[coreboot] [coreboot - Bug #536] Cannot build coreboot-sdk
Issue #536 has been updated by Nico Huber. Why explicitly specify `libcurl4` anyway? If it's a dependency, `apt-get` can solve it. If we want to build anything with it, we need one of the `-dev` variants instead. Bug #536: Cannot build coreboot-sdk https://ticket.coreboot.org/issues/536#change-1810 * Author: Michał Żygowski * Status: New * Priority: Normal * Assignee: Martin Roth * Target version: none * Start date: 2024-04-24 I have just tried building coreboot-sdk from scratch and could not get past the step of installing the required packages. Found out that diffutils dependency on libcurl4t64 break libcurl4 (change apt-get to apt to see verbose information message like below): ``` shell > [coreboot-sdk 2/4] RUN useradd -p locked -m coreboot &&apt-get > -qq update && apt -qqy install --no-install-recommends > bash-completion bc bison > bsdextrautils bzip2 ca-certificates > ccache cmake cscope curl > device-tree-compilerdh-autoreconf diffutils >exuberant-ctags flex g++ gawk > gcc git gnat-13 golang > graphicsmagick-imagemagick-compat graphvizlcov >lesslibcapture-tiny-perllibcrypto++-dev > libcurl4libcurl4-openssl-dev > libdatetime-perllibelf-dev libfreetype-dev >libftdi1-devlibglib2.0-dev libgmp-dev > libgpiod-dev libjaylink-dev liblzma-dev > libnss3-dev libncurses-dev libpci-dev > libreadline-dev libssl-dev libtimedate-perl >libusb-1.0-0-devlibxml2-dev > libyaml-dev m4 makemeson > msitoolsneovim ninja-build > openssh-client openssl parted patch > pbzip2 pkg-config python3 > python-is-python3 qemu-system-arm > qemu-system-miscqemu-system-ppc > qemu-system-x86 rsync sharutils > shellcheck unifont unzip uuid-dev >vim-common wgetxz-utils > zlib1g-dev && apt-get clean: 2.106 2.106 WARNING: apt does not have a stable CLI interface. Use with caution in scripts. 2.106 2.841 diffutils is already the newest version (1:3.10-1). 2.841 diffutils set to manually installed. 2.841 Some packages could not be installed. This may mean that you have 2.841 requested an impossible situation or if you are using the unstable 2.841 distribution that some required packages have not yet been created 2.841 or been moved out of Incoming. 2.841 The following information may help to resolve the situation: 2.841 2.841 Unsatisfied dependencies: 3.001 libcurl4t64 : Breaks: libcurl4 (< 8.7.1-3) 3.004 Error: Unable to correct problems, you have held broken packages. ``` Changing libcurl4 to libcurl4t64 allows the docker to continue the build process of coreboot-sdk. But is this the right thing to do? -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] AMD64 & X86S payload handover
Hi coreboot fellows, yesterday some patches[1] surfaced on Gerrit about a handover for 64-bit x86 payloads. Strictly speaking, we don't have to do anything for this right now, as the original, protected-mode handover would work too. How- ever, there is X86S on the horizon. If you don't know about it, here is the short version: X86S was announced by Intel last year, it's supposed to be a simplified version of AMD64, without real nor protected mode, so 64-bit long mode only. So we have: ++---+--+ || AMD64 | X86S | ++---+--+ | real mode | X | | ++---+--+ | protected mode | X | | ++---+--+ | long mode | X | X | ++---+--+ After a night's sleep, I'm convinced we should keep things as simple as possible on the coreboot side, and hence propose the following: 1. AMD64: Keep the current, 32-bit protected mode handover 2. X86S: Hand over in long mode with a) the pointer to cbtables in RDI (like the first parameter in the System V ABI), b) the guarantee that the payload and cbtables are identity mapped in the current page tables. Rationale: * 1. Allows us to keep compatibility where it's possible. X86S breaks compatibility on purpose but we don't have to break compatibility in the AMD64 case. There is one exception: A future X86S payload could potentially run on AMD64 and vice versa. Though, compatibility could be ensured on the payload end (e.g. having two entry points like the Linux kernel has(*)). * Keeping the current handover where possible would allow to use a new 64-bit payload with a coreboot build from one of the older branches, for instance, without having to modify them all. Existing coreboot binaries for AMD64 systems would stay compatible as well. * 1. requires a 64-bit payload to switch (back) to long mode by itself. This should be straight-forward, though, and can be done with rather few instructions. The necessary page-table setup could be kept small, as long mode supports 1GiB pages. Having to set up its own page ta- tables also avoids problems with assumptions about the prior setup. * Generally, we can't control what downstream does. However, by adding a long-mode handover as late as possible (i.e. the first X86S port), we would encourage everybody to stay compatible. Once the long-mode handover is implemented upstream, it will be easier to create a pay- load that works with some x86 coreboot builds, but not all. Making it X86S only, will limit the room for incompatibility. * 2. a) is probably what people would expect. * 2. b) allows for more flexibility in coreboot, without having to set up much (ideally nothing) special for the payload. If we'd make more guarantees, e.g. a whole 4GiB space identity mapped, it would become more likely that we have to change the mapping for the handover. For instance, if we'd ever decide to add a continuous mapping for a >16M flash chip. That would likely still be compatible with 2. b), though might not be with more elaborate guarantees. So, please share your thoughts :) Best regards, Nico [1] https://review.coreboot.org/c/coreboot/+/81960 https://review.coreboot.org/c/coreboot/+/81964 https://review.coreboot.org/c/coreboot/+/81968 (*) All payloads (builds) until now will be incompatible to X86S. But if we'd encourage to give all 64-bit payloads from now on two en- try points (32- and 64-bit), we could increase the number of pay- loads that are both compatible to X86S and all prior AMD64 core- coreboots. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #522] `region_overlap()` function might not work as expected due to an integer overflow in `region_end()` function.
Issue #522 has been updated by Nico Huber. Valerii Huhnin wrote in #note-14: > * What are well-formed regions? > * The last address of the region should be representable as a `size_t` > value? Definitely yes. > * The last address of the region +1 should be representable as a `size_t` > value? This won't be necessary and would only complicate the implementation. Everybody seems to agree that we don't want this. > * Regions should not have size 0 ? There seems to be consensus that we don't need it (and it would also minimally complicate the implementation). Though, we should do some testing because it is hard to assess if any part of the code expects this to work. > * What functions can assume that regions are well-formed? > * region API functions? > * SMRAM overlap check functions? > * But for sure not the SMI handlers themselves? We should check well-formedness before a `struct region` gets filled. Then any function using a struct region can assume that it's well formed. > * Where should we check if a region is well-formed? > * Create a dedicated function to check well-formdness of regions? > * Create a dedicated constructor function and check it there? We should explicitly check for invalid regions whenever data comes from outside of coreboot. We still need to decide on one of these two options. In any case, invalid external data should be handled gracefully. > * Check it directly in region API functions? We wouldn't want to do explicit error handling in every level of the API. IMO, an assert() in every public API function should suffice. > * What should we do if we encounter a non-well-formed region? > * Stop the execution? > * Try to treat it as well-formed (e.g. by ignoring addresses outside of > `SIZE_MAX`) ? > * Other context-dependent handling? I'd say depending on the context as described above. > Note: I also have a concern of the usage of the `size_t` type there. > Shouldn't we actually use `uintptr_t`? Might there be problems when > converting between this two? They should be the same anyway. A `struct region` only sometimes describes a region in memory, so `uintptr_t` wouldn't always be right. > After looking at the `mainboard_smi_brigthness_down()` function I think that > regions whose last address is non-representable as `size_t` is a problem on > its own (independently from whether or not `region_overlap()` correctly > detects overlap), as having such regions would later lead to an attempt of > constructing a pointer that points outside of the address space. This is true, but in this particular case, with the particular hardware, not a problem. The register should report 0 in the lower bits (except for the masked ones). This is also why the original overflow is hard to exploit with PCI BARs. Maximilian Brune wrote in #note-15: > > 2) Implement a specialized function that checks if the region is > > well-formed and returns a boolean value. I prefer this approach over > > ensuring well-formdness of regions in the constructor function because this > > would allow us to separate the well-formdness check itself from the > > handling of non-well-formed regions, which would also allow us to handle > > non-well-formed regions differently in different contexts if needed; > > I agree. The constructor should be separate from the check of itself. That > gives us the ability to check for sane values where it makes sense (SMM) and > leave them out for the rest (we can't check for overflows everywhere in the > code base). I proposed two different constructors in [1]. One that asserts and one that checks and allows to handle an error. I would prefer this over a separate function as it would make it clear when the check needs to be performed. If every API user with untrusted input would have to do the same `if (check(base, size)) ...`, I don't see what we win. I don't mind if somebody wants to implement it like that though. The callers that use region_create_unstrusted() in [1] are those that I identified as needing a check. [1] https://review.coreboot.org/c/coreboot/+/79905/ > > 4) Call the region well-formdness check function directly inside the SMI > > handlers before the smm_points_to_smram() check function; > > Sounds good. If they all go through smm_points_to_smram(), I would check there. Otherwise, the check could be missed on any new, future callers. That the region API is used that can overflow is also an implementation detail of smm_points_to_smram(). Bug #522: `region_overlap()` function might not work as expected due to an integer overflow in `region_end()` function. https://ticket.coreboot.org/issues/522#change-1753 * Author: Va
[coreboot] Announcement: flashrom-stable continues as flashprog
Hi everybody! as you may know already, flashrom-stable was removed from review.coreboot.org a while ago. flashrom-stable was a short- lived semi-fork, based on flashrom v1.2 [1]. The effort to keep developing a stable flash programming tool for everyone, however, shall continue. I have hence renamed flashrom-stable to *flashprog*. Now it's definitely a fork. The main reason for the fork is that I saw the flashrom master (now main) branch to become unmaintainable. Probably because we merged too much code together, without actually managing to work together on a product. Beside names, I tried to keep everything as usual. There's a wiki (slowly filled with contents from the old one) https://flashprog.org/ an IRC channel #flashprog on libera.chat and a mailing list, of course flashp...@flashprog.org managed at https://mail.sourcearcade.org/postorius/lists/flashprog.flashprog.org/ Review continues on a Gerrit instance, albeit on https://review.sourcearcade.org/ And you can clone the repository from a GitHub mirror https://github.com/SourceArcade/flashprog.git Now that all this is done, I hope to return to work on the source code again. There are still many patches open that were pending for flashrom-stable. And it looks like the next release candidate is only one commit away :) So stay tuned! Nico [1] https://mail.coreboot.org/hyperkitty/list/flashrom-sta...@flashrom.org/thread/RTP3UKMMGWUEVTS5XUFRCXXL24UE4FRV/ ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: coreboot's role in the boot process -- is it time for a coreboot spec?
On 29.11.23 02:01, Julius Werner wrote: >> I don't like superlatives. I don't think it needs to be "completely >> separate". For instance, when somebody discusses coreboot for a new >> platform behind closed doors[1]. And they implement something on the >> same code base. If they did that according to spec, it would be more >> likely to get accepted upstream, wouldn't it? > > I think whether stuff gets accepted upstream or not depends on whether > it follows coreboot coding conventions, fits in with our existing APIs > and general architecture, etc. I don't think it's really feasible to > write everything that goes into the code review and design discussion > process down in advance, and even if we could I'm not sure we'd really > want to either. Agreed. And that's why I want to describe things only at a rough, high level. I'd rather see compliance as a basic requirement than a suffi- cient condition. Direct things into the right direction early so there's more likely something worth reviewing. > Do we want to create a situation where someone uploads > code they developed in the dark and then tries to force us to take it > because "it matches the spec", even though we don't like it for some > good reason that we didn't anticipate in advance when writing the > spec? Somebody could try that, sure, but I don't see how that would be worse than the "it's already written" we often hear today. More important, IMO, is if such a conflict would be more likely. If I'd get one "it matches the spec" conflict instead of five "it's already written" conflicts, that would make me quite happy. > I think developing in the open and seeking consensus among all > upstream reviewers should continue to remain the officially > recommended way to develop in coreboot, and anyone who for whatever > reason develops stuff behind closed doors instead needs to understand > that they're responsible for dealing with other opinions when they > eventually decide to upload, including the risk that the majority of > the community says "we don't want this at all" or "we want a complete > redesign from the ground up". I just want to level that risk. And it's not just the development. When somebody starts talking to a silicon vendor behind closed doors, that can set certain expectations about coreboot. If those turn out to be wrong later, that can make future work harder. > > If you want to add documentation that explains how coreboot code > should fit together and where to integrate certain new features, or > just lists general best practices, I'm all for that. We have a bit of > that already and we could certainly always use more, or try to make it > more organized and discoverable. I would just be wary of calling it > anything that makes it sound official and authoritative. The term > "specification" usually implies that as long as you follow this thing > to the letter, you can _demand_ that your implementation should be > considered correct and everyone else who doesn't accept it is wrong. I > don't think we want anything like that for the coreboot development > process. Helping people do the right thing from the start is great, > but it should always remain understood that not everything that goes > into the process can be written down in advance and that the final > decision is done for each individual patch at review time. Like I said, I'm not set on calling it specification. And of course whatever we call it, it should have a defined scope, like an intro- duction that says what it applies for and what to expect. > > Or is the question more about "up to what point are people allowed to > say 'it runs coreboot' when they have out-of-tree code"? I'd say > that's an entirely different thing (that I'm less interested in tbh, > but maybe others are). Same here, I guess. I'm mostly concerned about the development process upstream. Not about what people do downstream; if they don't bother me I don't want to bother them. > I don't think we really have that problem in > practice yet, and if we ever get to the point where we do I think just > drawing the line at "runs 100% upstream code" should be good enough? That sounds rather infeasible, TBH. You may not know how hard it is to get things upstream when one isn't the first to work on a platform. Working around workarounds of others, maintaining undocumented boards that are already in the tree, having no word in what options a blob offers, etc. I believe coreboot has to go a long way before we can say that 100% upstream is possible for everybody. > coreboot is GPL so if people don't upstream their code there's really > only two possible reasons, either they're lazy and unreciprocating, or > their code is junk that wouldn't get accepted upstream. Or maybe the code that is already upstream is junk and it's impossible to fix without breaking some boards? Or maybe we let blobs in that make hackish workarounds necessary that maybe shouldn't even get upstream? Julius, I think in case of an
[coreboot] Re: coreboot's role in the boot process -- is it time for a coreboot spec?
Hi Julius, On 28.11.23 03:31, Julius Werner wrote: > Sounds to me like what you're asking for is really documentation, not > a spec? well, yes and no. It would be documenting what we did all along. But also serve as a blueprint for coreboot. I'm not all set on the term. I think it fits, even if it isn't what low-level developers would expect. But it seems more impor- tant to define (if not specify) what we think a coreboot should look like. > Or maybe project-internal rules about what individual platform > code may and may not do (but that's still not really a spec)? > > In my understanding, a specification is always something defining a > standard that allows interoperability _between_ different > implementations. It can be, but it can also be about interchangeability. When you specify a product, for instance, you may want different manufacturers to produce it, without making a difference for the consumer. > Something that only applies to a single > implementation (i.e. a single code base) can't really be a > specification. But there are different implementations of coreboot. Every time some- body does a bigger experiment on a local branch, that's a different coreboot. Or would you say it's still a single implementation when it shares 50% of the code base? 20%? 10%? > Making a "coreboot specification" would mean that > someone else could then take that and implement their own "coreboot" > in a completely separate cleanroom code base from scratch, and I don't > think that makes sense. I don't like superlatives. I don't think it needs to be "completely separate". For instance, when somebody discusses coreboot for a new platform behind closed doors[1]. And they implement something on the same code base. If they did that according to spec, it would be more likely to get accepted upstream, wouldn't it? Nico > (We could create a specification for the > coreboot payload handoff interface (i.e. coreboot tables) so that > other people could write their own firmware stack that can run > coreboot payloads. I don't think that would make much sense, though. > If we wanted payload interoperability we should probably rather attach > to one of the various other "universal payload" proposals that were > going around, although we've had discussions about that before where I > at least argued that I don't think that makes much sense for > coreboot.) [1] Let's not discuss if that should happen. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] coreboot's role in the boot process -- is it time for a coreboot spec?
Hi folks, something I've been thinking back and forth about since the hackathon a week ago: Should we give people who promote coreboot something to refer to, something that more clearly states, what coreboot is? I know, some of you who know me might feel the urge to check if it isn't April the 1st. Nico suggesting a spec? What's happening here? I've always neglected the idea. Probably because I was too focused on fellow developers. But coreboot is not only discussed by develo- pers anymore. And we all know too well, developers don't make all the decisions. I believe having a document that basically says "that's coreboot, that's what people ask for" might help in, well, higher-level discussions. So what do I suggest? To have some high-level description of what coreboot does, where it starts, where it ends. And also, to be com- prehensive, the things that are set in stone: cb-tables, SELF for the payload. It's in C header files. But I guess the information could be imported for the last chapters. Overall, the spec should not be long. I imagine something like 2~4 pages plus the cb-tables. About the high-level part: Generally, I don't want to rush this. But I'll draft some things below that I already have on my mind. My current thoughts are mostly motivated by the "new bootflow for ARM64" thread[1] and Martin's excellent idea to rather call that "with coreboot technology" than "coreboot". Many people seem to agree. I guess, because it's not what we usually do. But what do we usually do? Shouldn't we write that down? coreboot boot process - coreboot's bootstrapping usually happens in two phases: 1. When a DRAM controller is part of the platform, it will be configured by coreboot to allow access to the main memory. 2. When the main memory is available, the platform is further initialized into an abstract state that allows generic opera- ting systems to run. (some simple picture here; it's too late in the evening for ascii-art on my end) coreboot starts with the first instruction on the main application processor (AP), or earlier when another processor runs platform initialization code from writable memory before the AP starts. Exceptions are made, when * the first instructions run from a boot ROM, or * the first instructions are pre-defined by the silicon vendor and the hardware doesn't allow execution of other code, i.e. due to cryptographic signature checks. In this case, coreboot starts with the first instruction from writable memory that can be controlled by the platform owner. Future hardware iterations should strive to allow coreboot to run earlier. After the hardware initialization, coreboot will write tables (cbtables, ACPI, SMBIOS and alike) with chip- and board-specific information. With this information, a generic operating system should be able to run without any further, board-specific know- ledge. Finally, coreboot loads and executes an embedded payload program from the same memory that holds coreboot. If possible, coreboot will cease all other execution at this point. It is the payload program's responsibility to continue the boot strapping on its own, without relying on any services provided by coreboot but the in-memory tables. Cheers, Nico [1] https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/BRW3Z7G5DRYJBOZKAEQV7N7UBAIMXUWM ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: First time using coreboot+edk2, I didn't get to see the beginning.
Hi Keith, On 14.09.23 06:30, Keith Hui wrote: > What more set up I have to do to get my edk2 and grub boot menu back? > > I've attached logs from minicom, cbmem, and my Kconfig, if it helps. this seems to be the culprit: CONFIG_VGA_TEXT_FRAMEBUFFER=y EDK2 requires a linear framebuffer. You can find this in the Display submenu of the Devices menu. Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: 2023-08-23 - coreboot Leadership meeting minutes
Hello Hannah, On 07.09.23 20:49, Williams, Hannah wrote:> Already there are binaries FSP, AGESA, PSP being used in Coreboot and> because of IP and licensing issues everything cannot be open sourced. > The uGOP is just a stripped down version of GOP that is already inside > FSP. This is the fastest method for this specific product and hence we > are asking for a waiver to the closed source binary rule (by the way > where is this stated in coreboot.org?). Terms and conditions to use and modify/extend coreboot can be found here https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/COPYING The second sentence of the preamble already wraps the gist of it up, very well: "By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users." Changing software that comes in form of a blob is hard (and in case of FSP even denied by its license; nobody but Intel is allowed to even fix security issues). The technical mechanism to guarantee freedom lives in Section 3. The basic idea is that everybody who makes a product with coreboot has to share the source code of their whole coreboot under a compatible license. In a way, this means one has to pay to license coreboot for their products--not with money but with source code. Now with FSP, Intel presents their customers with an uncomfortable choice: Don't use Intel or go in debt (not being able to pay with source code). And now that Intel plunged everybody into debts for 10 years, you are asking for a waiver, so everybody can incur more debts? When should this end? When will Intel help to pay any of it back? Maybe, as a token of good faith, Intel could start publishing source code of this decade of FSP? All this "software freedom" may seem unnecessarily idealistic. But it often turns out that it actually helps with the every growing complexity of today's computer systems. And it helps to scale, it helps innovation. OTOH, the way I see it, Intel's approach seems to achieve less at much higher cost. As far as I understand, Intel's argument not to open source is usually a combination of: * There are a few lines that can't be open sourced because IP / NDA. * Intel supports only a single code base because of "convergence goals", (and that code base needs to be tainted by the lines mentioned above). I believe it's such convergence goals that keep Intel stuck 30 years in the past. Back then, there was little product diversity. Having a single, validated binary scaled well enough for a 386 SL/SX/DX (all in desktop like PCs). Toolchains weren't trusted, reproducibility probably wasn't a thing. Security updates were not a concern. I could imagine that source code wasn't even properly archived. IMO, the way Intel handles firmware today perfectly fits these times... In the 21st century, things look kind of the opposite: (security) updates every- where, huge product diversity (x86 on tablets, laptops, desktops, workstations, servers, all the IoT things--everything multiplied by consumer, embedded, server markets), and reproducible builds. A single validated binary probably scales so badly, I can't imagine the costs, and the horrors Intel employees have to go through. This also has bad effects on Intel's customers: there is absolutely no room for inno- vation. Let's imagine for a moment, everybody using coreboot for Meteor Lake would have to use a single coreboot build, a single binary, configured VBT-style. It seems virtually impossible to get that done in time. OTOH, it seems possible that supporting the coreboot code base and projects like libgfxinit directly--instead of trying to converge everybody's needs in a single binary--is actually cheaper for Intel. The SoL feature could be the perfect project to experiment with a community approach. Hannah, sorry if I digressed too much, but I really hope this helps to understand the bigger picture. Please help Intel to embrace diver- sity instead of trying to cook up single binaries. Actually, Pat Gelsinger seems to understand already[1]: "• And, as is core to the Intel values, we will be inclusive in our approach and support of communities’ efforts, while embracing diversity and our differences because they make us better." There are probably many levels inside Intel between you and him that need your help to understand it too, and to adapt Intel to the 21st century. Nico [1] https://www.linkedin.com/pulse/open-letter-ecosystem-pat-gelsinger ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: 2023-08-23 - coreboot Leadership meeting minutes
On 25.08.23 06:52, Williams, Hannah wrote: > I think your suggestion to use similar interface to libgfxinit > (gma_gfxinit(), gma_gfxstop()) is a good idea. Please add your comments to > the CLs and we will work on it. Thanks. I'll wait though, until the decisions about open-sourcing and integrating uGOP are made. > Regarding the MP PPI and the Kconfig cleanup that you mentioned, we will take > this up. I am going to open a internal ticket to follow up on this. Thanks again! However the MP PPI was just one example. It would be good to have up-to-date information and clean integration for all features of Intel's blobs. Information, I think, is the more impor- tant part. Staying with the MP PPI example: IIRC, when it was intro- duced there was a list of advanced features added to our documen- tation, arguing that the features would only be made possible by the MP PPI integration. But I'm not sure if any of these features ever surfaced in coreboot. So maybe this is something to add to your ticket: Do we actually need the MP PPI in coreboot? > Also, on your comment on implementing libgfxinit for MTL, this will not speed > up the process for us because we do not have resources to work on it Last time I checked Intel was still a multi-billion dollar company. I think this translates to: SOL is not a high enough priority for Intel. > and this is why we went the faster route to re-use what we already have (GOP) > and modified it as uGOP for SOL use case. If you only go one route, we'll never have a definite answer which is the faster one. Regards, Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: 2023-08-23 - coreboot Leadership meeting minutes
Hi Hannah, On 24.08.23 05:33, Williams, Hannah wrote: > We understand the hesitation to introduce one more binary blob in Coreboot. > We are not opposed to open sourcing (we did support libgfxinit for our > previous platforms). The Meteor Lake platform is at the final stages of > development and validation, so Intel prefers to proceed with the current path > to have https://review.coreboot.org/q/topic:%22ugop%22 merged now and we > will follow up in parallel with a plan for open sourcing uGOP. I don't comprehend this "merged now". *If* the project agrees to this path, first the design would have to be discussed. And then we could start a review. Merging comes after that. And as mentioned in the other thread, last time in a similar case it took 11 months. So if you are in a hurry to get something upstream, this doesn't seem like a promising approach. Again if the project would agree, you could probably speed things up by proposing a more modern interface and code flow (for libgfxinit we currently have a simple API: gma_gfxinit(), gma_gfxstop(), and I don't see why a blob couldn't reuse this interface). And a binary format that doesn't need changes to our tools. > > Notice though that currently there are many blobs still being loaded by > Coreboot and not all of these are Intel blobs, so why not allow another > Intel blob to be merged? Quite simple, because this is a free-software project, and every single blob requires careful consideration. The question raised one concern for me: Is it maybe that the amount of blobs mislead you to believe that integrating the uGOP would be an easy, feasible solution? I think it's quite important to discuss these things, so everybody can make better decisions in the future and avoid all the friction and pain for developers caused by bad decisions. If the obscure blob situation makes things harder, maybe it's time for a little housecleaning? For instance, if you've followed the other thread, there was the MP PPI mentioned, and some misunderstandings around it. Could Intel maybe evaluate what blobs and interfaces are actually required in upstream coreboot, and clean up the integration? For the MP PPI for instance, I saw half a dozen Kconfig options where one might suffice. It would also be interesting to see if the argu- ments that were used to introduce the blobs are still valid. WDYT? > Also, this is only an alternate method to libgfxinit. We do not have > support today for Meteor Lake in libgfxinit, so this is not an option, > hence we want the alternate method that uses the blob (uGOP). Either way takes time because we are only in the very early stages to discuss the uGOP solution. Here's a thought: Implementing libgfxinit support for MTL right now would at least speed the process up for the next generation. And in the best case, it would be ready before the MTL launch. So if you are in a hurry, the best thing to do is to work in parallel on both approaches and start coding right away. Regards, Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: [RFC] Pre-Memory Sign-of-Life using Intel uGOP
On 24.08.23 07:02, Martin Roth via coreboot wrote: > I don't like that idea, but as was said in the meeting today, coreboot is > willing to accept that, but on the condition that the source for the binary > (and future similar binaries) is made open. To show good faith Intel could > guarantee that the source will be opened when it can (supplying a date) and > release the GOP driver source for platforms that do have released PRMs. IMO releasing a PRM can't act as a reference point for this. As Intel decides when and if the release of PRMs happens and that is often more than a year after a platform launch, the code would be outdated and use- less by then. But before entertaining the idea of a later open-sourced blob further, I want everybody to be aware of the following: Last time a similar blob interface was merged upstream, it took 11 months to get it through review[1]. And that was for an optional interface; the blob can do its primary job without it. So even if by some miracle we would agree on a blob now, it would still need to be designed, discussed and reviewed. It's too late for Meteor Lake anyway. So I don't see why the community should bother with it. Nico [1] commit 6662cb3dc2c4fe56cb75f83e1e7015287870cf01 Author: Subrata Banik AuthorDate: Thu Apr 12 19:25:37 2018 +0530 Commit: Patrick Georgi CommitDate: Tue Mar 19 21:41:01 2019 + drivers/intel/fsp2_0: Implement EFI_MP_SERVICES_PPI structure APIs ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: [RFC] Pre-Memory Sign-of-Life using Intel uGOP
Hi Jeremy, On 24.08.23 00:24, Compostella, Jeremy wrote: >> 3) Is there a reason that the uGOP driver can't be open sourced, at >> least once the Graphics Programmer Reference Manuals are released? > > We cannot open-source the code for platforms for which the PRMs are > not publicly published and we currently do not have a commitment for > having RPMs for Meteor Lake. there's something that hit the news shortly after today's meeting: https://www.phoronix.com/news/Intel-Lunar-Lake-Display-Linux I know this doesn't mean that code is already working. Still, it would seem that some of your colleagues are about 24 months ahead of you when it comes to what they can publish. I'm starting to wonder, do you maybe talk to the wrong people internally at Intel? Or are we really talking about customers that want the driver ready more than 2 years before platform launch? In which case I'd have to say, you seem rather late for MTL, no matter what driver. Regards, Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: [RFC] Pre-Memory Sign-of-Life using Intel uGOP
On 23.08.23 11:32, Arthur Heymans wrote: >>> ReportStatusCode() to report debug information which coreboot prints > using printk. >> can you point me to the code integrating this? I could find this > identifier only in vendorcode/ headers. Is it for debugging? > > I meant code calling back to the coreboot console in general for debugging. > A few examples: > 1) > https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/src/northbridge/intel/sandybridge/raminit_mrc.c#153 > 2) > https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/src/drivers/intel/fsp2_0/fsp_debug_event.c#20 Thanks, seems ok to me to use it for debugging. >> I thought this was kept optional--one of the many things dumped into our > repo that didn't take off. > Just checked and it's enabled by default oO, but I could disable it and > coreboot built. > Does anybody use this PPI "feature" in a product? > > I thought the CPU PPI was enabled by default and necessary(?) on all Intel > products (except xeon-sp) since Intel Icelake. That is what we were told initially, but then the `SkipMpInit` UPD stayed and there was effort to keep it working, e.g. 8409f156d588 (soc/intel/alderlake: Remove dependency of FSP-S CpuMpPei Module) Grepping right now, this seems to be missing for Meteor Lake, though. Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: [RFC] Pre-Memory Sign-of-Life using Intel uGOP
Hi Arthur, On 23.08.23 10:41, Arthur Heymans wrote: > We already have code similar to ReportStatusCode can you point me to the code integrating this? I could find this identifier only in vendorcode/ headers. Is it for debugging? > and ramstage PPI so maybe > it's not a problem. I thought this was kept optional--one of the many things dumped into our repo that didn't take off. Just checked and it's enabled by default oO, but I could disable it and coreboot built. Does anybody use this PPI "feature" in a product? Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: [RFC] Pre-Memory Sign-of-Life using Intel uGOP
Hi Jeremy, On 14.08.23 22:52, Compostella, Jeremy wrote: > We propose to take advantage of a proprietary driver Intel already supports, > validates and includes in FSP silicon: the Intel Graphics PEIM (Pre-EFI > Initialization Module) driver also known as the GOP (Graphical Output > Protocol) driver. just to make sure nobody makes wrong assumptions: Will the uGOP be open-source or proprietary as well? I first thought the latter. But your proposed code-flow looks like some sort of dynamic linking with coreboot. > We intend to keep providing such a binary base solution on the long run as it > addresses our software convergence goals and is compatible with early > platform development stage constraints. [libgfxinit] supports can always be > added later by the open-source community once the Graphics Programmer > Reference Manuals are published. Sad to hear about this decision. It seems Intel is forgetting about non-consumer products (e.g. embedded market) where the code isn't needed years ahead of a platform launch. > We also noticed that microGOP is faster to bring-up graphics than libgfxinit. > Indeed, according to previously captured numbers on Raptor Lake compared to > some number of microGOP on Meteor Lake, microGOP is three times faster to > bring up graphics than libgfxinit on an eDP panel (119 ms vs 373 ms). Configuring the hardware and bringing up the eDP link should take about 20~30ms mostly depending on how long it takes to read the EDID. The longer delays are likely about panel power sequencing. IIRC, libgfxinit falls back to hardcoded default values if the sequencer is unconfigured, while the GOP just leaves it like that. Chromebooks often skip the configuration[1] in firmware and leave it to the OS driver. Using wrong delays probably doesn't hurt on a rare interactive boot. However, I guess doing this on regular boots might not be the best idea. Nico [1] https://doc.coreboot.org/gfx/display-panel.html ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] New Matrix channel #coreboot:matrix.org
Hi all, due to ongoing reliability issues with the matrix.org-to-libera.chat bridge, channel portalling is going to be disabled [1]. Hence there is a new Matrix channel #coreboot:matrix.org [2] that is bridged to the IRC channel on Libera. Hopefully, this will work a little better. AIUI, the old channel will become read-only on the Matrix network by August, 11th. So all Matrix users are encouraged to join the new channel. For direct IRC users, nothing changes. Best regards, Nico [1] https://libera.chat/news/matrix-deportalling [2] https://matrix.to/#/#coreboot:matrix.org ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Feature #500] coreboot bootsplash only supports jpeg and does not support extended resolutions
Issue #500 has been updated by Nico Huber. Related links updated Nico Huber wrote in #note-7: > It probably needs some tuning, but could work in theory. Anyone with a > compatible .jpg, please test :) Found [ThePlexus](https://github.com/osresearch/heads/blob/master/blobs/ThePlexus-bootsplash-1024x768.jpg) in the description. Seems to work fine in QEMU :) (as far as the coreboot framebuffer driver works, odd resolutions like 1366x768 don't work, not sure if a bug in coreboot or QEMU or if the emulated hardware is not supposed to support it) Feature #500: coreboot bootsplash only supports jpeg and does not support extended resolutions https://ticket.coreboot.org/issues/500#change-1610 * Author: Thierry Laurion * Status: New * Priority: Normal * Category: coreboot common code * Target version: master * Start date: 2023-07-13 * Related links: https://github.com/coreboot/coreboot/blob/master/src/lib/jpeg.c https://git.seabios.org/seabios.git/ https://github.com/osresearch/heads/pull/1403/commits/659308eff53f39633ffad71597a2463fa30eedd3#diff-816b79cd9a1192fa8cf78b9737f0d3fed5a943a0d2c952da591f8a2446edc1db WiP PoC: https://github.com/osresearch/heads/pull/1403 Potential enhancement of the existing JPEG decoder: https://review.coreboot.org/c/coreboot/+/76424 Image compatible with coreboot's current JPEG decoder: https://github.com/osresearch/heads/blob/master/blobs/ThePlexus-bootsplash-1024x768.jpg * Affected hardware: All using coreboot display init + bootsplash * Affected OS: n/a For those of you on matrix, the discussion happened at https://matrix.to/#/!BZxDFuoBnMKnzVZwEp:libera.chat/$pQoGnN9DnokZ875fTbHiAtTc0IEVgQDycUJmB7PLulE?via=libera.chat=matrix.org=matrix.zerodao.gg Short version: - libgfxinit bootsplash through jpeg.c supports VESA old resolutions (1024x768) - libgfxinit bootsplash through jpeg.c doesn't support native resolutions (1366x768) - libgfxinit bootsplash image creation requires voodoo skills explained at https://puri.sm/posts/librem-13-coreboot-report-february-25th-2017 - Basically, I do not think libgfxinit bootsplash is currently used otherwise there would be way more bug reports. Seabios is mostly used. - Seabios bootsplash code should be borrowed (lgplv3) which supports both BMP and JPEG and is not 13yo. - Coreboot should permit stiching of compressed bmp by default and deprecate old jpeg.c in tree - By doing so, more people could promote coreboot directly from coreboot raminit (Heads currently does that) Longer version: - OSes are attacking legacy BIOS mode for a while now, and the next steps are to deprecate DRM drivers in initrd - To phase DRM out, simplefb and simpledrm are promoted instead where final OS will be in charge of deploying bigger unified kernels containing/initrd which will contain the accelerated DRM and fb drivers - Currently deploying DRM drivers inside of linuxboot (heads) on Intel iGPU requires to include i915drmfb, coreboot linux command lines hacks to have the FB address exposed (tainting the kernel) and kexec hacked to expose exposed fb address to next kernel (see https://github.com/osresearch/heads/pull/1378) - Doing currently adds more then 500kb of in-kernel drivers, which bloats the firmware. In case of measured boot, that bigger payload needs to be measured prior of being read and jumped into (8-10 seconds under 5.10 kernel compared to 4-6 seconds under 4.14) - To have legacy BIOS survive this ecosystem attack against legacy boot, coreboot needs to push for a more generic way to provide a framebuffer (GOP/Native unified approach) - With libgfxinit/GOP/native gfx init and the kernel config adapted, linux can efficiently be used as a bootloader and be enabled by simplefb (https://github.com/osresearch/heads/pull/1403/commits/659308eff53f39633ffad71597a2463fa30eedd3) - The part missing is having coreboot drive the framebuffer with a native size bootsplash as everyone else does so that the waiting time to boot in kernel/payload is not a scary moment, and that the bootsplash doesn't restrict the size of the framebuffer configured under coreboot nor limit the UX. Actual state: - libgfxinit needs to have jpeg supported resolution to bootsplash (CONFIG_LINEAR_FRAMEBUFFER_MAX_HEIGHT=768 CONFIG_LINEAR_FRAMEBUFFER_MAX_WIDTH=1024) - libgfxinit bootsplash needs to have a 1024x768 voodoo crafted jpeg (https://github.com/osresearch/heads/blob/master/blobs/ThePlexus-bootsplash-1024x768.jpg) - Problem is that doing so, the whole console is limited to that resolution showing black borders on each side of the screen to compensate (1366 != 1024, so (1366-1024)/2 is the loss pixel width on each side of the screen for 1366x764, same applying to all other resolutions since needs to be 4x4 for jpeg.c to do its job. Desired state: - flat bmp support in native format just like seabios support, where coreboot compressed them
[coreboot] [coreboot - Feature #500] coreboot bootsplash only supports jpeg and does not support extended resolutions
Issue #500 has been updated by Nico Huber. Related links updated I don't think there is a limitation to legacy resolutions. At least, I've never heard of one. So far the resolution had to match the .jpg and that had to be a multiple of 16 pixels, AIUI. Until somebody takes on integrating any new decoder (SeaBIOS' doesn't seem to be compatible license wise), [this patch](https://review.coreboot.org/c/coreboot/+/76424) might help with the existing JPEG decoder. It probably needs some tuning, but could work in theory. Anyone with a compatible .jpg, please test :) Feature #500: coreboot bootsplash only supports jpeg and does not support extended resolutions https://ticket.coreboot.org/issues/500#change-1609 * Author: Thierry Laurion * Status: New * Priority: Normal * Category: coreboot common code * Target version: master * Start date: 2023-07-13 * Related links: https://github.com/coreboot/coreboot/blob/master/src/lib/jpeg.c https://git.seabios.org/seabios.git/ https://github.com/osresearch/heads/pull/1403/commits/659308eff53f39633ffad71597a2463fa30eedd3#diff-816b79cd9a1192fa8cf78b9737f0d3fed5a943a0d2c952da591f8a2446edc1db WiP PoC: https://github.com/osresearch/heads/pull/1403 Potential enhancement of the existing JPEG decoder: https://review.coreboot.org/c/coreboot/+/76424 * Affected hardware: All using coreboot display init + bootsplash * Affected OS: n/a For those of you on matrix, the discussion happened at https://matrix.to/#/!BZxDFuoBnMKnzVZwEp:libera.chat/$pQoGnN9DnokZ875fTbHiAtTc0IEVgQDycUJmB7PLulE?via=libera.chat=matrix.org=matrix.zerodao.gg Short version: - libgfxinit bootsplash through jpeg.c supports VESA old resolutions (1024x768) - libgfxinit bootsplash through jpeg.c doesn't support native resolutions (1366x768) - libgfxinit bootsplash image creation requires voodoo skills explained at https://puri.sm/posts/librem-13-coreboot-report-february-25th-2017 - Basically, I do not think libgfxinit bootsplash is currently used otherwise there would be way more bug reports. Seabios is mostly used. - Seabios bootsplash code should be borrowed (lgplv3) which supports both BMP and JPEG and is not 13yo. - Coreboot should permit stiching of compressed bmp by default and deprecate old jpeg.c in tree - By doing so, more people could promote coreboot directly from coreboot raminit (Heads currently does that) Longer version: - OSes are attacking legacy BIOS mode for a while now, and the next steps are to deprecate DRM drivers in initrd - To phase DRM out, simplefb and simpledrm are promoted instead where final OS will be in charge of deploying bigger unified kernels containing/initrd which will contain the accelerated DRM and fb drivers - Currently deploying DRM drivers inside of linuxboot (heads) on Intel iGPU requires to include i915drmfb, coreboot linux command lines hacks to have the FB address exposed (tainting the kernel) and kexec hacked to expose exposed fb address to next kernel (see https://github.com/osresearch/heads/pull/1378) - Doing currently adds more then 500kb of in-kernel drivers, which bloats the firmware. In case of measured boot, that bigger payload needs to be measured prior of being read and jumped into (8-10 seconds under 5.10 kernel compared to 4-6 seconds under 4.14) - To have legacy BIOS survive this ecosystem attack against legacy boot, coreboot needs to push for a more generic way to provide a framebuffer (GOP/Native unified approach) - With libgfxinit/GOP/native gfx init and the kernel config adapted, linux can efficiently be used as a bootloader and be enabled by simplefb (https://github.com/osresearch/heads/pull/1403/commits/659308eff53f39633ffad71597a2463fa30eedd3) - The part missing is having coreboot drive the framebuffer with a native size bootsplash as everyone else does so that the waiting time to boot in kernel/payload is not a scary moment, and that the bootsplash doesn't restrict the size of the framebuffer configured under coreboot nor limit the UX. Actual state: - libgfxinit needs to have jpeg supported resolution to bootsplash (CONFIG_LINEAR_FRAMEBUFFER_MAX_HEIGHT=768 CONFIG_LINEAR_FRAMEBUFFER_MAX_WIDTH=1024) - libgfxinit bootsplash needs to have a 1024x768 voodoo crafted jpeg (https://github.com/osresearch/heads/blob/master/blobs/ThePlexus-bootsplash-1024x768.jpg) - Problem is that doing so, the whole console is limited to that resolution showing black borders on each side of the screen to compensate (1366 != 1024, so (1366-1024)/2 is the loss pixel width on each side of the screen for 1366x764, same applying to all other resolutions since needs to be 4x4 for jpeg.c to do its job. Desired state: - flat bmp support in native format just like seabios support, where coreboot compressed them prior of adding it into CBFS. - support for all crazy resolutions we currently have, not being stuck in 2000. - Be able to promote
[coreboot] [coreboot - Bug #499] coreboot will not boot edk2 on Lenovo T440p with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled, cannot disable this setting during build
Issue #499 has been updated by Nico Huber. We should probably focus on one problem and one machine (that we can get edk2 logs from) at a time. Sean, thanks for your logs so far. Looking at the latest logs, I see what Michał pointed out: The 0xFEC0 error is present even without top-down allocation. And in the very last log we are one ``` InstallProtocolInterface: 4CF5B200-68B8-4CA5-9EEC-B23E3F50029A ``` (gEfiPciIoProtocolGuid) short. And everything around `Found PCI Display device` is missing. To make sure we are not hunting multiple issues at once, it would be best to return to known-good and first-broken master states, e.g. ``` supposedly good: commit d7a354dab0fb (mb/google/brya/acpi: Set polling timing for DL23 and LD23 to 2ms) introduced top-down: commit 5226301765de (allocator_v4: Treat above 4G resources more natively) otherwise known good: commit 0754e00ace63 (allocator_v4: Fix top-level allocations w/o IORESOURCE_ABOVE_4G) ``` The last one would only be interesting later, when we figured out what is wrong with the second. I'm not sure how to trace the gap to the installation of gEfiPciIoProtocolGuid. Assuming it goes through StartPciDevicesOnBridge(), maybe we should add additional output there: for each device in the loop: the path, `->Allocated` and `->Registered`. Bug #499: coreboot will not boot edk2 on Lenovo T440p with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled, cannot disable this setting during build https://ticket.coreboot.org/issues/499#change-1587 * Author: Oberon 4071 * Status: New * Priority: Normal * Assignee: Nico Huber * Start date: 2023-06-29 * Affected versions: 4.21 * Needs backport to: none * Related links: https://review.coreboot.org/c/coreboot/+/76198 https://review.coreboot.org/c/coreboot/+/76199 * Affected hardware: lenovo/t440p coreboot revision in git: feb27dcbf3fc685b070c950a16e8adec958bc1ce coreboot revision (git describe --tags): 4.20-520-gfeb27dcbf3 Tested payloads: edk2 from MrChromebox revision uefipayload_202304 and uefipayload_202306 coreboot will not boot my Lenovo ThinkPad T440p with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled, when using the edk2 payload (MrChromebox version, either uefipayload_202304 or uefipayload_202306). The display sometimes turns on, indicating that some of the hardware initialization was successful, but the payload will not start. I tried to disable CONFIG_RESOURCE_ALLOCATION_TOP_DOWN in .config, but the build process insists on leaving this config enabled. This seems to be caused by the RESOURCE_ALLOCATION_TOP_DOWN setting changed to "def_bool y" in src/device/Kconfig in commit 5226301765ded70e0ef640e5252bbaca8cd14451 (allocator_v4: Treat above 4G resources more natively). The make target for building coreboot seems to automatically rerun olddefconfig, causing this setting to always remain enabled no matter what was previously saved in the .config file. Modifying src/device/Kconfig to change RESOURCE_ALLOCATION_TOP_DOWN to "def_bool n" appears to fix the problem on my machine. I have attached my .config file (with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled to reproduce the problem). ---Files .config (20.7 KB) console.log (128 KB) cbmem.txt (151 KB) cbmem_seabios_with_resource_allocation_top_down.txt (41.1 KB) dmesg_change_76199.txt (56.7 KB) cbmem_change_76199.txt (120 KB) cbmem.txt (116 KB) cbmem_top_down_n.txt (163 KB) dmesg_top_down_n.txt (58.2 KB) dmesg.txt (58.3 KB) cbmem.txt (166 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #499] coreboot will not boot edk2 on Lenovo T440p with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled, cannot disable this setting during build
Issue #499 has been updated by Nico Huber.
Sean Rhodes wrote in #note-17:
> It's asserting on L1900 of
> MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c
This?
```
if (((EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE *)ChildTable)->Dsdt !=
0) {
TableToInstall = (VOID
*)(UINTN)((EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE *)ChildTable)->Dsdt;
Status = AddTableToList (AcpiTableInstance, TableToInstall,
TRUE, Version, TRUE, );
if (EFI_ERROR (Status)) {
DEBUG ((DEBUG_ERROR, "InstallAcpiTableFromHob: Fail to add ACPI
table DSDT\n"));
ASSERT_EFI_ERROR (Status);
break;
}
}
```
Any chance to get the status code?
Bug #499: coreboot will not boot edk2 on Lenovo T440p with
CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled, cannot disable this setting during
build
https://ticket.coreboot.org/issues/499#change-1581
* Author: Oberon 4071
* Status: New
* Priority: Normal
* Assignee: Nico Huber
* Start date: 2023-06-29
* Affected versions: 4.21
* Needs backport to: none
* Related links: https://review.coreboot.org/c/coreboot/+/76198
https://review.coreboot.org/c/coreboot/+/76199
* Affected hardware: lenovo/t440p
coreboot revision in git: feb27dcbf3fc685b070c950a16e8adec958bc1ce
coreboot revision (git describe --tags): 4.20-520-gfeb27dcbf3
Tested payloads: edk2 from MrChromebox revision uefipayload_202304 and
uefipayload_202306
coreboot will not boot my Lenovo ThinkPad T440p with
CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled, when using the edk2 payload
(MrChromebox version, either uefipayload_202304 or uefipayload_202306). The
display sometimes turns on, indicating that some of the hardware initialization
was successful, but the payload will not start.
I tried to disable CONFIG_RESOURCE_ALLOCATION_TOP_DOWN in .config, but the
build process insists on leaving this config enabled. This seems to be caused
by the RESOURCE_ALLOCATION_TOP_DOWN setting changed to "def_bool y" in
src/device/Kconfig in commit 5226301765ded70e0ef640e5252bbaca8cd14451
(allocator_v4: Treat above 4G resources more natively). The make target for
building coreboot seems to automatically rerun olddefconfig, causing this
setting to always remain enabled no matter what was previously saved in the
.config file.
Modifying src/device/Kconfig to change RESOURCE_ALLOCATION_TOP_DOWN to
"def_bool n" appears to fix the problem on my machine.
I have attached my .config file (with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN
enabled to reproduce the problem).
---Files
.config (20.7 KB)
console.log (128 KB)
cbmem.txt (151 KB)
cbmem_seabios_with_resource_allocation_top_down.txt (41.1 KB)
dmesg_change_76199.txt (56.7 KB)
cbmem_change_76199.txt (120 KB)
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
https://ticket.coreboot.org/my/account
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #499] coreboot will not boot edk2 on Lenovo T440p with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled, cannot disable this setting during build
Issue #499 has been updated by Nico Huber. Related links updated Oberon 4071 wrote in #note-13: > Nico Huber wrote in #note-11: > > Alas, nothing obvious in the log. If there is any resource unknown to > > coreboot, even with a log of the failing boot, we might end up simply > > constraining the space for allocations. So we can try that right away: > > [Here's a patch that might > > work](https://review.coreboot.org/c/coreboot/+/76198). If that doesn't > > help, I guess we have to disable top-down allocation for Haswell. > > Unfortunately, the above patch (to change DOMAIN_RESOURCE_32BIT_LIMIT) did > not work for me when using EDK2. Sorry, I forgot: You have to run `make olddefconfig` or any other config target after applying that patch. You can check if it had an effect in your `.config` file. [I've spotted something now](https://review.coreboot.org/c/coreboot/+/76199), that actually makes sense to patch, but I don't know if it has an effect on edk2. I'm actually quite surprised that it works with SeaBIOS. A cbmem log with that patch and the changed limit would also be much appreciated. `dmesg` output can also be helpful in case Linux detects any error that is caused by the top-down allocation (I couldn't spot anything abnormal in the cbmem log). Bug #499: coreboot will not boot edk2 on Lenovo T440p with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled, cannot disable this setting during build https://ticket.coreboot.org/issues/499#change-1577 * Author: Oberon 4071 * Status: New * Priority: Normal * Assignee: Nico Huber * Start date: 2023-06-29 * Affected versions: 4.21 * Needs backport to: none * Related links: https://review.coreboot.org/c/coreboot/+/76198 https://review.coreboot.org/c/coreboot/+/76199 * Affected hardware: lenovo/t440p coreboot revision in git: feb27dcbf3fc685b070c950a16e8adec958bc1ce coreboot revision (git describe --tags): 4.20-520-gfeb27dcbf3 Tested payloads: edk2 from MrChromebox revision uefipayload_202304 and uefipayload_202306 coreboot will not boot my Lenovo ThinkPad T440p with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled, when using the edk2 payload (MrChromebox version, either uefipayload_202304 or uefipayload_202306). The display sometimes turns on, indicating that some of the hardware initialization was successful, but the payload will not start. I tried to disable CONFIG_RESOURCE_ALLOCATION_TOP_DOWN in .config, but the build process insists on leaving this config enabled. This seems to be caused by the RESOURCE_ALLOCATION_TOP_DOWN setting changed to "def_bool y" in src/device/Kconfig in commit 5226301765ded70e0ef640e5252bbaca8cd14451 (allocator_v4: Treat above 4G resources more natively). The make target for building coreboot seems to automatically rerun olddefconfig, causing this setting to always remain enabled no matter what was previously saved in the .config file. Modifying src/device/Kconfig to change RESOURCE_ALLOCATION_TOP_DOWN to "def_bool n" appears to fix the problem on my machine. I have attached my .config file (with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled to reproduce the problem). ---Files .config (20.7 KB) console.log (128 KB) cbmem.txt (151 KB) cbmem_seabios_with_resource_allocation_top_down.txt (41.1 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #499] coreboot will not boot edk2 on Lenovo T440p with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled, cannot disable this setting during build
Issue #499 has been updated by Nico Huber. Related links updated Alas, nothing obvious in the log. If there is any resource unknown to coreboot, even with a log of the failing boot, we might end up simply constraining the space for allocations. So we can try that right away: [Here's a patch that might work](https://review.coreboot.org/c/coreboot/+/76198). If that doesn't help, I guess we have to disable top-down allocation for Haswell. Bug #499: coreboot will not boot edk2 on Lenovo T440p with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled, cannot disable this setting during build https://ticket.coreboot.org/issues/499#change-1574 * Author: Oberon 4071 * Status: New * Priority: Normal * Assignee: Nico Huber * Start date: 2023-06-29 * Affected versions: 4.21 * Needs backport to: none * Related links: https://review.coreboot.org/c/coreboot/+/76198 * Affected hardware: lenovo/t440p coreboot revision in git: feb27dcbf3fc685b070c950a16e8adec958bc1ce coreboot revision (git describe --tags): 4.20-520-gfeb27dcbf3 Tested payloads: edk2 from MrChromebox revision uefipayload_202304 and uefipayload_202306 coreboot will not boot my Lenovo ThinkPad T440p with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled, when using the edk2 payload (MrChromebox version, either uefipayload_202304 or uefipayload_202306). The display sometimes turns on, indicating that some of the hardware initialization was successful, but the payload will not start. I tried to disable CONFIG_RESOURCE_ALLOCATION_TOP_DOWN in .config, but the build process insists on leaving this config enabled. This seems to be caused by the RESOURCE_ALLOCATION_TOP_DOWN setting changed to "def_bool y" in src/device/Kconfig in commit 5226301765ded70e0ef640e5252bbaca8cd14451 (allocator_v4: Treat above 4G resources more natively). The make target for building coreboot seems to automatically rerun olddefconfig, causing this setting to always remain enabled no matter what was previously saved in the .config file. Modifying src/device/Kconfig to change RESOURCE_ALLOCATION_TOP_DOWN to "def_bool n" appears to fix the problem on my machine. I have attached my .config file (with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled to reproduce the problem). ---Files .config (20.7 KB) console.log (128 KB) cbmem.txt (151 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #499] coreboot will not boot edk2 on Lenovo T440p with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled, cannot disable this setting during build
Issue #499 has been updated by Nico Huber. With CONSOLE_SPI_FLASH it seems to hang too early for any useful output. If you'd return to a working config, a cbmem log would be more comprehensive. It won't show the same as one with RESOURCE_ALLOCATION_TOP_DOWN, but could already provide some more details of your system. Bug #499: coreboot will not boot edk2 on Lenovo T440p with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled, cannot disable this setting during build https://ticket.coreboot.org/issues/499#change-1571 * Author: Oberon 4071 * Status: New * Priority: Normal * Assignee: Nico Huber * Start date: 2023-06-29 * Affected versions: 4.21 * Needs backport to: none * Affected hardware: lenovo/t440p coreboot revision in git: feb27dcbf3fc685b070c950a16e8adec958bc1ce coreboot revision (git describe --tags): 4.20-520-gfeb27dcbf3 Tested payloads: edk2 from MrChromebox revision uefipayload_202304 and uefipayload_202306 coreboot will not boot my Lenovo ThinkPad T440p with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled, when using the edk2 payload (MrChromebox version, either uefipayload_202304 or uefipayload_202306). The display sometimes turns on, indicating that some of the hardware initialization was successful, but the payload will not start. I tried to disable CONFIG_RESOURCE_ALLOCATION_TOP_DOWN in .config, but the build process insists on leaving this config enabled. This seems to be caused by the RESOURCE_ALLOCATION_TOP_DOWN setting changed to "def_bool y" in src/device/Kconfig in commit 5226301765ded70e0ef640e5252bbaca8cd14451 (allocator_v4: Treat above 4G resources more natively). The make target for building coreboot seems to automatically rerun olddefconfig, causing this setting to always remain enabled no matter what was previously saved in the .config file. Modifying src/device/Kconfig to change RESOURCE_ALLOCATION_TOP_DOWN to "def_bool n" appears to fix the problem on my machine. I have attached my .config file (with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled to reproduce the problem). ---Files .config (20.7 KB) console.log (128 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #499] coreboot will not boot edk2 on Lenovo T440p with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled, cannot disable this setting during build
Issue #499 has been updated by Nico Huber. Alas, the flash console log ends before ramstage. It's often not fully working, but was worth a shot. Maybe a cbmem log with RESOURCE_ALLOCATION_TOP_DOWN disabled would already provide some insight. But it's really a bit like shooting in the dark. Bug #499: coreboot will not boot edk2 on Lenovo T440p with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled, cannot disable this setting during build https://ticket.coreboot.org/issues/499#change-1569 * Author: Oberon 4071 * Status: New * Priority: Normal * Assignee: Nico Huber * Start date: 2023-06-29 * Affected versions: 4.21 * Needs backport to: none * Affected hardware: lenovo/t440p coreboot revision in git: feb27dcbf3fc685b070c950a16e8adec958bc1ce coreboot revision (git describe --tags): 4.20-520-gfeb27dcbf3 Tested payloads: edk2 from MrChromebox revision uefipayload_202304 and uefipayload_202306 coreboot will not boot my Lenovo ThinkPad T440p with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled, when using the edk2 payload (MrChromebox version, either uefipayload_202304 or uefipayload_202306). The display sometimes turns on, indicating that some of the hardware initialization was successful, but the payload will not start. I tried to disable CONFIG_RESOURCE_ALLOCATION_TOP_DOWN in .config, but the build process insists on leaving this config enabled. This seems to be caused by the RESOURCE_ALLOCATION_TOP_DOWN setting changed to "def_bool y" in src/device/Kconfig in commit 5226301765ded70e0ef640e5252bbaca8cd14451 (allocator_v4: Treat above 4G resources more natively). The make target for building coreboot seems to automatically rerun olddefconfig, causing this setting to always remain enabled no matter what was previously saved in the .config file. Modifying src/device/Kconfig to change RESOURCE_ALLOCATION_TOP_DOWN to "def_bool n" appears to fix the problem on my machine. I have attached my .config file (with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled to reproduce the problem). ---Files .config (20.7 KB) console.log (128 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #499] coreboot will not boot edk2 on Lenovo T440p with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled, cannot disable this setting during build
Issue #499 has been updated by Nico Huber. > Modifying src/device/Kconfig to change RESOURCE_ALLOCATION_TOP_DOWN to > "def_bool n" appears to fix the problem on my machine. The cannonical way would be to add a `default n` to the mainboard or northbridge Kconfig. However, fixing the bug would be really preferred. Bug #499: coreboot will not boot edk2 on Lenovo T440p with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled, cannot disable this setting during build https://ticket.coreboot.org/issues/499#change-1566 * Author: Oberon 4071 * Status: New * Priority: Normal * Assignee: Nico Huber * Start date: 2023-06-29 * Affected versions: 4.21 * Needs backport to: none * Affected hardware: lenovo/t440p coreboot revision in git: feb27dcbf3fc685b070c950a16e8adec958bc1ce coreboot revision (git describe --tags): 4.20-520-gfeb27dcbf3 Tested payloads: edk2 from MrChromebox revision uefipayload_202304 and uefipayload_202306 coreboot will not boot my Lenovo ThinkPad T440p with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled, when using the edk2 payload (MrChromebox version, either uefipayload_202304 or uefipayload_202306). The display sometimes turns on, indicating that some of the hardware initialization was successful, but the payload will not start. I tried to disable CONFIG_RESOURCE_ALLOCATION_TOP_DOWN in .config, but the build process insists on leaving this config enabled. This seems to be caused by the RESOURCE_ALLOCATION_TOP_DOWN setting changed to "def_bool y" in src/device/Kconfig in commit 5226301765ded70e0ef640e5252bbaca8cd14451 (allocator_v4: Treat above 4G resources more natively). The make target for building coreboot seems to automatically rerun olddefconfig, causing this setting to always remain enabled no matter what was previously saved in the .config file. Modifying src/device/Kconfig to change RESOURCE_ALLOCATION_TOP_DOWN to "def_bool n" appears to fix the problem on my machine. I have attached my .config file (with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled to reproduce the problem). ---Files .config (20.7 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #499] coreboot will not boot edk2 on Lenovo T440p with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled, cannot disable this setting during build
Issue #499 has been updated by Nico Huber. Assignee set to Nico Huber Could you get a coreboot log of the failing boot? If nothing else is available, CONFIG_CONSOLE_SPI_FLASH might work. Bug #499: coreboot will not boot edk2 on Lenovo T440p with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled, cannot disable this setting during build https://ticket.coreboot.org/issues/499#change-1565 * Author: Oberon 4071 * Status: New * Priority: Normal * Assignee: Nico Huber * Start date: 2023-06-29 * Affected versions: 4.21 * Needs backport to: none * Affected hardware: lenovo/t440p coreboot revision in git: feb27dcbf3fc685b070c950a16e8adec958bc1ce coreboot revision (git describe --tags): 4.20-520-gfeb27dcbf3 Tested payloads: edk2 from MrChromebox revision uefipayload_202304 and uefipayload_202306 coreboot will not boot my Lenovo ThinkPad T440p with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled, when using the edk2 payload (MrChromebox version, either uefipayload_202304 or uefipayload_202306). The display sometimes turns on, indicating that some of the hardware initialization was successful, but the payload will not start. I tried to disable CONFIG_RESOURCE_ALLOCATION_TOP_DOWN in .config, but the build process insists on leaving this config enabled. This seems to be caused by the RESOURCE_ALLOCATION_TOP_DOWN setting changed to "def_bool y" in src/device/Kconfig in commit 5226301765ded70e0ef640e5252bbaca8cd14451 (allocator_v4: Treat above 4G resources more natively). The make target for building coreboot seems to automatically rerun olddefconfig, causing this setting to always remain enabled no matter what was previously saved in the .config file. Modifying src/device/Kconfig to change RESOURCE_ALLOCATION_TOP_DOWN to "def_bool n" appears to fix the problem on my machine. I have attached my .config file (with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled to reproduce the problem). ---Files .config (20.7 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: How to best handle new Intel Saphire Rapids server boards based on Intel Archer City?
On 21.06.23 04:58, David Hendricks wrote: > On Tue, Jun 20, 2023 at 4:41 PM Peter Stuge wrote: >> ron minnich wrote: >>> And, yes, no question, this is an activity that likely occurs less than it >>> should. Such is our industry. >> >> Such is project policy. Maybe because it's the lowest common >> denominator in industry. > > The project's policy is to remove code that becomes difficult to > maintain, whether due to bitrot or technical barriers to refactoring. I don't see this "becomes difficult to maintain" much. Much of what we removed in the last years had either an unfortunate design (cf. FSP 1.0) and or was already merged in a difficult to maintain state (cf. AGESA). IMO, this is where we should consider to learn from, not just make it policy and go on. >>> It is not possible to know, a priori, what those common pieces will be. >> >> I think this is where we fundamentally disagree. I think common >> pieces and their interfaces can be recognized based on the hard >> IP blocks and their interfaces plus some creative thinking based >> on development experience. > > I'm pretty sure the Intel engineers who wrote the Archer City CRB code > didn't have IBM's and ByteDance's server specs handy or know how they > would use the code. AFAICT, the less board-specific code in archercity_crb/ is platform specific. This may be an important point: FWIW, we focus more on review for the platform code, and are more lax about the board ports. Maybe we should try to keep an eye on it, so that platform code doesn't sneak into board ports. A bit OT, and sorry, if this is an odd question: Wasn't this the point of OCP, that they can talk to each other? If it's possible, we could try to talk earlier about the code, before it's written and pushed upstream later. Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: How to best handle new Intel Saphire Rapids server boards based on Intel Archer City?
On 21.06.23 01:23, ron minnich wrote: > The approach in the last 24 years (of this unsustainable project :-) has > been to get several mainboards of a type, and, once we have them, try to > work out what code is truly common and what code is similar but not truly > common. AFAICT, for the last 5~8 years, this has not been the case. > Code that is truly common can then be factored out into places such as > src/lib. Code then migrates out of specific mainboards and into common > spaces. This progression has happened many times. > > And, yes, no question, this is an activity that likely occurs less than it > should. Such is our industry. Saying our industry is like that is why our industry is like that. Many people don't try to optimize the process just because that's how the process has been, even when there are low-hanging fruits that could help. Felix H. has shown good examples [1] how to optimize the process for a silicon vendor. I don't see why that wouldn't be possible else- where. Quite interesting to see, how the diligence of one individual makes things possible that "our industry" can only dream of. > It is not possible to know, a priori, what those common pieces will be. So > we are left with this admittedly non-ideal situation. IMO, it is possible, when people talk about it. > There is the further risk (this has happened) that a seemingly harmless > change is discovered to break some board, 1.5 years later. This has > happened. To me. >From my point of view, this is an argument to not refactor later, but as early as possible. Ideally before board ports are merged, because then the known good state is the known maintainable state. Nico [1] https://www.osfc.io/2022/talks/exploring-approaches-to-add-firmware-support-for-new-socs-to-coreboot/ ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: How to best handle new Intel Saphire Rapids server boards based on Intel Archer City?
On 21.06.23 01:07, Peter Stuge wrote: > (sorry if you receive this twice) > > David Hendricks wrote: >> it will be easier to refactor portions of the code with the large >> patches merged in a buildable and (hopefully) usable/testable state. > > That's pretty weak sauce and I think you all know deep down. Let's not lose the scope here, please. AFAICT, we are still talking about particular mainboard ports that share, beside boilerplate, maybe 50~70 lines of code. From my point of view, we have much much bigger problems elsewhere. > Who pays for refactoring? Probably someone else. > > That's unsustainable for the project. If we'd make what is said about this case a general rule, maybe yes. But I don't see that David would have implied this. Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: How to best handle new Intel Saphire Rapids server boards based on Intel Archer City?
On 19.06.23 23:01, Paul Menzel wrote: > Am 19.06.23 um 22:31 schrieb Martin Roth: >> Duplicated code between mainboards isn't a big issue in my opinion. >> It allows the boards to be customized without worrying about other >> companies' mainboards. We've tried to make mainboards as small as we >> can, and we can keep refactoring things out where it makes sense. > > Are you talking in general or in this specific SRP boards. As stated by > others, a lot of code was copy-pasted. I don't see this. Maybe I'm too tired, but I only see about 500 lines in `archercity_crb/`. Maybe 300 of them being general boilerplate that one can't escape when adding a new board. There's an IIO header file (142 lines) that looks board specific. The only exception seems to be the already mentioned mainboard_config_ iio() function which looks like something that belongs into platform code (it looks generic with only a few numbers hardcoded that could be added to a struct as well). After all, if I'm not looking at the wrong branch, this looks cleaner than average for coreboot (wrt. copied code, I didn't look at the individual patches). >> If some common code fits under the SoC, that's great, and I'm all for >> moving it there, but let's not force the burden of that refactoring >> work onto inexperienced mainboard maintainers. Doing so just >> encourages vendors to keep their mainboards in private repositories - >> the opposite of what we should be working for. Even if this means >> that it doesn't get refactored and gets a bit out-of-date, I find >> that preferable to making contributors (more) frustrated about >> getting their boards accepted. > > I haven’t seen any frustration. Do you know more? I agree, nobody should > be frustrated. The question has to be answered though, who is going to > do that general maintenance work – I think Kyösti raised a similar > question a few weeks back. I welcome all new contributors, but it has to > be clear, that coreboot – especially for commercial offerings – needs > and expects some kind of maintenance commitment. I am pretty sure, the > vendors are going to understand the benefits. It just has to be > communicated transparently. I agree in general, but in this particular case it seems overzealous. We better save our energy until the next entire SoC code gets copied. Or for the review of these new boards. It seems like a good opportu- nity to teach people about coreboot. Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #478] X200 booting Linux takes a long time with TSC (`clocksource=hpet` works)
Issue #478 has been updated by Nico Huber. Can you provide a dmesg log? or even better, one with coreboot and one with vendor. It's probably just a flag somewhere that's telling Linux to use TSC. But that's easiest debugged in the OS. Bug #478: X200 booting Linux takes a long time with TSC (`clocksource=hpet` works) https://ticket.coreboot.org/issues/478#change-1470 * Author: Robert Gruber * Status: New * Priority: Normal * Target version: master * Start date: 2023-04-04 * Affected versions: 4.15, 4.16, 4.17, 4.18, 4.19, master * Needs backport to: master * Related links: Thank you for reporting this issue. Does booting with `'tsc=unstable` also work? Please the coreboot log messages for example by running `cbmem -1`. * Affected OS: xubuntu 22.04 LTS, Trisquel 11.0 dmesg: TSC found unstable after boot, most likely due to broken BIOS. Use 'tsc=unstable'. After a period of time the boot finished by auto-switching to hpet. Setting kernel parameter directly to clocksource=hpet the system is booting fast. Why is the faster clocksource tsc not working and tells coreboot is broken ? ---Files cbmem.log (38.6 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: How can I set up a userspace test for coreboot code in 2023?
Hi Keith, On 02.04.23 15:33, Keith Hui wrote: > Here is the command line I figured would work, gathered with "make -n": > > gcc -Isrc -Isrc/include -Isrc/commonlib/include > -Isrc/commonlib/bsd/include -Ibuild -I3rdparty/vboot/firmware/include > -include src/include/kconfig.h -include src/include/rules.h -include > src/commonlib/bsd/include/commonlib/bsd/compiler.h -I3rdparty > -D__BUILD_DIR__=\"build\" -Isrc/arch/x86/include -D__ARCH_x86_32__ > -Isrc/device/oprom/include -nostdinc -pipe -g -std=gnu11 -nostdlib > -Wall -Wundef -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings > -Wredundant-decls -Wno-trigraphs -Wimplicit-fallthrough -Wshadow > -Wdate-time -Wtype-limits -Wvla -Wold-style-definition -Wdangling-else > -Wmissing-include-dirs -fno-common -ffreestanding -fno-builtin > -fomit-frame-pointer -fstrict-aliasing -ffunction-sections > -fdata-sections -fno-pie -Wno-packed-not-aligned -fconserve-stack > -Wnull-dereference -Wreturn-type -Wlogical-op -Wduplicated-cond > -Wno-unused-but-set-variable -Werror -Os -Wno-address-of-packed-member > -m32 -fuse-ld=bfd -fno-stack-protector -Wl,--build-id=none > -fno-delete-null-pointer-checks -Wlogical-op -march=i686 -mno-mmx > --param asan-globals=0 -D__RAMSTAGE__ -include build/config.h > src/northbridge/intel/i440bx/raminit.c > src/northbridge/intel/i440bx/raminittest.c -o raminittest2023 > > The C test code is attached. I'm seeing two errors, smbus_read_byte() not being declared and missing. For the former, you should build with -D__ROMSTAGE__ (not R*A*MSTAGE). For the latter, I guess it might be better to compile `raminit.c` with the coreboot include paths and your `raminittest.c` with your host headers, i.e. *without* `-nostdinc` and coreboot paths. If that actually works depends a lot on details; it would be best to compile everything with the host's standard headers and only use those coreboot headers that are coreboot specific. However, both kinds of headers are mixed in coreboot's directory structure and some headers in coreboot that have standard names are actually not standard :-/ With separate compilation, I get to fatal error: standalonetest.h: No such file or directory ;) Cheers, Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Quick question for Kconfig lint checking
Hi Pratik, On 10.03.23 02:19, Prajapati, Pratikkumar V wrote: > For my patch https://review.coreboot.org/c/coreboot/+/71120, the Jenkins > build fails with following error: > > "Check Kconfig files for errors (lint-stable-008-kconfig): #! Error: > 'CONFIG_SOC_INTEL_COMMON_BLOCK_PRMRR_SIZE_2MB' selected at > src/soc/intel/meteorlake/Kconfig:101. Symbols created in a choice cannot be > selected" > > What is the rationale behind enforcing this? As of now, PRMRR Kconfig > settings are in common code and i wanted to set the right size from SOC > specific code. e.g. the patch i mentioned earlier. Quite simple: It doesn't work. Even if the linter didn't complain, a `select` on a choice config wouldn't do anything. That's actually a good thing, IMO, because it helps us to keep Kconfig prompts sane. A choice always has a prompt, e.g. is visible to the integrator in menuconfig. If you could enforce a single option of a choice, it would show a prompt without meaning. > One option i think is to simplify PRMRR Kconfig options (get rid of choice > menu) and define PRMRR_SIZE config option in SOC specific code. That's the big question. Either it's wrong to have a choice and thereby a prompt or it's wrong to enforce a specific selection. I can't tell what it is in your case. Does it really have to be 2MiB? Why would a bigger PRMRR not work for Keylocker? The `select INTEL_KEYLOCKER` also looks odd as that config option also has a prompt. Why would the SoC code make that choice if it was already decided that it should have a prompt? Or was that prompt added by accident? > But then all SOC specific code would have to define this Kconfig option. Not really, we can always set sane defaults at the common/ level. Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Refactoring #460] Make mainboards using the variant concept
Issue #460 has been updated by Nico Huber. I mean `lga1155` and `lga1150` respectively. Refactoring #460: Make mainboards using the variant concept https://ticket.coreboot.org/issues/460#change-1417 * Author: Felix Singer * Status: New * Priority: Normal * Target version: none * Start date: 2023-02-14 * asrock/ivybridge * asrock/b75pro3-m * asrock/h77pro4-m * asrock/haswell * asrock/b85m_pro4 * asrock/h81m-hds -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Refactoring #460] Make mainboards using the variant concept
Issue #460 has been updated by Nico Huber. It's actually quite simple to put an accurate name on it: Use something that is soldered to the mainboard. In case of platform code that supports multiple chipsets, it's usually the CPU socket that they have in common. `lga1155` should work here and similar names are used already in the tree. Refactoring #460: Make mainboards using the variant concept https://ticket.coreboot.org/issues/460#change-1416 * Author: Felix Singer * Status: New * Priority: Normal * Target version: none * Start date: 2023-02-14 * asrock/ivybridge * asrock/b75pro3-m * asrock/h77pro4-m * asrock/haswell * asrock/b85m_pro4 * asrock/h81m-hds -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: cross-repo-cherrypick and re-writing Signed-off-by's
Hi Martin, thanks for your reply. On 15.01.23 00:36, coreboot org wrote: > Since both branches are actually in the same repo here, I don't think > any change is needed, or actually even desired. My opinion is that if > we cherry-pick between branches at coreboot.org and update those tags, > what happens when it finally does get cherry-picked to a downstream > repo? Original-Original-Signed-off-by? To be fully accurate, it's not the same repo. However, everything is on the same Gerrit instance on coreboot.org. I guess that makes no difference, it's all public and we share the same DCO. Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] cross-repo-cherrypick and re-writing Signed-off-by's
Hi fellow coreboot developers, it was pointed out to me that I didn't do exactly what Chromium developers are used to (i.e. what util/scripts/cross-repo-cherrypick does) when picking patches to flashrom-stable. The major difference is that I didn't prepend Signed-off-by tags with an `Original-`. My reasoning was that it applies to the work in a patch and not the exact commit. We also don't change these tags when clicking Submit in Gerrit which also triggers a cherry- pick. Prepending the `Original-` to all the tags that are automatically added by Gerrit makes perfect sense to me, OTOH. So here's the question: Is there a particular reason that `cross-repo-cherrypick` prepends the Signed-off-by or is that just done because it treats all tags the same? Cheers, Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Toolchain build on Ubuntu 22.04 fails (at GCC 8.3.0)?
On 08.01.23 17:42, ron minnich wrote: > For reasons I still don't understand, the various linux distros no longer > ship .a as part of the library package. They ship them separately. On Ubuntu, usually a -dev package. I even recall -devel-static packages (-devel was headers only and such) ~20 years back. The reason to ship them separately is simple: not everybody has the space/bandwidth to spare. These habits are decades old. Some newer distros moved to ship everything in one package, though. One odd thing about libuuid: The Ubuntu package is called uuid-dev (not libuuid-dev). That's something I don't understand ;) Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Toolchain build on Ubuntu 22.04 fails (at GCC 8.3.0)?
On 07.01.23 23:53, Rafael Send wrote: > If I wanted to try your first suggestion, does the toolchain build > transcend directories? In order to not mix up trees & versions so far I > have just checked out the latest master and the version in question into > two totally separate coreboot folders. Not automatically, but you can point to the .../util/crossgcc/xgcc/bin directory in $XGCCPATH or add it to your $PATH. You can also pull out the whole xgcc/ dir, so it doesn't live in a specific tree checked out. Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Toolchain build on Ubuntu 22.04 fails (at GCC 8.3.0)?
Hi Rafael, On 07.01.23 22:03, Rafael Send wrote: > I didn't downgrade the toolchain intentionally, I'm looking to build a fork > of coreboot for a specific platform (mjg59's X2100 port) that never got > upstreamed. After pulling his repo at > https://github.com/mjg59/coreboot/tree/x2100_ng, that is what it wants to > build with. if you want open-source pre-OS display, you need the Ada compiler. You could build the current toolchain with a checkout of coreboot master and then try to build for this board with it. You could also try to build with your host toolchain (CONFIG_ANY_TOOLCHAIN, should be in the "General" Kconfig menu). Alas, GCC doesn't officially support building an older version with a newer one. It usually works, but the Ada frontend often needs a little help. Hence we only maintain that for the latest coreboot. It's probably easier to use the newest toolchain. Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Status of maintained boards and policies?
Hi Denis, On 05.01.23 18:03, Denis 'GNUtoo' Carikli wrote: > On Wed, 4 Jan 2023 09:58:59 -0700 > Nicholas Chin wrote: >>> And given that there is no way to guarantee that a Mainboard doesn't >>> get removed, we'd also need to watch what is happening with the GM45 >>> Thinkpads as well, as this problem also affect these computers. >> >> Could you elaborate on this? I'm not aware of any planned changes >> that would result in GM45 being dropped. Is it just about finding >> people to provide support for those boards/chipset? And if so, does >> the same not apply to other older chipsets like i945 or x4x? Or even >> Sandy/Ivy Bridge? > Maintained boards/computers can be removed (that happened to the APU1), > because the fact that a computer is maintained only gives some > guarantees that patches will be reviewed. I guess the question was why you were pointing at GM45 in particular. I'm wondering, too. Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Status of maintained boards and policies?
Hi Denis, On 04.01.23 17:33, Denis 'GNUtoo' Carikli wrote:> On Wed, 4 Jan 2023 04:37:01 +0100 (CET) > Martin Roth wrote: >> I think you're right that we need some way to guarantee that boards >> added to coreboot aren't going to be dropped again in a short period >> of time, but that requires investment from companies using coreboot >> to make sure that it happens. > The investment could also come from the people and organizations that > want the boards to stay in Coreboot. My questions were mainly directed > at trying to understand how much resources that would require to see if > this is doable or not. I believe the best investment can be made by the author/uploader of the chipset code, before and during review. AFAICT, the reason why individual platforms in the coreboot tree are treated very differently wrt. maintenance and deprecation is mostly because of very different levels of code quality. Judging from the code I've seen that was moved away over the years, I guess review must have been more lax when that code was originally added. To mention only the latest revelation: The coreboot code to integrate AGESA apparently copied more code than necessary [1] from the previous, native K8 port. This was discovered only after a decade of cleaning that code up. If code is in such a state, nobody can fully understand it. And then naturally, nobody wants to touch it and adapt it when changing something at the heart of coreboot. IMO, what you need if you want to ensure that platform support stays, is code that is readable and understandable. Tight code, that only does what is necessary is a bonus. Understanding the code should start at the uploader side. Copy-pasting, or reverting a code drop can't help there. If the uploader understands the code, it's easier to prepare it for review and there's a chance that the reviewer can understand it too and probably can help to make it even easier to be understood. If you get there, I'm sure, much fewer people would hesitate to keep the code up-to-date. I've always estimated that it would take about $200k to get there for any of the older AMD platforms (assuming you can get experienced core- boot developers to do it). But once reasonable code for one platform would be written, the others should be a piece of cake in comparison. > > There are people and organizations who want the Asus KGPE-D16 to > continue to be supported in some form, so we are currently evaluating > our options with that, with the constraint that the code needs to keep > working over time. And upstream Coreboot is one of the options being > evaluated. > > A French association (Libre en Communs) already applied for funding > through NLnet to bring The KGPE-D16 back to upstream Coreboot. > > So if this is accepted, we will also need a plan to make sure that the > board isn't removed again. And for that we'd need not only to review > patches, but also to actually get work done so it doesn't get removed > again. > > So for instance we could get donations through an association to fund > someone to keep the board supported, but to do that we do need to have > at least a vague idea of the budget required for that. I guess nobody can estimate the budget for that because it depends heavily on the state of the code when it would be re-added. I haven't followed up on the latest work around the fam15h support. Was it re- written or is it still based on the old, dropped code? But to provide a rough idea: If the code was still in the state as it was when dropped, I'd say it's a full-time job to keep it main- tained. >> When a chip is added to coreboot, how long is a company expected to >> maintain that chip in the coreboot repository? If we make it too >> short, nobody wants to develop mainboards for it. If we make that >> time too long, chip vendors aren't going to want to add their chips >> to the tree. I'm not sure how to balance that. > To keep supporting a given mainboard, I only know these options: > - Do like Linux and put the burden on people sending patches not to > break the existing mainboards. This reduces the amount of work > needed to maintain a given mainboard, but it still requires > maintainers. IMO this is the way to go. I'm convinced, if the initial investment is good enough, it can reduce the maintenance burden by orders of magnitude. > - Doing it like it's done now, putting most of the burden on people > wanting to continue maintaining existing mainboards, but making it > easier to cleanup code and add new mainboards. It seems you are forgetting one group of people: those who want to actively continue coreboot. Same as Linux, we want to keep everything in the tree up to date. However, that's only possible if the code shows some degree of soundness. These people have carried most of the burden over the last years, AFAICT. > > U-boot is probably somewhere in between both. > > Another option would be to have different rules for different code > quality. For instance require
[coreboot] Re: FSP 2.4: runtime blobs!
Hi Arthur, coreboot fellows, On 30.09.22 13:53, Arthur Heymans wrote: > What are your thoughts? printing, bonfire... > Do we take a stance against FSP-I integration in coreboot? I think we already do. From coreboot.org: "coreboot is an extended firmware platform that delivers a lightning fast and secure boot experience on modern computers and embedded systems. As an Open Source project it provides auditability and maximum control over technology." FSP-I means exactly the opposite of most of the above points. It's inherently incompatible. IMO, unless we discuss if we want to change how we define coreboot first, there can't be a discussion about integrating FSP-I nor any action in that direction. > Are there precedents where blobs runtimes are installed on the main CPU, > that I don't know of which could justify FSP-I? There's something for the main CPU but definitely not the same: I was told AMD's binary pi can provide runtime ACPI code. But running ACPI is an opt-in for the OS, whilst FSP-I wouldn't even allow an opt-out, I guess. > > P.S. It's quite sad to see this happen after an open letter 361 people > signed for a more open FSP. > https://openletter.earth/adopting-open-source-firmware-approach-for-intel-fsp-59d7a0c6 Sad, but not unexpected. I believe this is part of a more than a decade old strategy. It seems to me Intel never really supported open-source OS drivers for their server platforms. They just hid everything in SMM with a nice open-source facade for Linux. We turned a blind eye to that. Now it seems that the ecosystem around Intel servers is rather unprepared for open source. Even if they'd open up their SMM code, it would just be wrong to keep the code in SMM, IMO. Proper OS drivers should be written instead. Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: LPC problem in Coreboot for Apollo Lake
Hello Roman, On 09.09.22 17:48, roman perepelitsin wrote: > I use coreboot for ApolloLake CPU (Atom). We have SuperIO WB83627-DHG chip > on carrier board. LPC enabled, POST codes work normal. But I can't get > access to SIO under Linux (via port 0x2e). Superiotool can't find chip. > Also, I have CPLD on LPCB - I use it to view LPC transactions - so, then I > try to out byte to 0x2e - transaction on LPC is none. But, I enable UART0 > on SIO (via devicetree.cb) - and it works fine. Whats wrong? the W83627DHG has the UART enabled by default, so it's still possible that coreboot can't access 0x2e either. Do you have a setting for `lpc_ioe` in your devicetree? It's easier to help if you'd show your complete mainboard port. Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #415] RESOURCE_ALLOCATION_TOP_DOWN breaks booting
Issue #415 has been updated by Nico Huber. File t500.log added File hermes.log added Bug #415: RESOURCE_ALLOCATION_TOP_DOWN breaks booting https://ticket.coreboot.org/issues/415#change-1094 * Author: Sean Rhodes * Status: New * Priority: Low * Target version: none * Start date: 2022-09-07 * Affected versions: master CB:41957 enabled RESOURCE_ALLOCATION_TOP_DOWN by default, which stopped edk2 from booting. The commit has been reverted, so this ticket is just to post logs. ---Files resource_allocatorv4.txt (94 KB) up_squared.log (47.9 KB) hermes.log (575 KB) t500.log (585 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #415] RESOURCE_ALLOCATION_TOP_DOWN breaks booting
Issue #415 has been updated by Nico Huber. File up_squared.log added Bug #415: RESOURCE_ALLOCATION_TOP_DOWN breaks booting https://ticket.coreboot.org/issues/415#change-1093 * Author: Sean Rhodes * Status: New * Priority: Low * Target version: none * Start date: 2022-09-07 * Affected versions: master CB:41957 enabled RESOURCE_ALLOCATION_TOP_DOWN by default, which stopped edk2 from booting. The commit has been reverted, so this ticket is just to post logs. ---Files resource_allocatorv4.txt (94 KB) up_squared.log (47.9 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #415] RESOURCE_ALLOCATION_TOP_DOWN breaks booting
Issue #415 has been updated by Nico Huber. Subject changed from RESOURCE_ALLOCATION_TOP_DOWN breaks booting (edk2) to RESOURCE_ALLOCATION_TOP_DOWN breaks booting Bug #415: RESOURCE_ALLOCATION_TOP_DOWN breaks booting https://ticket.coreboot.org/issues/415#change-1092 * Author: Sean Rhodes * Status: New * Priority: Low * Target version: none * Start date: 2022-09-07 * Affected versions: master CB:41957 enabled RESOURCE_ALLOCATION_TOP_DOWN by default, which stopped edk2 from booting. The commit has been reverted, so this ticket is just to post logs. ---Files resource_allocatorv4.txt (94 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #415] RESOURCE_ALLOCATION_TOP_DOWN breaks booting (edk2)
Issue #415 has been updated by Nico Huber. Subject changed from RESOURCE_ALLOCATION_TOP_DOWN breaks booting (-edk2-) to RESOURCE_ALLOCATION_TOP_DOWN breaks booting (edk2) Bug #415: RESOURCE_ALLOCATION_TOP_DOWN breaks booting (edk2) https://ticket.coreboot.org/issues/415#change-1091 * Author: Sean Rhodes * Status: New * Priority: Low * Target version: none * Start date: 2022-09-07 * Affected versions: master CB:41957 enabled RESOURCE_ALLOCATION_TOP_DOWN by default, which stopped edk2 from booting. The commit has been reverted, so this ticket is just to post logs. ---Files resource_allocatorv4.txt (94 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #415] RESOURCE_ALLOCATION_TOP_DOWN breaks booting (-edk2-)
Issue #415 has been updated by Nico Huber. Subject changed from RESOURCE_ALLOCATION_TOP_DOWN breaks edk2 to RESOURCE_ALLOCATION_TOP_DOWN breaks booting (-edk2-) It turned out that there are a lot of platforms in the tree that still don't report their fixed resources correctly. These should be added inside `.read_resources` of device drivers. This commit[1] provides an example how it can look like. Sometimes * `.read_resources` is simply missing for a device, or * the device driver is not considered because a PCI device ID is missing, or * the device driver is accidentally disabled in the mainboard devicetree. One common mistake is not to reserve the memory-mapped "BIOS" flash. Integrated resources that are handled by blobs can also be easily forgotten (at least Intel provides documentation about the complete memory map, though). When resources are not reported, the allocator can cause conflicts with them. This can happen already by chance; chances are higher when space is tight. Also, the OS needs to be made aware of such resources or might run into the same problem (alas, this is not tied to `.read_resources` in coreboot but needs additional ACPI code at the moment). [1] https://review.coreboot.org/c/coreboot/+/64077 Bug #415: RESOURCE_ALLOCATION_TOP_DOWN breaks booting (-edk2-) https://ticket.coreboot.org/issues/415#change-1090 * Author: Sean Rhodes * Status: New * Priority: Low * Target version: none * Start date: 2022-09-07 * Affected versions: master CB:41957 enabled RESOURCE_ALLOCATION_TOP_DOWN by default, which stopped edk2 from booting. The commit has been reverted, so this ticket is just to post logs. ---Files resource_allocatorv4.txt (94 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #412] x230 reboots on suspend
Issue #412 has been updated by Nico Huber. ``` [ERROR] SF size 0xc0 does not correspond to CONFIG_ROM_SIZE 0x40!! ``` `CONFIG_ROM_SIZE` needs to cover both chips. It's a known issue that coreboot will write the MRC cache at the wrong offset otherwise. As reading happens memory-mapped (not with manual SPI flash commands) it will use a different offset then. The cache is needed to bring DRAM up without destroying memory contents (would be bad during resume). Bug #412: x230 reboots on suspend https://ticket.coreboot.org/issues/412#change-1082 * Author: Carson Alberding * Status: New * Priority: Normal * Target version: none * Start date: 2022-09-02 * Affected versions: master * Related links: https://ticket.coreboot.org/issues/393 * Affected hardware: x230 * Affected OS: windows/arch linux Very similar to issue 393 where the x230 reboots when suspended to RAM. Seems to be an issue with coreboot v4.16 & 4.17 or something is missing in the config (attached). Any insight on this would be appreciated! ---Files coreboot_config.txt (18.8 KB) normal_boot.txt (48.1 KB) suspend_boot.txt (48 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Coffee Lake Refresh RVP11 + Integrated graphics initialisation + Uefipayload
Hi, On 25.08.22 08:53, Moorthi M.s wrote: > Hi Nico, > >> did you get that from the binary or from the running system? It's >> possible that your BIOS patches it at runtime, and the one in flash might >> be unusable. On Linux, you can find the active VBT in debugfs, usually >> `/sys/kernel/debug/dri/0/i915_vbt`. > > I have added the VBT file copied from the running system (fedora 30). Still > the graphics is not up. that is unfortunate. But knowing that this VBT actually works when booting with another firmware can give us more clues. You could get a debug log from the working boot and compare that to a failing one. Add this to your kernel command line: `drm.debug=0xe`. It will make the i915 driver very chatty. > >> Note, for Coffee Lake there's an open-source alternative[1]. It needs > a little per-board configuration, but then usually works out of the box. > > I tried using the libgfxinit for graphics initialisation. With that the > graphics is up and i am able to see the Uefipayload screen output in the > display. Thanks for your guidance. > I'm glad to hear that :) > Is there anything need to be added in coreboot to invoke the integrated > graphics driver in the OS? > But i tried booting the Operating System (windows 10 & fedora 30) after the > selecting the operating system in the grub, nothing came in the display. You might still need a valid VBT for Intel's OS drivers. If you had it in your coreboot image already, comparing logs might be the best next step. With the VBT, Linux' i915 driver should be capable to fully ini- tialize the display even if the firmware did nothing. Cheers, Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Coffee Lake Refresh RVP11 + Integrated graphics initialisation + Uefipayload
Hi Moorthi, On 19.08.22 07:32, Moorthi M.s wrote: > I have also extracted and added the vbt.bin from BIOS to coreboot. did you get that from the binary or from the running system? It's possible that your BIOS patches it at runtime, and the one in flash might be unusable. On Linux, you can find the active VBT in debugfs, usually `/sys/kernel/debug/dri/0/i915_vbt`. > For graphics initialisation, i selected "Run a GOP driver" and for Note, for Coffee Lake there's an open-source alternative[1]. It needs a little per-board configuration, but then usually works out of the box. And in case it doesn't work, it comes with extensive logging and debug capabilities, down to attaching a debugger in Linux user-space. > And i checked the debug prints, there it is mentioned as "GMA: Found valid > VBT in CBFS" and in the next line "Graphics hand-off block not found". > > From the above prints i assume that the vbt.bin is proper but still the FSP > is not returning the graphics HOB. Alas, that is not enough to tell if the VBT is correct. However, if you extracted it from a running system where the display came up, it should be. In any case, you can examine the file with `intel_vbt_decode` from `intel-gpu-tools`. The most important part is that the DP you are trying to use is enabled. > Is there any other configurations need to be done with respect to > integrated graphics? Are you using vboot by any chance? It's the only other thing in the code that I see that should make a difference. You could have another look at the log, there's another printk earlier "Found a VBT of %zu bytes after decompression\n" That would either come directly before the lines you mentioned above (if the GOP is not executed), or much earlier (if executed). Nico [1] https://doc.coreboot.org/gfx/libgfxinit.html ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Issue tracker version update / disabling of login methods
On 12.08.22 14:04, Sam Kuper wrote: > On Thu, Aug 04, 2022 at 10:26:25PM +, Felix Singer wrote: >> However, I have an idea for a solution. I took a look at the Redmine >> database and I played around with the Google login method. My tests >> showed that it creates a normal user account, as it is done with the >> registration, just with the little difference that no password is set >> disabling the login over password. These accounts also have an user >> name and an email address. As soon as I set a password, I was able to >> login using the user name. >> >> So, my idea is that we just go with these changes and affected users >> use the functionality to reset their password, which means they will >> have a "normal" user account then. In preparation to that version >> update, we should disable these login methods so that no new users will >> make use of them. >> >> Other ideas? What's your opinion? Felix, I guess you know my opinion already: Whoever maintains the service should decide. If there's already a password database, responsibilities (e.g. to inform everybody in case of a breach) won't change. So it sounds like making password-based logins the only option would reduce chore on your end. And nobody objected, so please go ahead :) > > I'm a bit unclear what you are proposing. > > I'm also unclear whether, under your proposal, users without Google > accounts would be able to register or log in to the Redmine instance. > > Please can you clarify? Currently one can login either with OpenID, a Google account or with a password that is stored on our Redmine host. With the intended changes, everybody will have to use a password. Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Heads up: Allocator changes
On 25.06.22 22:05, Nico Huber wrote: > Reasons for the changes are somewhat the same as always: we haven't > finished the support for 64-bit resources. Currently one has to opt > in for a placement above 4G with a resource flag, and even this has > its limitations. For instance, reserved space for hot-pluggable de- > vices can be placed above 4G with a Kconfig setting, but there's no > rule what should happen with the resources of cold-plugged devices. > In the worst case, allocation for those can fail. After some discussions on IRC, a potential default solution started to shape itself. The goal is to have a common, still simple scheme that doesn't run out of resources easily, but also allows to boot with 32-bit coreboot and payloads, so: Place every prefetchable resource above 4G that supports it, except optionally the resources of the primary VGA device. For prefetchable resources of hotpluggable devices, this is already the default. The primary VGA device usually has its framebuffer in a prefetchable resource. It is required below 4G for access from 32-bit coreboot and 32-bit payloads. However, on some platforms like servers, it's infea- sible to have it below 4G due to space constraints. So this would de- finitely require a Kconfig, probably with a prompt and default n for server platforms. That's so far the bare minimum I expect we would need. Additional Kconfig options are imaginable. However, I would prefer to add as few as possible. For better compatibility with 32-bit payloads: * Opt-out for everything "onboard". * Opt-outs for other device classes that one might want to boot from in 32-bit mode: - Storage (RAID controllers mostly) - Network Note, these can have, but often don't have prefetchable resources. * Alternatively to opt-out options, an option for additional allocator rounds that try to move resources from above 4G to below 4G (poten- tially with a priority based on the device class). If somebody wants to keep the current behavior, the following, but please speak up early(!) as this would make the code more complex: * An option to keep the current default to place resources only above 4G on request. If we add this, we would also - keep the current PCIEXP_HOTPLUG_PREFETCH_MEM_ABOVE_4G, and - potentially extend it to cover everything behind a hot-pluggable port explicitly (currently that's implied by the implementation, but not documented). Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Image size and cpu-flash addresses.
Hi Pedro, On 06.08.22 18:45, Pedro Erencia wrote: > I was going to try coreboot on an ASROCK FM2A88X Extreme4+ ( > https://www.asrock.com/mb/AMD/FM2A88X%20Extreme4+/) with the configuration > of the supported ASUS A88XM-E ( > https://doc.coreboot.org/mainboard/asus/a88xm-e.html) which has the same > chipset (A88X Bolton). to repeat Paul's warning: A coreboot build is very board specific. There's a chance that it boots, but there's also a chance that some hardware breaks. The chance that everything works OOB is probably lower. > The fact is that, at this moment, I only have a 16 MiB flash, while the > image is 8 MiB. As the chipset claims that it > “Supports a maximum SPI ROM size of 16MB” I think there should be no > problem, but I wonder how I have to burn the image. That led me to the > question of how the translation between CPU and flash addresses are done. > For supporting various ROM sizes, I guess the controller should somehow > know the size of the ROM, but I don't see anywhere where that could be > specified. > The only thing I found is this stack overflow question ( > https://stackoverflow.com/questions/60200796/how-does-processor-read-bios-from-spi-flash). > There, flash descriptors and some straps are mentioned to provide the ROM > size, but none of those methods are mentioned on the Bolton Datasheet. > So I have two questions here, > 1. How should I burn the 8 MiB image on the 16 MiB flash? > 2. Out of curiosity, how is the cpu-flash address translation done? You are right that it's not explicitly configured. It's a simple trick: If you don't know the size you have to start at an offset from one end. For the lower end (address 0) that's simple, every SPI flash starts at address 0. But x86 is very special: The firmware actually starts at the end of the flash. And that's where one details plays a significant role: A SPI flash ignores address bits that it doesn't know. So, when it is asked for data at address 0xf0, it will always return the last 16 bytes (assuming a flash chip that uses commands with 24-bit addresses). The size of the chip doesn't matter, a 1MiB chip would simply ignore the 4 most-significant address bits. Before SPI flash, the logic was in the flash chip itself, AIUI. The chips were on the memory bus and knew they should reply to requests in the range 0x1-flashsize..0x. Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: [BUG?] objcopy extracts a wrong section of cbfs_master_header.c
Hello Petr, thanks for reporting this. Are you using your host toolchain to build coreboot by any chance (CONFIG_ANY_TOOLCHAIN)? or do you use `make crossgcc*`? On 10.07.22 05:40, Petr Cvek wrote: > but on my setup there is no ORBC magic ID. Instead it seems a > ".note.gnu.property" > section has been copied by objcopy into the final image (conincidentally it is > the last section in the object file too). > > Does anybody have the same problem? The missing header will cause seabios to > fail to > detect secondary payloads (ex. memtest and nvramcui) and probably the rest of > CBFS stuff > too. > > My binutils version is 2.38 (exactl version is: GNU objcopy version > 2.38-slack151). > But for coreboot 4.16 the image seems to be compiled correctly (so the > problem would be > only with a singular object file?). I've heard about `objcopy -O binary` copying .note sections before. So it might rather be the compiler or linker that makes the difference in your case (because it emits that .note which is unexpected). > > I was able to force the correct section copy by changing the Makefile.inc > near this code: > > cbfs-files-processor-struct= \ > $(eval $(2): $(1) $(obj)/build.h $(obj)/fmap_config.h > $(KCONFIG_AUTOHEADER); \ > printf "CC+STRIP $(1)\n"; \ > $(CC_ramstage) -MMD $(CPPFLAGS_ramstage) $(CFLAGS_ramstage) > --param asan-globals=0 $$(ramstage-c-ccopts) -include $(KCONFIG_AUTOHEADER) > -MT $(2) -o $(2).tmp -c $(1) && \ > - $(OBJCOPY_ramstage) -O binary --set-section-flags > .bss*=alloc,contents,load $(2).tmp $(2); \ > + $(OBJCOPY_ramstage) -O binary --only-section=.data.* > --set-section-flags .bss*=alloc,contents,load $(2).tmp $(2); \ I'm not an expert on ELF sections. But given that this is about very simple C structs, I guess adding the following should be safe: --only-section='.data*' --only-section='.bss*' That should also catch all-0 structs. Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #343] Fails to load GRUB payload: CPU Index 0 - APIC 0 Unexpected Exception:6 @ 10:00009016 - Halting
Issue #343 has been updated by Nico Huber. I think this is related: https://review.coreboot.org/c/coreboot/+/64235 Bug #343: Fails to load GRUB payload: CPU Index 0 - APIC 0 Unexpected Exception:6 @ 10:9016 - Halting https://ticket.coreboot.org/issues/343#change-1024 * Author: Paul Menzel * Status: New * Priority: Normal * Start date: 2022-03-30 coreboot emulation/qemu-i440fx is unable to load GRUB payload. It works with SeaBIOS. ``` FMAP REGION: COREBOOT Name Offset Type Size Comp cbfs master header 0x0cbfs header32 none fallback/romstage 0x80 stage 21944 none fallback/ramstage 0x56c0 stage 62048 LZMA (139536 decompressed) config 0x14980raw 428 none revision 0x14b80raw 716 none build_info 0x14e80raw 112 none fallback/dsdt.aml 0x14f40raw 4044 none cmos_layout.bin0x15f40cmos_layout 640 none fallback/postcar 0x16200stage 23328 none fallback/payload 0x1bd80simple elf 460906 none (empty)0x8c640null 3603556 none bootblock 0x3fc2c0 bootblock 15104 none ``` ``` […] [NOTE ] coreboot-4.16-415-ga84c00c9ce Wed Mar 30 01:18:14 UTC 2022 ramstage starting (log level: 7)... […] [INFO ] Timestamp - selfboot jump: 965162845 [EMERG] CPU Index 0 - APIC 0 Unexpected Exception:6 @ 10:9016 - Halting [EMERG] Code: 0 eflags: 00010002 cr2: [EMERG] eax: ebx: 3ffbdc18 ecx: 0001ac27 edx: 00ff [EMERG] edi: 3ffbdc00 esi: 3ffbdbf0 ebp: 01e4 esp: 3ffc3fbc [EMERG] 0x8fd0:00 00 00 00 00 00 00 00 [EMERG] 0x8fd8:00 00 00 00 00 00 00 00 [EMERG] 0x8fe0:00 00 00 00 00 00 00 00 [EMERG] 0x8fe8:00 00 00 00 00 00 00 00 [EMERG] 0x8ff0:00 00 00 00 00 00 00 00 [EMERG] 0x8ff8:00 00 00 00 00 00 00 00 [EMERG] 0x9000:52 52 68 27 ac 01 00 6a [EMERG] 0x9008:0b e8 5e cd 00 00 83 c4 [EMERG] 0x9010:10 a0 00 00 00 00 0f 0b [EMERG] 0x9018:51 51 68 6a a2 01 00 6a [EMERG] 0x9020:0b e8 46 cd 00 00 83 c4 [EMERG] 0x9028:10 eb e6 90 bc f0 ff 07 [EMERG] 0x9030:00 e9 c7 d7 00 00 66 90 [EMERG] 0x9038:02 b0 ad 1b 02 00 00 00 [EMERG] 0x9040:fc 4f 52 e4 55 57 56 53 [EMERG] 0x9048:83 ec 1c 8b 5c 24 30 8b [EMERG] 0x3ffc4038:0x0002 [EMERG] 0x3ffc4034:0x0003 [EMERG] 0x3ffc4030:0x [EMERG] 0x3ffc402c:0x [EMERG] 0x3ffc4028:0x [EMERG] 0x3ffc4024:0x [EMERG] 0x3ffc4020:0x [EMERG] 0x3ffc401c:0x [EMERG] 0x3ffc4018:0x [EMERG] 0x3ffc4014:0x [EMERG] 0x3ffc4010:0x [EMERG] 0x3ffc400c:0x [EMERG] 0x3ffc4008:0x [EMERG] 0x3ffc4004:0x [EMERG] 0x3ffc4000:0x [EMERG] 0x3ffc3ffc:0x [EMERG] 0x3ffc3ff8:0x3ffbd4e8 [EMERG] 0x3ffc3ff4:0xdeadbeef [EMERG] 0x3ffc3ff0:0xdeadbeef [EMERG] 0x3ffc3fec:0x3ff9e061 [EMERG] 0x3ffc3fe8:0x3ffa1f19 [EMERG] 0x3ffc3fe4:0x00018f20 [EMERG] 0x3ffc3fe0:0x3ffdcfd4 [EMERG] 0x3ffc3fdc:0x3ffc4000 [EMERG] 0x3ffc3fd8:0x3ffd63ac [EMERG] 0x3ffc3fd4:0x [EMERG] 0x3ffc3fd0:0x3ffa1fe5 [EMERG] 0x3ffc3fcc:0x3ffa2139 [EMERG] 0x3ffc3fc8:0x3ffbdc24 [EMERG] 0x3ffc3fc4:0x3ffa4303 [EMERG] 0x3ffc3fc0:0x3ff95000 [EMERG] 0x3ffc3fbc:0x3ffac8e4 <-esp ``` ---Files coreboot.log (17.2 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Heads up: Allocator changes
Hi coreboot fellows, after two years with the new resource allocator it's time again for some changes[1]. Much less invasive than last time, but again there will be changes in the pattern where resources are placed. So once more this may uncover bugs in case fixed resources are not reserved properly. Reasons for the changes are somewhat the same as always: we haven't finished the support for 64-bit resources. Currently one has to opt in for a placement above 4G with a resource flag, and even this has its limitations. For instance, reserved space for hot-pluggable de- vices can be placed above 4G with a Kconfig setting, but there's no rule what should happen with the resources of cold-plugged devices. In the worst case, allocation for those can fail. Another reason are approaching changes to support multiple PCI host bridges and multiple resource windows per domain. I digress... So everybody is invited to test the patch train. There is a new Kconfig option RESOURCE_ALLOCATION_TOP_DOWN. The default y should work fine, though in case of regressions it would be nice to have it tested with both settings. Cheers, Nico [1] https://review.coreboot.org/q/topic:allocator+status:open ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Support #387] Support Framework Laptop
Issue #387 has been updated by Nico Huber. Raul Rangel wrote in #note-7: > Just FYI, the board schematics are here: > https://github.com/FrameworkComputer/Mainboard/blob/main/Electrical/Mainboard_Interfaces_Schematic.pdf That's just bits about the connectors, AFAICS. Support #387: Support Framework Laptop https://ticket.coreboot.org/issues/387#change-955 * Author: Jun Aruga * Status: New * Priority: Normal * Category: board support * Target version: none * Start date: 2022-06-05 * Affected hardware: Framework Laptop Dear coreboot developers, I am a user of Framework Laptop[1][2]. Thank you for working to make coreboot work on Framework Laptop! This ticket is to track the task, as I didn't see any other issue tickets about Framework Laptop here. According to the Framework founder's comment[3] below, Framework provided Framework Laptops to the coreboot community. > We've handed three systems that can boot unsigned bootloaders to folks in the > coreboot community. Our plan in the near term is to help them create a shim > loader that can be signed to run on any Framework Laptop, which then enables > anyone to do further coreboot development. Then I saw Matthew's try to make the coreboot work on Framework Laptop,[4] but unfortunately it didn't work at that time.[5] How is the current status? What prevents coreboot from working on the Framework Laptop? How can we, people in the Framework community, help you? As a reference, there is a coreboot specific thread on the Framework community forum.[6] ## References * [1] https://frame.work/ * [2] Framework Computer - Wikipedia - https://en.wikipedia.org/wiki/Framework_Computer * [3] Framework Laptop Mainboard, Hacker News, April 20, 2022 - https://news.ycombinator.com/item?id=31097434 * [4] Matthew tries to port Coreboot to the Framework laptop - February 27, 2022 - https://www.youtube.com/watch?v=Jf_6xW-8tfQ * [5] Matthew Garrett on Twitter, February 27, 2022 - https://twitter.com/mjg59/status/1497788538212917250 * [6] Free the EC! and Coreboot Only - https://community.frame.work/t/free-the-ec-and-coreboot-only/791 -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Support #387] Support Framework Laptop
Issue #387 has been updated by Nico Huber. > Framework controls this key, and has proposed creating both a signed > "official" coreboot image as well as signed shim which would allow user-built > coreboot firmware to be used. I hope they know what they are talking about. I mean such a shim, wouldn't that effectively disable the whole BootGuard feature? It would be most welcome, though. Because without it, it would be very hard for the community to maintain the port (and to be honest, if they make it hard, it won't happen). Alternatively, they could sell units with BootGuard disabled. That would also reduce the amount of blobs needed. > How can we, people in the Framework community, help you? Get them to publish documentation. Or at least get them to offer a reasonable NDA to individuals. Without documentation, the community is unlikely to pick up the maintenance effort and they'll need to constantly pay somebody for it (if the goal is to have upstream coreboot support). Schematics are a minimum. What is controlled by the EC and how is also very valuable information. Without such documentation, one has to be very lucky. If unlucky, it's possible that the initial port costs some $10,000 more. Support #387: Support Framework Laptop https://ticket.coreboot.org/issues/387#change-952 * Author: Jun Aruga * Status: New * Priority: Normal * Category: board support * Target version: none * Start date: 2022-06-05 * Affected hardware: Framework Laptop Dear coreboot developers, I am a user of Framework Laptop[1][2]. Thank you for working to make coreboot work on Framework Laptop! This ticket is to track the task, as I didn't see any other issue tickets about Framework Laptop here. According to the Framework founder's comment[3] below, Framework provided Framework Laptops to the coreboot community. > We've handed three systems that can boot unsigned bootloaders to folks in the > coreboot community. Our plan in the near term is to help them create a shim > loader that can be signed to run on any Framework Laptop, which then enables > anyone to do further coreboot development. Then I saw Matthew's try to make the coreboot work on Framework Laptop,[4] but unfortunately it didn't work at that time.[5] How is the current status? What prevents coreboot from working on the Framework Laptop? How can we, people in the Framework community, help you? As a reference, there is a coreboot specific thread on the Framework community forum.[6] ## References * [1] https://frame.work/ * [2] Framework Computer - Wikipedia - https://en.wikipedia.org/wiki/Framework_Computer * [3] Framework Laptop Mainboard, Hacker News, April 20, 2022 - https://news.ycombinator.com/item?id=31097434 * [4] Matthew tries to port Coreboot to the Framework laptop - February 27, 2022 - https://www.youtube.com/watch?v=Jf_6xW-8tfQ * [5] Matthew Garrett on Twitter, February 27, 2022 - https://twitter.com/mjg59/status/1497788538212917250 * [6] Free the EC! and Coreboot Only - https://community.frame.work/t/free-the-ec-and-coreboot-only/791 -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Deprecation of the Intel Quark SoC
Hi Sheng, On 16.04.22 11:01, Sheng Lean Tan wrote: > Personally I think moving Galileo soc to stable branch is a win-win situation > for all of us. it looks like nobody is maintaining such a stable branch yet. Would you volunteer to maintain one for Quark? AIUI, some people already want to take care of testing. So you'd only have to maintain compatibility with newer toolchain and payload versions and such. > For the enthusiast who still want to use it are freely to do so without the > baggage, and for others it’s a great savings on resources spent, so that we > could leave more rooms (and also testing resources)to the more upcoming > coreboot products and architecture (I think much more will come, the public > has just only warmed up to coreboot ;) ). FWIW, most resources for newer platforms are wasted by copying code (kind of forking the original code in the same repository). So there is much more potential to save resources by adding proper abstraction instead. And what would be better to get the abstractions right than a diverse set of platforms in the tree? I'm not saying, you need Quark for that, but so far I also don't see how it could hurt. Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Deprecation of the Intel Quark SoC
On 12.04.22 23:22, Martin Roth via coreboot wrote: > Apr 12, 2022, 12:14 by f...@mniewoehner.de: >> Maintaining without ability to test will make it degrade, too. >> > Exactly. By moving it to a branch, if someone wants to work on a platform, > they can do it in a more stable environment. I think it depends a lot how you define "degrade" and how the workflow of potential future contributors looks like. Platforms that are moved forward on the master branch without testing break, that's true. I've not seen any platform where every patch gets the necessary testing, though. So they all break from time to time. And what are the patches doing anyway, that break things? Usually, patches that touch a lot of platforms are about maintenance (e.g. keep things building with a new compiler) or refactoring to ease future development. So even if booting for some platform breaks, is the code really degrading? Or did some of the refactoring actually make it easier to fix it? And talking about slower moving branches as "a more stable environment": FWIW we moved code to such branches because it was in such an unreadable state that maintenance on master was too much effort. Is this true about Quark? IDK, but it seems nobody has said so yet. I absolutely agree that if something isn't being used, it doesn't need to be maintained on the master branch. >>> >>> I disagree. >>> > Ok. Any reason why? I don't understand why would we want to maintain > something that nobody uses on the master branch. If it's not being used, it > can just as easily not be used on a release branch as the master branch, and > then we don't have to continue to try to maintain it as the rest of coreboot > moves forward. It's always a trade-off. Is the Quark code really that bad that it is hard to keep it along? Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Deprecation of the Intel Quark SoC
Hello Ron, I agree with most what you are saying in general. However, I find it very concerning that you make it about Quark. Are you sure you are not just jumping on the bandwagon because people started to pick on Quark? There are probably many boards in the tree that are even more abandoned and their platform code was in worth shape from the beginning. Let's not make arbitrary choices what to move and what not. On 15.04.22 22:38, ron minnich wrote: > I think quark revival should come with a reasonable deadline. IOW, if > people are serious about keeping this platform, I think we ought to > see commitments as to when they report that it works. I'd suggest July > 1. We already have rules when to announce and when to actually move things to abandoned branches. Let's not make arbitrary exceptions. > We've had a lot of commitments before, but everyone is busy, and > hopes can outrun reality. It should not take more than a few hours to > verify that this board or does not work. The same seems true about many other boards in the tree. Why don't you demand the same for them? > > Keeping an old platform is not zero cost. It comes with costs for > running CI, keeping it up to date as other parts of coreboot evolve, > and dealing with build failures that can occur as it falls out of > date. Those costs are all externalized, for most of us, to Patrick and > Martin, but they do exist. > > In round numbers, coreboot is at about 5k commits/year (last time I > looked; maybe it's higher or lower now). Assuming each CL takes > around ten builds, that's 50,000 builds, times 350 boards, which > translates to "a lot." It keeps Martin's house warm, I suspect. That's > not counting the continuous builds that go on for Chromebooks at > Google, Intel, and many other places. These builds all include Quark. > To put it another way, Quark has a CO2 footprint. There ought to be > usage to justify this cost. Speaking of builds in other places and CO2 footprint, wouldn't it reduce the coreboot CI's CO2 footprint by roughly 33% if we would stop build testing Chromebooks twice (with and without the CHROMEOS option enabled)? I'm not saying we should do it. But there are much lower hanging fruits than Quark. So I don't understand why this is brought up for the latter. > > I'm told that 1% or so of our mainboards are dependent on quark. As > far as I know, there are 0 quark boards out there using coreboot. We WDYM? why would you know who is using coreboot on their Galileo board and who isn't? > seem to be putting an awful lot of effort into a board with no users > -- a board and chip that, furthermore, has been dead for several > years, and was never that great to begin with. Can you please elaborate on that "awful lot of effort"? Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Security notice: SMM can be hijacked by the OS on APs
Hello Insurgo, On 12.04.22 16:01, Insurgo Technologies Libres / Open Technologies wrote: > On April 12, 2022 8:55:56 AM UTC, Arthur Heymans wrote: >>> Would it make sense to backport your fix to old releases and bump >>> those release numbers to a .1 on the end? >>> >> >> Some see releases as mere synchronization tags & nice PR. >> Some releases are also branches in gerrit but there are none affected by >> this (latest is 4.12 and it was introduced in 4.13). > > As you may know, coreboot distributions (talking of Heads specifically here), > take releases tarballs and apply patches where needed on top of it. > > In the present case, Heads currently depends on coreboot 4.11, 4.13 and 4.15 > for its supported boards. I quickly attempted to backport the relevant > patches to 4.13 tarball release, unsuccessfully. have you checked if the SMM module loader v2 was used in your 4.13 builds? AIUI, it was optional and only enabled on user request. Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Multi domain PCI resource allocation: How to deal with multiple root busses on one domain
On 22.03.22 12:01, Mariusz Szafrański via coreboot wrote: >> At some point of time I was thinking about something called >> "subdomains" concept to cover this multiple root buses in one >> domain case so to make something like: >> >> domain 0 //domain >> domain 1 //subdomain >> first root bus from stack x and its downstream devices >> end >> domain 2 //subdomain >> second root bus from stack x and its downstream devices >> end >> end >> domain ... >> ... >> end >> ... >> >> >> T8he way I understood it, domains are a set of resource windows to be >> constrained and then distributed over children and in this case >> children over multiple PCI root busses. >> I have some doubts that subdomains map the situation >> correctly/efficiently, because it has essentially the same problem as >> knowing how to split the resources between domains correctly. > As I stated it was never implemented as subdomain level device is more a > "bridge device" than "domain device" This sounds much like my idea to have device nodes for the PCI host bridges :) I believe it's the right way to model the hierarchy. Having these nodes might also make it easier to map things to ACPI. >> >> OTOH, does it even make sense to map this in the devicetree? The way >> FSP reports stacks is generated at runtime and differs depending on >> the hardware configuration. >> So having a static structure mapping that may not be interesting? >> >> Arthur >> > It depends if few ms in boot time does matter. Do you mean us? or are the HOBs that huge? Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Multi domain PCI resource allocation: How to deal with multiple root busses on one domain
On 22.03.22 09:57, Mariusz Szafrański via coreboot wrote: > e.g. if we got from HOB info that physical stack x has preallocated PCI > buses 0x20..0x2f, io form 0x2000..0x2fff, mem 0xd000..0xdfff, > mem 0x100...0x1ff and there are 2 root buses 0x20 and > 0x28 instead of adding one domain with "physical" stack we added two > domains with "virtual" stacks: I'm still trying to learn what a "stack" comprises. I'm pretty sure most of the problems solve themselves if we map the Intel terms to standard and coreboot terms. Would the following be a correct statement about stacks? A "stack" always has dedicated I/O port and memory ranges (that don't overlap with anything else, especially not with the ranges of other stacks) and has one or more PCI root buses. If so, are the PCI bus numbers separate from those of other stacks? Or do all stacks share a single range of 0..255 PCI buses? In standard terms, do they share a single PCI segment group? Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Multi domain PCI resource allocation: How to deal with multiple root busses on one domain
On 22.03.22 10:30, Arthur Heymans wrote: > OTOH, does it even make sense to map this in the devicetree? The way FSP > reports stacks is generated at runtime and differs depending on the > hardware configuration. > So having a static structure mapping that may not be interesting? IMO, a static devicetree structure only makes sense if you can tell FSP to configure the hardware like this or it is somehow predefined, e.g. descriptor straps. If FSP is broken and makes decisions on its own, better generate the tree at runtime. Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Multi domain PCI resource allocation: How to deal with multiple root busses on one domain
Hi Lance, On 18.03.22 05:06, Lance Zhao wrote: > Stack idea is from > https://www.intel.com/content/www/us/en/developer/articles/technical/utilizing-the-intel-xeon-processor-scalable-family-iio-performance-monitoring-events.html thank you very much! The diagrams are enlightening. I always assumed Intel calls these "stacks" because there are multiple components invol- ved that matter for software/firmware development. Turns out these stacks are rather black boxes to us and we don't need to know what components compose a stack, is that right? Looking at these diagrams, I'd say the IIO stacks are PCI host bridges from our point of view. > In linux, sometimes domain is same as "segment", I am not sure current > coreboot on xeon_sp already cover the case of multiple segment yet. These terms are highly ambiguous. We always need to be careful to not confuse them, e.g. "domain" in one project can mean something very dif- ferent than our "domain device". Not sure if you are referring to "PCI bus segments". These are very dif- ferent from our "domain" term. I assume coreboot supports multiple PCI bus segments. At least it looks like one just needs to initialize `.secondary` and `.subordinate` of the downstream link of a PCI host bridge accordingly. There is also the term "PCI segment group". This refers to PCI bus segments that share a space of 256 buses, e.g. one PCI bus segment could occupy buses 0..15 and another 16..31 in the same group. Multiple PCI segment groups are currently not explicitly supported. Might work, though, if the platform has a single, consecutive ECAM/MMCONF region to access more than the first group. Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Multi domain PCI resource allocation: How to deal with multiple root busses on one domain
Hi Arthur, On 17.03.22 19:03, Arthur Heymans wrote: > Now my question is the following: > On some Stacks there are multiple root busses, but the resources need to be > allocated on the same window. My initial idea was to add those root busses > as separate struct bus in the domain->link_list. However currently the > allocator assumes only one bus on domains (and bridges). > In the code you'll see a lot of things like > > for (child = domain->link_list->children; child; child = child->sibling) > this is correct, we often (if not always by now) ignore that `link_list` is a list itself and only walk the children of the first entry. > > This is fine if there is only one bus on the domain. > Looping over link_list->next, struct bus'ses is certainly an option here, > but I was told that having only one bus here was a design decision on the > allocator v4 rewrite. I'm not sure how common that assumption is in the > tree, so things could be broken in awkward ways. I wouldn't say it was a design choice, probably rather a convenience choice. The old concepts around multiple buses directly downstream of a single device seemed inconsistent, AFAICT. And at the time the allo- cator v4 was written it seemed unnecessary to keep compatibility around. That doesn't mean we can't bring it back, of course. There is at least one alternative, though. The currently common case looks like this: PCI bus 0 | v domain 0 --. |-- PCI 00:00.0 | |-- PCI 00:02.0 | : Now we could have multiple PCI buses directly below the domain. But instead of modelling this with the `link_list`, we could also model it with an abstract "host" bus below the domain device and another layer of "host bridge" devices in between: host bus | v domain 0 --. |-- PCI host bridge 0 --. | |-- PCI 00:00.0 | | | `-- PCI 00:02.0 | | |-- PCI host bridge 1 --. | |-- PCI 16:00.0 | | | : : I guess this would reduce complexity in generic code at the expense of more data structures (devices) to manage. OTOH, if we'd make a final decision for such a model, we could also get rid of the `link_list`. Basically, setting in stone that we only allow one bus downstream of any device node. I'm not fully familiar with the hierarchy on Xeon-SP systems. Would this be an adequate solution? Also, does the term `stack` map to our `domain` 1:1 or are there differences? Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: New array-bounds warnings with GCC 12
On 15.03.22 12:25, Nico Huber wrote:
> Hi Peter, Paul,
>
> On 15.03.22 02:18, Peter Stuge wrote:
>> Paul Menzel wrote:
>>> x86_64-linux-gnu-gcc-12 .. -std=gnu11 ..
>> ..
>>> In file included from src/include/cpu/x86/lapic.h:4,
>>> from src/cpu/x86/lapic/lapic.c:5:
>>> In function 'read32',
>>> inlined from 'xapic_read' at src/include/cpu/x86/lapic.h:13:9,
>>> inlined from 'lapic_read' at src/include/cpu/x86/lapic.h:80:10,
>>> inlined from 'lapicid' at src/include/cpu/x86/lapic.h:138:21,
>>> inlined from 'enable_lapic' at src/cpu/x86/lapic/lapic.c:41:3:
>>> src/arch/x86/include/arch/mmio.h:20:16: error: array subscript 0 is
>>> outside array bounds of 'const volatile void[0]' [-Werror=array-bounds]
>>> 20 | return *((volatile uint32_t *)(addr));
>>>|^~
>> ..
>>> I have no idea, if it’s valid or not
>>
>> gcc-12 is technically correct that accessing element 0 (the first element)
>> in an array with 0 elements is out of bounds.
>>
>> But in practice it's not a problem for our code, because these are all
>> uint32_t pointers to memory mapped registers (hint: volatile).
>>
>> So our code is somehow incorrect since these are, in fact, not arrays
>> with 0 elements. The question is why we use them.
>
> in this instance, there is no literal `[0]` involved. I'm not sure why
> GCC makes it up. Starting to manually inline at lapicid(), this is what
> our code does:
>
>unsigned int lapic_read_param_reg = 0x020 /* LAPIC_ID */;
>unsigned int xapic_read_param_reg = lapic_read_reg;
>const volatile void *read32_param_addr = (volatile void *)(uintptr_t)
>(0xfee0 /* LAPIC_DEFAULT_BASE */ + xapic_read_reg);
>
>uint32_t lapicid_local_lapicid =
>*((volatile uint32_t *)(read32_param_addr));
>
> (Where I named function parameters `x` `_param_` and local
> variables `y` _local_`.)
>
> IIRC, I read in some issue tracker about this or something similar
> before, and there the solution was to use `volatile` which we do
> already. I don't see what our code could do better (beside adding
> some more `const` and removing odd parentheses). *shrug*
Turned out it was the same bug report Paul linked [1]. The suggestion
is to make the pointer variables `volatile`, not the pointed to data.
This should avoid that GCC tries to reason about the pointer value.
The GCC behavior seems reasonable overall, just the warning text is
very off.
Nico
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
If somebody wants to try (there are many more places but this should
affect the reported lapic case):
diff --git a/src/arch/x86/include/arch/mmio.h
b/src/arch/x86/include/arch/mmio.h
index 7188eac22a..72302125f6 100644
--- a/src/arch/x86/include/arch/mmio.h
+++ b/src/arch/x86/include/arch/mmio.h
@@ -15,7 +15,7 @@ static __always_inline uint16_t read16(const volatile
void *addr)
return *((volatile uint16_t *)(addr));
}
-static __always_inline uint32_t read32(const volatile void *addr)
+static __always_inline uint32_t read32(const volatile void *volatile addr)
{
return *((volatile uint32_t *)(addr));
}
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: New array-bounds warnings with GCC 12
Hi Peter, Paul, On 15.03.22 02:18, Peter Stuge wrote: > Paul Menzel wrote: >> x86_64-linux-gnu-gcc-12 .. -std=gnu11 .. > .. >> In file included from src/include/cpu/x86/lapic.h:4, >> from src/cpu/x86/lapic/lapic.c:5: >> In function 'read32', >> inlined from 'xapic_read' at src/include/cpu/x86/lapic.h:13:9, >> inlined from 'lapic_read' at src/include/cpu/x86/lapic.h:80:10, >> inlined from 'lapicid' at src/include/cpu/x86/lapic.h:138:21, >> inlined from 'enable_lapic' at src/cpu/x86/lapic/lapic.c:41:3: >> src/arch/x86/include/arch/mmio.h:20:16: error: array subscript 0 is >> outside array bounds of 'const volatile void[0]' [-Werror=array-bounds] >> 20 | return *((volatile uint32_t *)(addr)); >>|^~ > .. >> I have no idea, if it’s valid or not > > gcc-12 is technically correct that accessing element 0 (the first element) > in an array with 0 elements is out of bounds. > > But in practice it's not a problem for our code, because these are all > uint32_t pointers to memory mapped registers (hint: volatile). > > So our code is somehow incorrect since these are, in fact, not arrays > with 0 elements. The question is why we use them. in this instance, there is no literal `[0]` involved. I'm not sure why GCC makes it up. Starting to manually inline at lapicid(), this is what our code does: unsigned int lapic_read_param_reg = 0x020 /* LAPIC_ID */; unsigned int xapic_read_param_reg = lapic_read_reg; const volatile void *read32_param_addr = (volatile void *)(uintptr_t) (0xfee0 /* LAPIC_DEFAULT_BASE */ + xapic_read_reg); uint32_t lapicid_local_lapicid = *((volatile uint32_t *)(read32_param_addr)); (Where I named function parameters `x` `_param_` and local variables `y` _local_`.) IIRC, I read in some issue tracker about this or something similar before, and there the solution was to use `volatile` which we do already. I don't see what our code could do better (beside adding some more `const` and removing odd parentheses). *shrug* Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Certificate expired
Hello Galarazamba, On 25.02.22 14:47, Galarazamba via coreboot wrote: > I am trying to build a Heads x230-maximized.rom on Debian 10.4.0, > > but right at the beginning I get the error, that the certificate of > www.coreboot.org cannot be trusted because it has expired. you can see the received certificate with this command: $ openssl s_client -connect www.coreboot.org:443 2>/dev/null
[coreboot] Re: About to revive an AMD AM3/fam10 platform. Reality check and guidance please
Hi Keith, On 01.02.22 08:18, Keith Hui wrote: > Read my story then tell me what I need to know and do, and if I've > taken on too much. > > With my P8Z77-M board committed, I've restarted another decade-old > platform coreboot port. > > This time it's the M4A785TD-M EVO, another Asus board, also one where > another variant *was* already supported, but not that exact one. > > I said "was" because two years ago we dropped AMD family10 CPUs and a > number of northbridge/southbridge serving them because they have not > gained some important features. unfortunately, by now there may be more to do than implementing those features. For instance the old (deprecated) allocator had some support for special things surrounding hyper-transport, IIRC. But I don't know AMD platforms as well to tell if this affects your system. Also, what could be considered current standards most probably changed. > > However this board is prime candidate for a port because it's 64-bit > but predates UEFI or PSP; its 1MB SPI flash was picked up by flashrom > with no extra work and the southbridge can take up to 16MB SPI meaning > I COULD fit a miniature Linux system in there. As I bought the board > along with a Phenom II 975 black CPU and DDR3 memory, it has as much > power as P8Z77-M and its i7-3770k and my daily machine the X230 > tablet, meaning it is still useful as a daily. > > I popped the heatsinks and have visually confirmed the chips I'm > dealing with: RS880 and SB710. Phenom II x4 975 black is a family 10h. > > I backed up their codes as present before the purge and would work off > of them. I wonder what held us up back then, was it a software limit > or just lack of attention? My goal is to bring the three pieces up to > current coreboot standards and do everything natively. I would guess "software limit". Much unlike the code around P2B these platforms were hard to maintain. I can't tell if the code just decayed or never was easy to maintain from the beginning. > > For the job I got these manuals: > RS880: Databook, Register programming requirements, RRG, BKDG > SB7x0: RRG, BKDG, Databook > Fam10: BKDG, revision guide > Plus the JEDEC DDR3 specs where info on mode registers are. > > So far I've done the bootblock inits of the board and SB710. I made > sure the SB710 code would enable the entire flash regardless of size. > Next I'll want to do CAR setup. The BKDG has specific instructions to > not use MMX or SSE instructions during CAR. Can we compile only some > units without SSE? That should certainly be possible. For instance for MMX we have an opt-out in the top-level Makefile: ifneq ($(CONFIG_MMX),y) CFLAGS_x86_32 += -mno-mmx endif You could have something like CFLAGS_bootblock += -mno-mmx > > What would be my next big hurdle, with a goal of coming up with a > native raminit like ivybridge? > > Is it time for a reality check before I dive too deep and start to > neglect Z77, or worse, P2B? Very hard to tell. It would keep you very busy to say the least. It might be worth a look how much code can be shared with other platforms. There's some effort for fam15, AIUI, and even the code of the newest Zen SoCs shows signs of rather old hardware blocks that could still be com- patible. Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: SPIBAR + 0x10 offset with MMIOREAD32 causing exception
Hi Rao, On 28.01.22 14:30, Rao G wrote: > 2) > ScSpiBar0 = MmioRead32 (SpiInstance->PchSpiBase + > PCI_BASE_ADDRESSREG_OFFSET) & 0xF000; > > Expectation: > this should return value at 0xC00FD010 > > Result > The above code is throwing processor exception > > PchSpiBase at 0xC00FD000 > X64 Exception Type - 0E(#PF - Page-Fault) CPU Apic ID - > ExceptionData - I:0 R:0 U:0 W:0 P:0 PK:0 SS:0 SGX:0 > RIP - 771903D0, CS - 0038, RFLAGS - 00010046 this is literally as it says, a page fault. Just like in any other OS (and wrt. this UEFI is an OS) you have to map physical memory using page tables before you can access it. There is likely a very simple function you have to call to turn your physical address into a virtual pointer that you can use in C. I'm not familiar with UEFI, so can't tell you what to call. Better ask UEFI developers. > > Any clues whether SPI flash needs to be enabled in descriptor or any straps > by using FIT tool? No, this problem is a generic one and far away from your particular controller. It's not even about hardware (beside that you run it on a computer ^^). Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Installing coreboot with SeaBIOS
Hi Bernd, On 18.01.22 14:41, bernd...@web.de wrote: > So, after having made clear the corresponding points do you think that the > following hardware will be sufficient to flash the coreboot/SeaBIOS ROM to the > chip of my ThinkPad X220 (notebook version, not tablet version): > > Raspberry Pi with keyboard and screen > Pomona or SOIC8 programming clip > 8 jumper wires/dupont wires that fit the clip 10 to 20 cm each > PSUs to power everything tl;dr Go! If you want to be 100% sure, you should open your ThinkPad and check that your BIOS flash is indeed in a SOIC-8 package, and that there is only a single flash chip. In theory it can be different, but so far people have only encountered a single SOIC-8 chip, AFAICT. Minor corrections: Pomona is the name of the manufacturer (of the better clips). You only need 6 wires; /HOLD and /WP pins of the flash are already properly connected by the mainboard. Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Gerrit shows a Merge Conflict (was: Re: Denverton-NS refactoring)
Hi, On 19.01.22 14:27, Jeff Daly wrote: > Intel continues to support inclusion of support for Denverton in coreboot, > but there will be a shift in day to day maintenance is all rather than the > maintenance being completely internal. AFAICT, this doesn't mean it will shift but it may start. Denverton support in coreboot was mostly a code drop, FWIW, including redundant files, dead code. Not really maintained until the first Intel customer (IIRC, jvdg working for Scaleway) started to work on it. Over the years Intel had put a lot of names into our MAINTAINERS file, but there seemed to be a pattern: the more names, the lower coreboot was a priority. Also, more names often means less experience. For the initial code drop, review was basically skipped, so people never got the chance to learn upstream coreboot development. Might be an issue on our side. Later the maintainers list was made a running joke: When deprecation of the Denverton code was requested, Intel did one thing: They updated the list of names. But nothing else changed; e.g. review request from September, still unanswered. My interpretation: For Intel, maintaining DNV support in coreboot means that they provide contacts for their customers. But the maintainers were never given the resources to work with the open-source community. Rant is just about DNV support. It's a completely different story for other teams at Intel. Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Installing coreboot with SeaBIOS
On 18.01.22 10:40, bernd...@web.de wrote: > "Depends on your ThinkPad model, usually yes if the clip fits the chip, > the wires fit the clip and aren't too long, and you have PSUs to power > everything." > > It's a ThinkPad X220 (notebook version, not tablet version). Let's provide > that > the clip fits the chip, the wires fit the clip and I have PSUs to power > everything. You're lucky. The X220 is a rather easy target. > > How long may the wires be? 10 to 20cm works well. Sometimes shorter is better, but the X220 shouldn't make you any trouble. So I'd rather choose cables that don't make handling of the clip too inconvenient. Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Installing coreboot with SeaBIOS
On 16.01.22 18:16, bernd...@web.de wrote: > Hello Nico, > > ... "It can act as the second computer, you just need a keyboard and screen I > suppose. flashrom works well on the RPi. Usually you can just install > it with your package manager." ... > > Is a Raspberry Pi with keyboard, screen and jumper wires and a programming > clip > enough hardware to flash the ROM to the chip of my ThinkPad or is anything > else > necessary? Depends on your ThinkPad model, usually yes if the clip fits the chip, the wires fit the clip and aren't too long, and you have PSUs to power everything. Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Installing coreboot with SeaBIOS
Hello Bernd, On 16.01.22 11:09, bernd...@web.de wrote: > ... "other solutions like a Raspberry Pi or STM32." ... > > Is the STM32 a board like the CJMCU-2232H which has a USB connection and a pin > header and that's attached to a second computer via USB and to the programming > clip via jumper wires? STM32 is actually a whole family of microcontrollers. In this context, likely a blue-pill board was meant (e.g. [1]). As mentioned, this requires more effort to set up. You need to solder the pin headers and you need another device to program a flashrom-compatible firmware[2] to it. For the programming, you need a TTL-level (3.3V!) UART. For instance, a USB adapter, or the UART of an RPi. There are also other STM32 boards that work with this firmware. But the blue-pill is the famous/cheap one. > > If a Raspberry Pi is used, is it both the second computer and the programmer > all > in one or is a second computer or a programmer still needed? It can act as the second computer, you just need a keyboard and screen I suppose. flashrom works well on the RPi. Usually you can just install it with your package manager. Nico [1] https://www.ebay.de/itm/144350056565 [2] https://github.com/dword1511/stm32-vserprog ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Gerrit shows a Merge Conflict (was: Re: Denverton-NS refactoring)
On 12.01.22 18:11, Jeff Daly wrote: > If I don't have to do anything, then I won't. I wasn't sure whether commits > that are marked with conflicts tend to get less attention than ones that > don't. I've been rebasing for amending earlier commits so I guess at least > I'm doing that correctly. What I'm confused with is as you said, if I'm > removing lines it will try to remove them, and fail if something changed > between the 2 bases. I'm the only one making any changes, so that shouldn't > be an issue.I understand the file replacement explanation as well, but > again nothing changed in the file in the base I'm working on and by rebasing > against master before pushing, I'd see the merge conflict. If my change got > in before someone elses, then they'd see the merge conflict when they went to > push. The xHCI patch on Gerrit is currently based on one changing the PCI ID macro in `xhci.c`. When you cherry-pick the xHCI commit alone (on master where the macro name didn't change), the file contents are different. Nico > > > -----Original Message- > From: Nico Huber > Sent: Wednesday, January 12, 2022 12:04 PM > To: Jeff Daly ; Paul Menzel ; > coreboot@coreboot.org > Subject: Re: [coreboot] Re: Gerrit shows a Merge Conflict (was: Re: > Denverton-NS refactoring) > > Caution: This is an external email. Please take care when clicking links or > opening attachments. > > > On 12.01.22 16:21, Jeff Daly wrote: >> Ok that sort of makes sense, but for example in the case of the XHCI patch, >> the merge conflict appears to be that since soc/intel/denverton_ns/xhci.c >> was changed completely to reflect the usage of the common code and shouldn't >> cause an issue with being cherry-picked onto master... >> >> So, I just tried it and see that it comes up with the merge conflict. I >> guess the merge operation is super-cautious and prefers the developer to do >> a manual merge vs always accepting the newer code? Is there a setting that >> can be modified for that? > > I don't know any setting to change that. It's simple tools, AFAICT. If you > supply them a patch with something to remove they'll try to find the > respective line to remove and fail if that line changed between the two > bases. Git cannot see that the intention is to replace the entire file no > matter its current contents. To a human that might be obvious but also only > in the context of your whole patch train. IMO that's correct behavior. For > instance, if somebody else added something to that file in the meantime, > would the intention still be to replace the whole file? How to decide that > automatically? > >> Having to do a merge resolution for wholesale changes to code seems >> counter-productive. > > You don't have to do anything unless you want to re-organize your patch > train. For instance, change the order of commits you currently have on one > branch. But is that really what you want? > >> >> Next question would be, what's the best mechanism to do this and not mess up >> my patch train again. I want to keep all the relationships in gerrit so the >> progression can be visualized. I have a clean master branch and the >> denverton_refactor branch locally where I'm keeping my changes. I'd like to >> keep it in denverton_refactor locally. is it required that I need to >> apply the merge resolution commit on the master branch or can I rewind my >> branch to the offending commit^ and do git pull --rebase at that point? > > I'm afraid I don't follow. What is it that you want to do that results in the > conflict in the first place? > > Generally our Gerrit setup doesn't allow merge commits. If you want to amend > a commit on your branch, you have to rebase. > > But a `git pull --rebase` would rebase on top of upstream (I assume). > That's sometimes useful, but rather a potential cause of conflicts than a > resolution. > > Nico > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Gerrit shows a Merge Conflict (was: Re: Denverton-NS refactoring)
On 12.01.22 16:21, Jeff Daly wrote: > Ok that sort of makes sense, but for example in the case of the XHCI patch, > the merge conflict appears to be that since soc/intel/denverton_ns/xhci.c was > changed completely to reflect the usage of the common code and shouldn't > cause an issue with being cherry-picked onto master... > > So, I just tried it and see that it comes up with the merge conflict. I > guess the merge operation is super-cautious and prefers the developer to do a > manual merge vs always accepting the newer code? Is there a setting that can > be modified for that? I don't know any setting to change that. It's simple tools, AFAICT. If you supply them a patch with something to remove they'll try to find the respective line to remove and fail if that line changed between the two bases. Git cannot see that the intention is to replace the entire file no matter its current contents. To a human that might be obvious but also only in the context of your whole patch train. IMO that's correct behavior. For instance, if somebody else added something to that file in the meantime, would the intention still be to replace the whole file? How to decide that automatically? > Having to do a merge resolution for wholesale changes to code seems > counter-productive. You don't have to do anything unless you want to re-organize your patch train. For instance, change the order of commits you currently have on one branch. But is that really what you want? > > Next question would be, what's the best mechanism to do this and not mess up > my patch train again. I want to keep all the relationships in gerrit so the > progression can be visualized. I have a clean master branch and the > denverton_refactor branch locally where I'm keeping my changes. I'd like to > keep it in denverton_refactor locally. is it required that I need to > apply the merge resolution commit on the master branch or can I rewind my > branch to the offending commit^ and do git pull --rebase at that point? I'm afraid I don't follow. What is it that you want to do that results in the conflict in the first place? Generally our Gerrit setup doesn't allow merge commits. If you want to amend a commit on your branch, you have to rebase. But a `git pull --rebase` would rebase on top of upstream (I assume). That's sometimes useful, but rather a potential cause of conflicts than a resolution. Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: How should we handle different endianness in cbtable?
Hi Igor, On 23.12.21 15:49, Igor Bagnucki wrote: > > Dear coreboot community, > > as a part of coreboot port for Talos II POWER9 architecture, we are > porting the cbmem tool. [1] This platform can switch between the > big-endian and the little-endian. coreboot operates in big-endian but in > theory it could also operate in little-endian, and the OS can also > operate in both - little-endian and big-endian. how likely is it that an OS runs in big-endian? IIRC from past discussions it was usually expected that the OS runs in little- endian. If there is such a preference, I'd simply specify the cbtable endianness to be little-endian. After all, the cbtable is an interface for the OS so we should make things easy on that end, IMHO. Also, if we could assume little-endian OS's, we could also switch early (e.g. bootblock) to that. Or is there any other technical difficulty why we don't do that already? > This creates a situation > where cbmem tries to read cbtable in different endianness than the > cbtable was created. Therefore, cbmem needs to convert the endianness, > and it needs to differentiate if the conversion is required or not. > > There are several ways we could differentiate if it is required to > convert endianness or not. What would be the best approach to this problem? > > 1. Save endianness information in the cbtable header. > For example, the signature on the big-endian coreboot could be “OIBL” > instead “LBIO”. This solution would be very portable as the other tools > looking for the cbtable but not expecting the big-endian format would > simply not find the table instead of trying to read it and crashing. > However, this change would need to be introduced in multiple places in > coreboot as the signature is hardcoded in multiple where it was needed. > > 2. Add preprocessor checks to enable endianness conversion only on > defined platforms. > It would be easy to implement, but if the BIOS and the OS can have > different endianness, then it could break for cbtable written in > little-endian mode. > > 3. Recognize the correct endianness by checking some property of cbtable > header. For example, header size property value could be checked if it > reads as 0x18 or 0x1800, but this solution requires very little > changes but feels hacky and susceptible to changes in cbtable header > format. > > 4. Add command-line option to cbmem so the user can choose what > endianness should be used. I’m not sure about this solution, because it > pushes the responsibility to recognize endianness to the user. 5. Specify a single endianness for cbtable. I would prefer little-endian as that would keep compatibility to older (maybe not too old) user-space binaries. Even if we have code that runs in big-endian, that would still keep the conversion simple. We could just always convert host-to-LE and vice versa, no need for any `if`. Nico > > [1] https://github.com/Dasharo/coreboot/pull/62 > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Question about compressed FIT payloads
On 15.12.21 13:24, Krystian Hebel wrote: > Hi Nico, > > On 15.12.2021 12:21, Nico Huber wrote: >> Hi Krystian, >> >> On 14.12.21 13:00, Krystian Hebel wrote: >>> For our work on POWER9 coreboot port we were using Skiboot [1] packed >>> into >>> FIT payload. >> I might just miss it because I never worked with FIT, but maybe I'm not >> the only one: Can you elaborate why you chose FIT? Reading through your >> mail (and without further knowledge) it would just seem like the wrong >> choice. > > Good point, I spent so much time in this project that I treat too many > things as obvious. Don't hesitate to ask if I omit something important. > > Skiboot must be supplied with information about hardware. Some of that > is generated by code based on current configuration (e.g. number of > cores, their IDs, memory amount and associativity), but a lot is always > the same for a given platform or even whole architecture (BMC sensors, > interrupt controller, register address space, LPC controller). Isn't this all or mostly information that coreboot has already available? It seems much like the situation on x86 with ACPI. We also had static ACPI tables that redundantly stored infor- mation at first. However, static ACPI tables were never treated first-class, sometimes even like an alien, and were prone to rot. Today, we try a good compromise between runtime generation and static tables (which can be extended at runtime). > This can > be passed either in HDAT structure (Hostboot data, proprietary and > mostly undocumented format in supposedly open firmware) or, as we > learned after asking on OpenPower-Firmware mailing list, using FDT: > > https://lists.ozlabs.org/pipermail/openpower-firmware/2021-May/000641.html > > In our current setup that second, constant part is supplied as FDT in > FIT image so it can be added as .dts file, which is easier to read and > understand than C code that would be used for creating these nodes. Hmmm, I read above mailinglist thread. But I still miss the link to FIT. coreboot would have a dtb (doesn't matter if it generates it at runtime or a file in CBFS) and a payload (in CBFS or some other flash partition), right? Why do you need FIT? Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: 915G support
Hi, On 15.12.21 14:25, Sid_key wrote: > Hello, is 915G supported? alas not, and it never was, AFAICT. i945 is supported and i855 was once. > Is it hard to implement support for Gigabyte > 8i915md-g? It very much depends on your skillset. It's not hard compared to a modern mainboard. However, it could still take some months. Given that there is code for newer and older Intel platforms available, all the information needed to understand what needs to be done for i915 should be public. Finding the exact sequence of bits to toggle could be done with a tool like serialice[1]. Datasheets of that time might also provide rather comprehensive register descriptions. Beside the northbridge, you'd also need code for the CPU, the south- bridge and likely a super-i/o. Your CPU might be supported, for the southbridge it's roughly the same as for the northbridge, but easier. Nico [1] https://www.serialice.com/Main_Page ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Question about compressed FIT payloads
Hi Krystian, On 14.12.21 13:00, Krystian Hebel wrote: > For our work on POWER9 coreboot port we were using Skiboot [1] packed into > FIT payload. I might just miss it because I never worked with FIT, but maybe I'm not the only one: Can you elaborate why you chose FIT? Reading through your mail (and without further knowledge) it would just seem like the wrong choice. Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: spkmodem output
On 10.12.21 12:56, Keith Emery wrote: > Am I correct in my understanding that bison is complaining about some > component of the tool chain? `bison` just shows warnings. The actual problem is the C compiler showing some errors (actually just warnings, but acpica is configured to make them errors). The problematic code is generated by `flex`. So in a way your installed `flex` is not fully compatible with your installed C compiler (GCC or clang most likely). You could try dif- ferent versions of these, or try to disable the `-Werror` option when acpica is built. Nico > > I don't remember using any different versions. > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: spkmodem output
Hi Keith, On 10.12.21 09:28, Keith Emery wrote: > So I set out to repeat the experiment on my local computer. Only to find > that the current master branch of Coreboot fails to build the tool > chain. I was following the tutorial to the letter, but received the > following: > > [redacted]/src/coreboot/util/genbuild_h/genbuild_h.sh: 59: -v: not found that's a known cosmetic issue. Calling `genbuild_h.sh` at that time seems spurious. I guess, you can ignore it. > The tool-chain then failed to build IASL: > > Building IASL v20210331 for host ... failed. Check 'build-IASL/build.log'. > make[1]: *** [Makefile:23: build_iasl] Error 1 > make: *** [util/crossgcc/Makefile.inc:30: crossgcc-i386] Error 2 > > > I checked the log, which states: > > cp: cannot stat 'iasl': No such file or directory That looks like a later error only shown because the script goes on even when the build failed. The actual error might be earlier in the log. If in doubt, please attach the whole file. Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Questions Regarding Flashing a Voxel (CP713-3W) Chromebook
Hello Matthew, On 02.12.21 19:55, Matthew K wrote: > 1. Am I even looking at the right chip? No. > Is there a different 32MB Rom that I should be flashing to? Yes and no. There is another chip, but a current Chromebook shouldn't require you to access the chip directly. Generally, one should be able to restore the firmware and/or add a payload for legacy boot via soft- ware flashing. Also, the security chip should allow you to program the flash via a SuzyQ(uabble?) cable, AIUI. I'm not a Chromebook expert, but I'm sure that this is the direction to look into. > Does the chromebook firmware live on the harddrive > somehow (I find this unlikely because the hard drive is replaceable, but I > wanted to mention the possibility)? If it's not the bios chip, then what is > it? Could be firmware for the security chip, or maybe the EC. Or maybe both. It's not uncommon to find additional flash chips. > 3. What sort of expectations should I have for the current status of > coreboot on this mainboard (either from the coreboot or chromium > repositories)? What additional work should I expect to have to do if I want > to be able to e. g. boot from a linux flash drive? If you can find the correct branch and config for the chromium version, the coreboot should work. No guarantee for the upstream version, but I would expect it to work too or be easy to fix. Regarding booting from a Linux flash drive, you have choices to make :) You can either try one of the legacy boot methods, BIOS (SeaBIOS pay- load) or UEFI (TianoCore payload), or some generic boot-loader payload like GRUB or FILO. The latter need configuration, however, and it's only advisable to use them when one is used to configure the boot- loader manually. While all the mentioned payloads should run on any x86 machine, they sometimes lack compatible drivers. Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: How to maintain AGESA-based ports long-term?
On 01.12.21 15:57, Ivan Ivanov wrote: > Thank you, these seem to be good points. However, in regards to: > >> If you have any hope of open-source coreboot for newer platforms, you >> shouldn't make it harder for coreboot to advance. > > Where to advance? Are there any "newer platforms" that are as worthy > as the "older platforms": Not sure how to compare that, nobody has written native coreboot code for the platforms that you deem worthy either. Also, ... > 1) as secure: no Intel ME / AMD PSP "security" co-processors, which > are seen as harmful to real security by many ; ...open-source AGESA seems worse to me. In theory one could review it, but did anyone? AIUI, it even provides runtime code for the OS (ACPI DSDT), i.e. tells the OS what to do. So what you call "real security" seems more like wishful security to me. Presence of ME or PSP does not provide a security issue per se. It depends on your threat model and if they are your weakest spot. There are plenty of controllers even in older machines that run code from ROM masks. What's the difference? Can we trust vendors with code in ROM masks but not with code in flash? These are subtle considerations. So far, it doesn't make older hardware more attractive to me. Did I mention that at least one of the pre-PSP platforms already has a PSP, just hidden? Ok, I admit I didn't look at the silicon to check, but it's common that a silicon vendor puts new stuff early into chips to test it. So it seems very likely to be true. We generally don't know what exactly lives in these chips. I rather trust what I can see. > 2) as affordable: the older devices are possible to get used for like > $100-$200. Meanwhile - because of Boot Guard etc. - the "newer > platforms" are unlikely to have coreboot without vendor's involvement, > who will gladly charge a big extra for "coreboot support". Last time I checked BootGuard wasn't a big issue, i.e. not so many devices ship with it. Did that change? Devices sold today will be as affordable tomorrow (well, on a slightly larger timescale). What's your point? > 3) as available: these generic consumer electronics, which have been > shipped with a proprietary UEFI but got coreboot support later, have a > huge numbers all over the world - compared to the quite limited > availability of newer coreboot platforms. I don't understand this point either. This will change, earth keeps turning, right? Also, I'm quite sure that your numbers are wrong anyway. Please check how many Chromebooks are sold, for instance. These, are sold by people who actually support the project btw. > > Sorry, I don't see any "newer platforms" which would match the "older > platforms" on these critically-important points. You seem to be too much used to look behind. Please look ahead from time to time. And regarding security, don't trust what you read on the internet. It's far more subtle than non-PSP is secure, PSP is insecure. Also, it's not about old vs. new hardware anyway. There's much older hardware than the AGESA ports that will stay maintained. It's about hardware that nobody took the time to write a proper, long-term main- tainable coreboot for. And I can't blame anyone for it. Everything AMD Bulldozer based always seemed like the most unattractive hard- ware to me. > So it doesn't seem reasonable to drop the "crappy code" of "older > platforms" in favor of the "beautiful code" of "newer platforms", if > they could never become as worthy. You made it clear that they are worthy to *you* (even your arguments seem extremely fragile, so maybe that changed), so you are free to look after their code. Why not start with that instead of complaining that nobody else does it for you? > > Well, maybe some corporation sees their newer platform as "more > worthy" - despite it's losing on all 3 points above and there are > blobs-over-blobs. But they can't speak for the community of opensource > hobbyists all over the world, people like you and me. And pleasing the > corporations by easing their "burden" - while dropping the "older > platforms" which are more worthy - doesn't seem wise, at least to > me... You are blaming and talking to the wrong people. Deprecating old code was always driven by the most libre developers in this community, FWIW. They shoulder the hard work to keep the code base maintainable, so I think they should decide what is worthy and what isn't (hopefully not based on some weak, wishful arguments). Keeping the code clean makes life easier for other people too, sure, but that's what happens when people work together on a project. Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: How to maintain AGESA-based ports long-term?
On 01.12.21 11:28, Ivan Ivanov wrote: > Good thing about what I've suggested - "different places for v3 and v4 > allocators" - is that it's (almost?) already done ;-) It would mean a constant burden for the project. The resource allocation is kind of the heart of coreboot's ramstage, it's strongly tied to our devicetree model. Many changes in that area would have to be done twice, and changes to the older code are more expensive than changes to the newer, cleaner code (there were reasons to rewrite it!). Also, we'd be either constantly looking for testers for changes to the old code, or risk to break it which is why branching is so much cheaper for the community as a whole. Basically, what you are asking is that people who want to advance coreboot in that area should work twice as hard (mostly in their limited spare time). Trust me, it's infeasible. You can't talk people into maintaining some- thing for you when you ask them to work on something very pesky for free. Maybe worth to mention again: The platforms that don't work with the v4 allocator don't work because their code is broken. It's subtle bugs that were not visible with the v3 allocator by coincidence. You're also as- king to keep the code buggy. Nico PS. If you have any hope of open-source coreboot for newer platforms, you shouldn't make it harder for coreboot to advance. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: How to maintain AGESA-based ports long-term?
On 29.11.21 15:58, awokd wrote: > Nico Huber: >> On 29.11.21 14:49, awokd wrote: >>>> >>>> Branching >>>> - >>>> I know some people are easily offended by the thought, but I want to >>>> mention it anyway as it seems to me like a cheap solution for the com- >>>> munity as a whole. We could maintain platforms on separate branches. >>> >>> Is this different than the status quo? >> >> Yes, these ports wouldn't hold the master branch back anymore. > > Meant the status quo approach of deprecating boards and leaving to an > older branch. I think you are saying it would be a named branch instead. > Well, if I wanted to maintain a branch I would make it dedicated to these specific ports. That would probably be easier to maintain than a release branch that covers all ports of the given time. Also, it seems to me that leaving things on an anonymous release branch provides too much hope that somebody else will do the work ;) Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: How to maintain AGESA-based ports long-term?
On 29.11.21 14:49, awokd wrote: >> >> Branching >> - >> I know some people are easily offended by the thought, but I want to >> mention it anyway as it seems to me like a cheap solution for the com- >> munity as a whole. We could maintain platforms on separate branches. > > Is this different than the status quo? Yes, these ports wouldn't hold the master branch back anymore. > I think the concern here is once > platforms are dropped from master, people rarely take the time to > consider or backport any improvements to the out of sight, out of mind > old branches. On the other hand, concerns about trying to maintain code > with mounds of technical debt are entirely valid. They are out of sight either way, IMHO. The original deprecation notice is over a year old, why would anyone still put any effort into it? I assume if there was a dedicated place for these ports, people might even be encouraged to work on it because they don't have to fear that the ports are completely abandoned soon. I guess it depends most on the maintainers of such a branch. If they'd let it rot, things won't get better of course. >> >> Porting >> --- >> Given that we are talking about platforms that are not based on native >> coreboot code but unmaintained vendor code instead, it might help to >> port these platforms to coreboot proper. >> > You mention the KGPE-D16 as an example. I hadn't followed at the time, > but from what I can tell it was a well-written, coreboot native port. AFAIR, it's the exact opposite. IIRC, Timothy asked for $200k to publish the code, clean it up, and for upstreaming. They only got $50k which was enough to publish the code, that IMHO, was in a PoC state (it worked somehow for their selection of CPUs and DRAM, but not generally). And review was mostly skipped. There was this argument all over the review: that the existing code (K8 etc. IIRC) was broken anyway. I can't say if this is true. But it felt a little that upstreaming the KGPE-D16 work, in the given state and with the given resources, led to abandoning the last native AMD ports. > However, that didn't save it from getting dropped, presumably under a > similar scenario. What would be different with today's scenario, for > example? Sincere, reasonable funding, clean code, decent review. Everything would (should?) be different. Before you consider paying somebody for the effort, you have to find somebody qualified and willing to do it anyway. I'd start with that. Then ask why they think they could succeed. >> Oh, and I almost forgot, the board ports don't look like coreboot code. >> There's CamelCase, odd tables in C code (as if there was no devicetree), >> AGESA configuration done in the code of each and every mainboard that >> should be done only once in the chipset code... IMHO it looks like a >> mess. When one is used to coreboot and then sees this, there should >> be no doubt why we have deprecation squabbles ;) This [1] might be >> related. Board ports of other platforms have seen a lot of updates >> over the last ten years, that's not easy for ports where one doesn't >> know what to begin with. > > Your "[1]" footnote didn't seem to make it. Sorry, sent it later: [1] https://en.wikipedia.org/wiki/Broken_windows_theory >> A last thought about board ports, wrt. to blobbed vendor code I stated >> it like this lately: The board port should be written such that in case >> one would replace the blob (vendor code) with a native coreboot port, >> that should be possible without touching the board code. IMO, there >> shouldn't be a trace of AGESA in the mainboard dirs. The mainboard code >> should configure the chipset drivers/code and the chipset code can use >> AGESA to achieve its goal, but shouldn't be force by mainboard code to >> do so. > > Something hybrid like this is what I was considering to remove > LEGACY_SMP_INIT. Could the first portions of fam14-16 bootstrap (i.e. up > to and including AP early initialization) be done with a more > common/cleaner coreboot approach, then chained over to AGESA vendorcode > for the rest? I have been unable to figure out the answer or how much > work would be involved. If it is a valid approach, might let other > native pieces be added in the future to more easily address new > requirements. It's just software, so it could certainly be done. How much work would be involved is the right question. Alas, I have no idea. One needs to study the AGESA sources to tell, I guess. However, LEGACY_SMP_INIT sounds like something that is usually done late in ramstage. I'm not sure this is anything to make an early cut. Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: How to maintain AGESA-based ports long-term?
On 28.11.21 19:54, Nico Huber wrote: > Oh, and I almost forgot, the board ports don't look like coreboot code. > There's CamelCase, odd tables in C code (as if there was no devicetree), > AGESA configuration done in the code of each and every mainboard that > should be done only once in the chipset code... IMHO it looks like a > mess. When one is used to coreboot and then sees this, there should > be no doubt why we have deprecation squabbles ;) This [1] might be > related. Board ports of other platforms have seen a lot of updates > over the last ten years, that's not easy for ports where one doesn't > know what to begin with. Looks like I forgot the ref here. [1] https://en.wikipedia.org/wiki/Broken_windows_theory ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] How to maintain AGESA-based ports long-term?
Hi coreboot folks, there have always been platforms in the coreboot tree that are easy to maintain and others, alas, that seem to be the complete opposite. When new features or new iterations of existing code are pushed, we'd love to keep everything up-to-date. But this is infeasible. Given the vast amount of platforms in-tree, including poorly written ones with inex- plicable code, it's simply not possible to demand this from any single developer or entity. Hence, what usually happens is that at first only the easy-to-maintain platforms are updated. This pattern usually works for some time, but at some point it looks like coreboot has been forked within its own tree, making further maintenance too hard. So we drop old code paths and the platforms relying on them from time to time. It seems to me that AGESA-based ports are always on the brink of being dropped. I can't say for sure why that is, neither do I want to pretend to know how to avoid it. However, I'm convinced that they are among the hard to maintain ports that drag the project down. And I have no doubt that we'd have to squabble less about them if somebody would actively take care of the code. I can't say that I'd be of much help and I don't really care about the code. But it seemed to me that other people do care and need a little nudge to get a discussion going. I'll list some thoughts what could be done. Feel free to agree to or dismiss any of it. Some things are mutually exclusive, others are not. Branching - I know some people are easily offended by the thought, but I want to mention it anyway as it seems to me like a cheap solution for the com- munity as a whole. We could maintain platforms on separate branches. Keeping things working shouldn't be much effort. At least, I guess the following would be necessary: * Keep the toolchain up-to-date and the code compatible. * Keep the payload hook-ups up-to-date and test them from time to time. Naturally, this is less effort on a branch that is dedicated to specific platforms, i.e. does not keep all the other things in the tree like we have on release branches. I would drop anything not related to the plat- forms in question right after the branch point. This would move most of the effort to the folks who actually benefit from the maintenance. However, given my experience in this community, I would expect people who usually only work on the master branch to still be responsive and helpful. Porting --- Given that we are talking about platforms that are not based on native coreboot code but unmaintained vendor code instead, it might help to port these platforms to coreboot proper. I don't think that the integration of vendor core is a root-cause of the trouble. FWIW, other vendor code (well, usually in the form of blobs) has been integrated into coreboot with more success. However, a fresh port with decent review could definitely lose a lot of the burden of the old one. It's a huge effort of course, I don't want to hide that. Just like for the famous KGPE-D16 and surrounding platform code, I'd estimate roughly $200k for such an endeavor (maybe half of it for the initial implemen- tation and the rest for both sides during a few months of review). IMHO, this is an investment that was missed initially when these plat- forms were added to coreboot. Generally, getting something to boot with coreboot is rather easy. I guess you can get things running with maybe 20% of the effort necessary for a port of reasonable code quality. How- ever, if things are left in such a state, somebody has to pay 10% on top during every year of maintenance (which is currently left to the active coreboot developers). IOW, the current state is also very expen- sive whilst not getting anywhere, and paid by the wrong people. Documenting Hardware The existing documentation, at least AFAICS, is rather thin. Every time some developer wants to advance coreboot and has to touch the respective code, they could use some good documentation. I can't exactly say what is missing. It's like whenever I have to look into a BKDG, I don't find what I'm looking for. Also, it's very hard to tell which AMD document applies to what hardware. Register descrip- tions are usually there, maybe what I'm missing is some in-depth docu- mentation of the concepts. Or maybe it would already help to extend the register descriptions. Also, organizing the available information could help. Comparing BKDGs to Intel's public, scrubbed datasheets, it seems the latter already have more in-depth textual descriptions. Cleaning up the existing ports -- Of course, one can also try to continue as usual and bring things for- ward iteratively. This might be the most expensive way, though, so I put it last. Kyösti has already mentioned some things that could be done beyond what is immediately necessary to avoid the current depre- cation plans. He's definitely the guy to talk to about AGESA topics.
[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
Hi Peter, On 28.11.21 02:44, Peter Stuge wrote: > TL;DR: If someone wants to deprecate older code then *they* have to > first balance any compatibility debt introduced by the newer code. sounds fair. However I have to ask, do you see things are unbalanced? And in what direction? Taking the allocator case for instance, there is zero compatibility debt introduced by the new code. All the debt is within the code of the deprecated platforms, which is neither compatible to the old nor the new allocator code. It's just buggy. Always has been. Changing core coreboot code just makes this more visible, and to me it seems fairer to deprecate broken code than to pretend that it's working. Overall, all the cases of dropped platforms that I can recall are of this kind: Somebody pushed their code upstream and then they or somebody relying on the code tried to get their bugs fixed for free by coreboot maintainers. IMHO, this is heavily unbalanced and depre- cation are a means to fix that. > Anything else incentivises a race to the bottom; to move fast and > break things. coreboot IMO neither wants nor needs that. Sounds right. But I guess you assumed things are unbalanced in a different direction than they are :) > Patrick Georgi via coreboot wrote: >>> With all due respect, dropping support for the majority of AMD boards >> >> Dropping support for hardware has never been the primary purpose of >> deprecation plans, > > I think the difference is unimportantly subtle; deprecation is formal > intent to (eventually) drop. No, not unconditionally and definitely not eventually. Their is always hope that somebody tries to fix the platforms that rely on deprecated code. > > Deprecating code that not only provably works on hardware but is in > fact *our only* code that currently works on the hardware IMO falls > between lazy and malicious, in any case far from good practice when > considering the future. tl;dr that code works by coincidence is not enough to ask other people to maintain it. You may not have read the code of the platforms in question. I did and IMHO, if anything is malicious then it's having such broken, impossible to maintain code in our tree. Looking at the code, I have to assume it was added with minimum effort to write sound code and maximum debt. People have worked to fix it and clean it up for years and it's still in a (IMHO) horrible state. Pushing such code into the tree "falls between lazy and malicious". Asking to keep such code without the intention to fix it, too. > Our classic tension between private interests and the public good > will not diminish over time unless everyone invests towards that goal. > The Linux kernel is a perfect example of what happens otherwise, it's > certainly nothing to strive for. What's the public good in this case? Isn't it for the public good when people like Arthur continue to support projects like coreboot? You seem a little too biased towards existing code, but what about new code? Is there no public interest in new code? > > I consider Arthur's argument about maintenance burden to be based on the > false premise that newer code is per se more valuable than older code. Ok, your are free to consider it like this. But I can tell you it's wrong. IIRC, all the deprecation up to now were in favor of code that turned out to work best for all sound coreboot ports. Of course, new code doesn't always work well for ports that only worked by coincidence with the old code, and there's the burden. Who's responsible to fix code that was added in a poor state? The original authors? the people who rely on it? or the people who want to continue the project? > > If only considering hardware running the newer code with tunnel vision > I do understand such an attitude, but to me a hard requirement for such > a premise is that the newer code is a drop-in replacement - only then > is it prudent to speak of deprecating the older code. If it's not > compatible then the new code obviously solves a different problem. > > It's of course too late to enforce drop-in compatibility once new code > has been accepted into the tree, but the desire for deprecation such as > this is a good opportunity to pay back what I consider compatibility debt > in the new code. > > Accepting an incompatible new implementation fails to create the incentives > required for medium to long-term codebase stability. It would be wise to > start repairing that culture deficit right now. Again, the incompatibility burden is usually not introduced by the new code. What you say seems generally true, but you are blaming / talking to the wrong people. It's not what is going on in this project. > > I find it completely unacceptable for someone working on something new > to push a workload of forward-porting onto people who have no relation > whatsoever to that new effort, but I'm sure it's a fun power trip. :) I find it completely unacceptable for someone adding broken code to push a workload of fixing onto
[coreboot] Re: DIP8 flash programming for development
Hi Pedro, On 27.11.21 00:02, Pedro Erencia wrote: > I'm thinking about porting coreboot to a FM2A88X Extreme4+ board. This > board has a DIP8 flash with a socket and I wondered what would be the best > way to do an efficient development cycle. Ideally, I suppose that the best > option would be to use a clip test and a CH341A, but all the clips that I the CH341A is a rather slow programmer and the most popular version uses 5V i/o while you most likely need 3.3V. I would rather use something FT*232H based (the H is important, it's high-speed and speaks SPI) or maybe a stm32 "blue-pill" with firmware from [1]. > found are SOIC/SOP. Should I buy a SOIC clip and an adapter from SOIC to > DIP? I've seen those adapters, but I'm not sure if they will fit well in > the mobo DIP8 socket. Not sure what adapter you are talking about. Clips are not good for development anyway; they are most useful if you want to program a device just once and then go on with the next device. What I would do (but not sure if I'd recommend that): Solder wires somewhere at to the tops of the DIP8 legs. So you could still plug it into the socket. Or maybe I would try to squeeze some stranded wire along with the chip into the socket. Anyway, I would consider something more professional, see below. > > Aside from the mechanical question, I'd appreciate any advice about the > safety of externally programming the board. I don't have the schematics and > I wonder if there could be any risk of damaging the board. To be safe, there should be some sort of isolation between the mainboard components and the programmer. If you don't have schematics of the main- board, you can't tell if there is any on the board already, and I would suggest a "qspimux" [2]. Usually a connector for it is soldered to the board, but it should be possible to use a DIP8 socket too. Nico [1] https://github.com/dword1511/stm32-vserprog [2] https://github.com/felixheld/qspimux ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Placing coreboot in system memory
Hi, On 11.11.21 14:05, Julian Stecklina wrote: > with the following patch, the Qemu coreboot image indeed does not write to ROM > anymore. > > The question is whether this is behavior that is also considered broken on > qemu? > > diff --git a/src/mainboard/emulation/qemu-i440fx/Kconfig > b/src/mainboard/emulation/qemu-i440fx/Kconfig > index 19f0fca5abe9..eba8d00bd761 100644 > --- a/src/mainboard/emulation/qemu-i440fx/Kconfig > +++ b/src/mainboard/emulation/qemu-i440fx/Kconfig > @@ -15,7 +15,7 @@ config BOARD_SPECIFIC_OPTIONS > select MAINBOARD_FORCE_NATIVE_VGA_INIT > select HAVE_ASAN_IN_ROMSTAGE > select NO_SMM > - select BOOT_DEVICE_NOT_SPI_FLASH > + select BOOT_DEVICE_SPI_FLASH this wouldn't be correct as QEMU doesn't emulate SPI, IIRC. However, selecting BOOT_DEVICE_MEMORY_MAPPED directly would reflect reality. Not sure if it's that easy, though ;) Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Placing coreboot in system memory
Am 10.11.21 um 10:43 schrieb Nico Huber: Hi Julian, Am 10.11.21 um 10:02 schrieb Julian Stecklina: CBFS: Found 'fallback/romstage' @0x80 size 0x3ba0 in mcache @0x00014e2c WARN - MOVS to ROM at RIP dc2f RCX ee8 ff200300->ff200300 The warning is from us. Improvising a stack trace at this point yields: cbfs_prog_stage_load -> cbfs_load_and_decompress.isra.5 -> rdev_readat -> mdev_readat -> mdev -> memcpy In cbfs_prog_stage_load, I can see this code: size_t fsize = cbfs_load_and_decompress(, prog_start(pstage), prog_size(pstage), compression, file_hash); And here prog_start() definitely returns the pointer 0xff20_0300, which points into ROM. Passing a pointer to ROM as a writable pointer feels wrong. Given that the code just does memcpy with src=dst in this buffer, this all is harmless, but it feels a bit like "works by accident". Am I missing something? no, I think you are not. It really seems odd. In `src/lib/cbfs.c:553` there is a comment: /* Hacky way to not load programs over read only media. The stages * that would hit this path initialize themselves. */ AIUI, this "hacky way" should be taken, so cbfs_load_and_decompress() would never be called. First, I'd check if the path is tried, i.e. check the .config file if these are set to `y`: * CONFIG_NO_XIP_EARLY_STAGES Sorry, this one is inverted in the condition, it should be set to no / unset, of course. Nico * CONFIG_BOOT_DEVICE_MEMORY_MAPPED If they are, it's still possible that something fails and it falls back to cbfs_load_and_decompress(). In that case, further debugging might be needed. Cheers, Nico OpenPGP_0xBD56B4A4138B3CE3.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Placing coreboot in system memory
Hi Julian, Am 10.11.21 um 10:02 schrieb Julian Stecklina: CBFS: Found 'fallback/romstage' @0x80 size 0x3ba0 in mcache @0x00014e2c WARN - MOVS to ROM at RIP dc2f RCX ee8 ff200300->ff200300 The warning is from us. Improvising a stack trace at this point yields: cbfs_prog_stage_load -> cbfs_load_and_decompress.isra.5 -> rdev_readat -> mdev_readat -> mdev -> memcpy In cbfs_prog_stage_load, I can see this code: size_t fsize = cbfs_load_and_decompress(, prog_start(pstage), prog_size(pstage), compression, file_hash); And here prog_start() definitely returns the pointer 0xff20_0300, which points into ROM. Passing a pointer to ROM as a writable pointer feels wrong. Given that the code just does memcpy with src=dst in this buffer, this all is harmless, but it feels a bit like "works by accident". Am I missing something? no, I think you are not. It really seems odd. In `src/lib/cbfs.c:553` there is a comment: /* Hacky way to not load programs over read only media. The stages * that would hit this path initialize themselves. */ AIUI, this "hacky way" should be taken, so cbfs_load_and_decompress() would never be called. First, I'd check if the path is tried, i.e. check the .config file if these are set to `y`: * CONFIG_NO_XIP_EARLY_STAGES * CONFIG_BOOT_DEVICE_MEMORY_MAPPED If they are, it's still possible that something fails and it falls back to cbfs_load_and_decompress(). In that case, further debugging might be needed. Cheers, Nico OpenPGP_0xBD56B4A4138B3CE3.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
