Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

On Sun, May 12, 2024 at 10:55 PM ibrahim via 9fans <9fans@9fans.net> wrote: > > > Please correct me if I'm wrong. > Permalink > > In my opinion? you are wrong. And that's as far as I will stay involved in this

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

On Sun, May 12, 2024 at 8:53 PM ibrahim via 9fans <9fans@9fans.net> wrote: > Not a single developer who uses plan9 for distributed systems, commercial > products will dare to use a system like 9front as the sources. The reason > is quite simple : > > You ignore copyrights as you please and

Re: [9fans] troll paper

The author of the paper not only helped get the conference going this year, he worked hard this and last year to make sure our youtube channel worked. He also has done a lot of work to get faculty from U. Bamberg in Germany on board. The author was a major part of making IWP9 2024 go so well.

Re: [9fans] openat()

openat gives you the effect of 'cd path; open file' without having to cd. I don't see a lot of benefit to it unless you're opening a lot of files at that path. My first reaction, assuming you have a lot of files in that directory, was something like bind /dir /n/x and then just open /n/x/file...

Re: [9fans] openat()

024, 22:12 Gorka Guardiola wrote: >> >>> ¿Isn't that fd2path, strcat and open? >>> Or am I misunderstanding something? >>> >>> On Fri, Apr 5, 2024, 21:51 ron minnich wrote: >>> >>>> One of the folks I worked with, when we pulled a b

[9fans] openat()

One of the folks I worked with, when we pulled a big chunk of plan 9 into akaros, commented that he had implemented openat on akaros. I don't want this to turn into a debate on the merits of openat; I am more curious: if you went to implement openat on Plan 9, how would you go about it? I have a

[coreboot] Re: [coreboot - Bug #524] `CONFIG_X2APIC_ONLY=y`or `CONFIG_X2APIC_RUNTIME=y` cause Linux in emulation/qemu-i440fx to crash

This is another example of "don't try to support impossible hardware" :-) The real bug is that coreboot build system let you build the i440fx with APIC2, right? I assume that's what Paul meant. OTOH, it is a way to test that linux properly fails when told to use impossible hardware :-) On Mon,

[coreboot] Re: QEMU x86 i440fx/piix4 build fails for >= 32MB ROMs - Assertion IS_HOST_SPACE_ADDRESS(host_space_address) failed

h for me to put 9 of 10 > > floppies of the collection described here (thanks to LZMA compression) > > - > http://dangerousprototypes.com/docs/Lenovo_G505S_hacking#Useful_floppies > > , guess what wonders we can do with 31 MB... ;-) > > > > On Mon, Feb 19, 2024 at 7:17 

[coreboot] Re: QEMU x86 i440fx/piix4 build fails for >= 32MB ROMs - Assertion IS_HOST_SPACE_ADDRESS(host_space_address) failed

Can the system you are discussing actually use larger than 16 MB rom? I am wondering about your use of the phrase “out of curiosity” On Mon, Feb 19, 2024 at 07:05 Mike Banon wrote: > Small bump, I am still having this error while (out of curiosity) > trying to build the Lenovo G505S ROM for

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

While it is true that there are binary blobs in coreboot today, that was not always the case. From 1999 to about 2011, all coreboot images were built from 100% source code, most of it GPL, some of it BSD-style license (e.g. microcode). Around 2006, Intel made it impossible to continue with open

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

Were it not for the fact that we've been having the general open source discussion with intel for 24 years, and this graphics discussion for 10 years, we might believe that the claim of future open source is possible. Intel did not take open source into account when Intel wrote this code; why

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

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. Code that is truly common can then be factored out into places such

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

There have always been two approaches to new mainboards in coreboot. The first, "copy and convert", is to take the most similar board, copy the code, and then change it. I believe this is the strategy paul is unhappy with. The second, "embrace and extend", is to modify existing board in place to

[coreboot] Re: proposal for cross compilation: add Rust support

y. > > Am Sa., 1. Apr. 2023 um 18:07 Uhr schrieb ron minnich >: > >> https://review.coreboot.org/c/coreboot/+/74124 >> >> First step, which I almost certainly did incorrectly, is to add Rust >> toolchain support to the Makefile. >> >> Next, addi

[coreboot] proposal for cross compilation: add Rust support

https://review.coreboot.org/c/coreboot/+/74124 First step, which I almost certainly did incorrectly, is to add Rust toolchain support to the Makefile. Next, adding a rust payload was suggested. I'll look into that, probably rewriting linuxcheck in rust (since I'm the only user anyway :-)

[coreboot] Re: Toolchain build on Ubuntu 22.04 fails (at GCC 8.3.0)?

Ron, > > > Am 08.01.23 um 20:16 schrieb ron minnich: > > But in some cases static libs are no longer provided at all. Would be > nice > > to know if that's the case for libuuid. > > The static library is part of `uuid-dev` [1]: > > /usr/include/uuid/uuid.h >

[coreboot] Re: Toolchain build on Ubuntu 22.04 fails (at GCC 8.3.0)?

and I'll >> supply images and instructions to get you up and running. >> >> Martin >> >> Jan 8, 2023, 12:16 by rminn...@gmail.com: >> >> > But in some cases static libs are no longer provided at all. Would be >> nice to know if that's the case for libuuid. >

[coreboot] Re: Toolchain build on Ubuntu 22.04 fails (at GCC 8.3.0)?

But in some cases static libs are no longer provided at all. Would be nice to know if that's the case for libuuid. On Sun, Jan 8, 2023, 9:24 AM Nico Huber wrote: > On 08.01.23 17:42, ron minnich wrote: > > For reasons I still don't understand, the various linux distros no longer

[coreboot] Re: Toolchain build on Ubuntu 22.04 fails (at GCC 8.3.0)?

If i look on ubuntu 18 I see this: /usr/lib/x86_64-linux-gnu/libuuid.a If I look on ubuntu 22, it's no longer there. to build firmware with this sort of library, you need the .a (which is for static linking). Somewhat ironic, for UEFI, since the entire DXE model is built on the DLL model, that

Re: [9fans] A few questions about 9p

Tflush is harder than it looks, given that it is part of a giant race condition. Will you get the R for the message you are flushing right after you send Tflush? What happens at the server? It's fun. Perhaps one of the biggest uses of 9p, globally, was google's gvisor, which runs an unimaginably

Re: [9fans] How can I compile c code written for plan9 in ANIS C compiler

(...){ <+... m->d ...+> } @@ function mr.f; position mr.p; @@ f@p(...) { ++ Mach *m = machp(); ... } spatch is pretty amazing. On Tue, Oct 11, 2022 at 12:32 PM ron minnich wrote: > we used the coccinnelle tool (spatch) to convert about 1.4M lines of Plan > 9 code to

Re: [9fans] How can I compile c code written for plan9 in ANIS C compiler

we used the coccinnelle tool (spatch) to convert about 1.4M lines of Plan 9 code to C11 for harvey. It was not perfect, but it did get a lot right. This even got pretty complex: in amd64 Plan 9, r14 and r15 are dedicated to up and mach. This is not portable, so we wanted to make it explicit. So

[coreboot] Re: FSP 2.4: runtime blobs!

y >> >> https://universalscalablefirmware.groups.io/g/discussion >> >> >> >> What is USF? Links to USF training videos: >> https://www.youtube.com/playlist?list=PLehYIRQs6PR5N73cbW8CPvU_stDTAG_j5 >> >> >> >> Thanks, >> >>

[coreboot] Re: FSP 2.4: runtime blobs!

note that I am having this exact same problem in the RISC-V community: https://github.com/riscv-non-isa/riscv-sbi-doc/issues/102 People just like their SMM. It's hard to kill. I fear that you're not going to get much luck with Intel, which is why I try to work with non-Intel CPUs as much as I

[9fans] possible factotum device?

https://github.com/tillitis/tillitis-key1 we got handed these at OSFC. The app it comes with: https://github.com/tillitis/tillitis-key1-apps/blob/main/signerapp/main.c which they use to implement an ssh agent. The device looks like a serial. It's a lattice FPGA and the bitstream (which you can

[coreboot] Re: Verifiable UEFI OS

gt; coreboot + edk2 firmware and install ChromeOS Flex, than to build > their own ChromiumOS (vs ChromeOS, since the private overlays are not > available) and manage updates > > On Mon, Sep 5, 2022 at 4:21 PM ron minnich wrote: > > > > I'm completely lost. Why would you update

[coreboot] Re: Verifiable UEFI OS

I'm completely lost. Why would you update a chromebook to chromeos flex when you can build chromeos and install that. Did you know that you can build chromeos from source, rekey the chromebook, and then it will boot in normal mode with your build? You can even run the chromeos OTA service from a

[coreboot] Re: Intel Quark - a quick update

Do we have criteria on which to decide if quark is worth keeping? Is there a deadline for the work? At some point, you're going to find code changing out from under you; are you committing to be the maintainer? On Tue, Jul 19, 2022 at 7:45 AM Angel Pons wrote: > > Hi Andy, > > On Tue, Jul 19,

[coreboot] Re: Reconsidering the Gerrit submission strategy

I like it. We do this on most of my other projects. On Thu, Jul 14, 2022, 6:12 AM Peter Stuge wrote: > Patrick Georgi via coreboot wrote: > > I was recently made aware that Gerrit now supports adding metadata to > > commit messages in the "rebase" strategy. > > That's cool! > > > > It's a

[coreboot] Re: Intel Quark - a quick update

so how's it going? On Tue, Apr 26, 2022 at 8:41 AM Martin Roth via coreboot wrote: > > Thanks Andy, I think that's totally reasonable. > Martin > > Apr 26, 2022, 06:56 by andy.p...@sdcsystems.com: > > > Felix wrote... > > > > >So, will you also step up as a maintainer for it? > > I’m going to

[coreboot] Re: POST codes and PCI Post card

They are incredibly useful, which is why they are still there. That first post-bist code has been there since the first code in 1999. If you have jtag, it still helps. But many BMC also have ways to see port 80 writes. You can see it before PCI is up. On Mon, Jul 11, 2022 at 8:00 AM Pedro

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

I've asked the software freedom conservancy to take a look. On Wed, Jun 29, 2022, 2:48 PM Hal Martin wrote: > Hello, > > Several Cisco Meraki products (MX84, MX250) are using the coreboot > bootloader. Meraki are also distributing coreboot builds for these products > via their update mechanism.

Re: [9fans] 9p server to multiply 9p messages?

On Tue, May 31, 2022 at 11:29 AM hiro <23h...@gmail.com> wrote: > > so virtiofs is not using 9p any more? > > and with 10 million parallel requests, why shouldn't 9p be able to > deliver 10GB/s ?! Everyone always says this. I used to say it too. 9p requires a certain degree of ordering -- as

Re: [9fans] 9p server to multiply 9p messages?

On Mon, May 30, 2022 at 12:21 AM Bakul Shah wrote: > 9p itself is low performance but that is a separate issue. Bakul, what are the units? It might be helpful to quantify this statement. Are you possibly conflating Plan 9 file systems being slow and 9p being slow? As Rob pointed out in 2013,

Re: [9fans] 9p server to multiply 9p messages?

not for 9p, but in 1993, when Gene Kim interned with me at the Supercomputing Research Center, we did this: https://www.semanticscholar.org/paper/Bigfoot-NFS-%3A-A-Parallel-File-Striping-NFS-Server-(-Kim/19cb61337bab7b4de856fcbf29b55965647be091, similar in spirit to your idea. The core idea was

[coreboot] Re: [RFC] #pragma once

ese days it's sufficient to assume clang > will catch any real problems (CB:62173). > > > > On Mon, May 16, 2022 at 1:03 PM ron minnich wrote: >> >> we have, in the past, used Linux kernel style as our guideline on >> coreboot style. >> >> I'd say, based

[coreboot] Re: [RFC] #pragma once

come up. On Mon, May 16, 2022 at 12:34 PM Martin Roth wrote: > > After reading what I've included below, I'm going to have to vote to keep the > guards. > Martin > > May 16, 2022, 10:59 by david.hendri...@gmail.com: > > > On Mon, May 16, 2022 at 8:59 AM ron minnic

[coreboot] Re: [RFC] #pragma once

good idea. On Mon, May 16, 2022 at 9:59 AM David Hendricks wrote: > > On Mon, May 16, 2022 at 8:59 AM ron minnich wrote: > > > > btw, sometimes this has gone the other direction .. > > https://github.com/lowRISC/opentitan/pull/5693 > > It looks like they did that s

[coreboot] Re: [RFC] #pragma once

btw, sometimes this has gone the other direction .. https://github.com/lowRISC/opentitan/pull/5693 On Mon, May 16, 2022 at 3:04 AM Angel Pons wrote: > > Hi Arthur, list, > > On Sun, May 15, 2022 at 6:56 PM Arthur Heymans wrote: > > > > Hi > > > > To make sure headers don't create conflicts,

[coreboot] Re: Automated Engineering Notes was Re: Deprecation of the Intel Quark SoC

yeah, I ran out of time for now. On Mon, May 2, 2022 at 10:57 AM Karl Semich <0xl...@gmail.com> wrote: > > I'm not working on this but am still interested in the idea, in my hobby > capacity. The below emails were exchanged. I didn't yet receive further reply. > > -- Forwarded message

[coreboot] Re: Deprecation of the Intel Quark SoC

On Fri, Apr 22, 2022 at 11:59 PM Karl Semich <0xl...@gmail.com> wrote: >> >> We are deprecating ALL boards on oreboot that need FSP, as we took the >> decision a few weeks ago to drop boards >> that require blobs on the main CPU (we're accepting PSP blobs for now) > > > Just a quick note that our

[coreboot] Re: Open letter to Intel regarding the PSE on Elkhart Lake

Nice job Werner, I'm completely shocked! On Thu, Apr 21, 2022, 10:24 PM Zeh, Werner wrote: > Hi everybody. > > It has been a while now that we started the open letter to Intel regarding > open-sourcing the PSE firmware. > I am now happy to announce that all this effort was not worthless! >

[coreboot] Re: Deprecation of the Intel Quark SoC

oh oops the person doing that misunderstood me, we'll have to fix it On Fri, Apr 22, 2022 at 5:41 PM Martin Roth wrote: > > Hey Ron, > I think this is a good plan. We can make a markdown file doing the same. > I'm not sure that coreboot wants to record where it's deleted, but instead > the

[coreboot] Re: Deprecation of the Intel Quark SoC

we may be saying the same thing, but that commit in our file is the "check this out to get this board" ref. On Fri, Apr 22, 2022 at 5:41 PM Martin Roth wrote: > > Hey Ron, > I think this is a good plan. We can make a markdown file doing the same. > I'm not sure that coreboot wants to

[coreboot] Re: Deprecation of the Intel Quark SoC

The discussion here has been pretty helpful to my thinking. I think the concerns people are raising are important. We are deprecating ALL boards on oreboot that need FSP, as we took the decision a few weeks ago to drop boards that require blobs on the main CPU (we're accepting PSP blobs for now)

[coreboot] Re: Two Payloads

for a good example of matt's (1) above, see the pc engines apu2 coreboot image. It's very nice. On Thu, Apr 21, 2022 at 7:05 AM Matt DeVillier wrote: > > there are two ways to handle multiple payloads in coreboot: > > 1) have a single primary payload, which provides the mechanism to > execute

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

Arthur, your proposal would actually make things worse, surprisingly. While your proposal would fix a problem, it would change the binary layout, and create a problem. Consider the case of a 10y old coreboot, with a modern kernel (Linux) booting from it. How does linux parse the structures?

[coreboot] Re: lb_serial: drop 'uart_pci_addr' entry

Wow, that one chip-specific kludge impacts almost 10 source files. On Sun, Apr 17, 2022 at 11:15 AM ron minnich wrote: > > yes, and this is a perfect example of how one platform, which is not > used, can cause unneeded features to persist and make the codebase > more complex t

[coreboot] Re: lb_serial: drop 'uart_pci_addr' entry

yes, and this is a perfect example of how one platform, which is not used, can cause unneeded features to persist and make the codebase more complex than it needs to be. I support dropping it. On Sun, Apr 17, 2022 at 2:12 AM Arthur Heymans wrote: > > Hi > > In 2016 'uart_pci_addr' was added to

[coreboot] Re: Deprecation of the Intel Quark SoC

to record mainboards we've dropped, with their commit, so memory is not lost. Maybe with tags, maybe with plain text file, not sure. It's possible whatever we try out will work for coreboot, but we'll see. On Sat, Apr 16, 2022 at 8:25 AM ron minnich wrote: > > nico, it was not so much a matter

[coreboot] Re: Deprecation of the Intel Quark SoC

nico, it was not so much a matter of me jumping on the bandwagon, as my reluctance to get involved in another never-ending discussion over retiring a platform that nobody uses or cares about. But let's keep it simple. I think it's clear that the effort to maintain the Quark is > 0. The number of

[coreboot] Re: Deprecation of the Intel Quark SoC

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've had a lot of commitments before, but everyone is busy, and hopes can outrun

[coreboot] Re: Deprecation of the Intel Quark SoC

do you have a way to recover if the flash fails? On Thu, Apr 14, 2022 at 1:09 PM Andy Pont wrote: > > Karl wrote… > > >Obviously a way to sidestep all this would be to simply test the board > >in question, which is a small investment of money and time. > There is still one of these boards (Intel

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

agree totally on how to lay out data structures. UPD are also a major pain for non-C firmware, such as oreboot. So I'd like a data format that is not defined by a compiler or language. But maybe I'm the only person who wants that :-) On Tue, Apr 12, 2022 at 11:45 AM Peter Stuge wrote: > &g

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

peter, you are right about CBOR, and that says to me it does not really meet the original goal of self-describing data. But coreboot tables, at least in my understanding, is also not self-describing. Do you have some thoughts on a good format that is self-describing? On Mon, Apr 11, 2022 at 3:05

[coreboot] Re: Another day, another SMM loader vulnerability

arthur, what might we do with either the build process or startup to avoid this problem in future? Do you think we could find a way to catch this programmatically soon, rather than humanly too late? On Mon, Apr 11, 2022 at 2:48 AM Arthur Heymans wrote: > > Hi > > After last week's SMM loader

[coreboot] Re: Deprecation of the Intel Quark SoC

Does anyone even have one? Has anyone done a build and burn recently to test? Has anyone volunteered to maintain it? How much does it it impact other code as a special case? I threw mine out years ago. On Fri, Apr 1, 2022 at 6:19 AM Peter Stuge wrote: > > Felix Singer wrote: > > to me it seems

[coreboot] Re: Deprecation of the Intel Quark SoC

go for it. Long overdue. On Thu, Mar 31, 2022 at 1:55 PM Felix Singer wrote: > > Hi all, > > to me it seems like the Intel Quark SoC has been unmaintained and > unused for a long time now. So I'm proposing to deprecate the support > for it with coreboot release 4.17 [1], in order to drop the

[coreboot] Re: [GSoC 2022] Interested in Contributing to coreboot.

he current U-Boot payload in coreboot supports UEFI. > In the UEFI working group meeting there was a suggestion to take just > the UEFI code from U-Boot and build our own payload for coreboot. > > > On Sat, Mar 12, 2022 at 11:41 PM ron minnich wrote: >> >> so is your

[coreboot] Re: [GSoC 2022] Interested in Contributing to coreboot.

so is your plan to port the UEFI code as a payload or to use u-boot as a payload and then use their UEFI support? On Sat, Mar 12, 2022 at 9:36 AM Ahamed Husni wrote: > > Hi everyone, > > On Fri, Feb 25, 2022 at 4:21 PM Ahamed Husni wrote: > > > > Dear All, > > > > I am hoping to apply for the

Re: [9fans] licence question

This one statement: "Berkeley stopped their distribution of BSD systems right after they were forced to remove the toolchain." is completely wrong. I just asked the people who were there, on TUHS, and they confirmed my memory: DARPA funding for BSD support ended in 1995, and that was probably the

Re: [9fans] licence question

On Sat, Jan 29, 2022 at 6:19 PM ibrahim via 9fans <9fans@9fans.net> wrote: > As far as I recall OpenBSD (Theo dR) was interested in BSD licensed compilers > at that time and that didn't happen. That happened about 10 years earlier. The effort I am talking about with jmk was 2013; the dustup

Re: [9fans] licence question

"Why do you think p9f asked for a relicensing of plan9 while it was already gpl licensed a few years ago ? Both are redistributable but the MIT version is also usable for closed source commercial projects while the GPL version is not. Does this matter ? Yes of course it matters for people or

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

if these boards are to see maintenance in the future, so > I figured it made sense to just start with that. > > > On 5/12/21 5:53 am, ron minnich wrote: > > 100 hours of work for 50 boards? 2 hours per board? Each one fully > > tested and working as before? 'm pretty surprised.

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

ly buy a round of beer (or equivalent) for anyone who can provide a > clear picture of what the road forward looks like. Then we can at least talk > in grounded terms. > > -Matt > > On Wed, Dec 1, 2021 at 12:51 PM ron minnich wrote: >> >> We've always deprec

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

We've always deprecated platforms. And they're still in tree -- you can build for DEC Alpha if you want. There's no shame in not being in the latest release. Given unlimited time and money and people, we could fix all the problems. We live in a world of limits, and must do what we can with the

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

having read this discussion, and with all respect for all the opinions so clearly expressed, I still support Arthur's original proposal. On Sun, Nov 28, 2021 at 2:20 PM David Hendricks wrote: > > > >> 1. These boards will be gone for the people who check the "mainboards >> supported by

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

The word 'drop' has ominous connotations, but it's not a deletion. A board is never really gone. It's git. I can still find the Alpha boards in there if I go back far enough. It's just that active development ends, as no one is working to keep them up to date. Would it be ok with you to drop the

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

I think, given how good a job you've all done with the release tags and so on, it's easy for people to get to a working build for a board; therefore, deprecating non conforming platforms make sense, as does your suggestion for six months. On Wed, Nov 24, 2021 at 4:51 AM Arthur Heymans wrote: >

[coreboot] Re: Another year, another blob?

I'd like to get back to a rating system. There's a really simple measure that I've never seen improved upon, namely, for a given firmware image, what fraction of the bits in that image come from open source code? e.g., the KGPE-D16 would get a 100%, and a typical laptop would get 0%. This is a

[coreboot] Re: There is a python in our toolchain?!?

Still working on getting the setup, but 9elements reports: "We have it running as CI System attached to a Github repo and do build and boot testing on Qemu und real hardware with it." On Sat, Oct 16, 2021 at 1:39 AM Patrick Georgi wrote: > > Am Sa., 16. Okt. 2021 um 02:40 Uhr sch

[coreboot] Re: There is a python in our toolchain?!?

I would rather we not start depending on pytest. Just my take.There's a difference between a utility for one chipset and global infrastructure, and pytest could become the latter. There's a pretty big testing activity starting up in OCP, involving many companies, and python is not something we

[coreboot] Re: There is a python in our toolchain?!?

;> Regards, >> Patrick >> >> Am Mo., 4. Okt. 2021 um 18:59 Uhr schrieb Ricardo Quesada < >> ricar...@google.com>: >> >>> Hi all, >>> >>> Regarding Patrick's 2nd point (end-to-end testing), what's the recommend >>> way to go

[coreboot] Re: There is a python in our toolchain?!?

i all, >> >> Regarding Patrick's 2nd point (end-to-end testing), what's the recommend way >> to go forward? >> I just need to run one of the Coreboot's utils (in this case "elogtool"), >> and make sure the output is the expected one. >> >> Should I use Con

[coreboot] Re: Atomic Accesses to Local APIC

Stuge wrote: > > ron minnich wrote: > > same applies to new software applied to antiques. > > While you are correct for some software and some antiques I find this > premise completely unacceptable. This attitude may be convenient for > developers but it only further normal

[coreboot] Re: Atomic Accesses to Local APIC

ums remain. > > On Tue, Oct 5, 2021 at 4:06 PM ron minnich wrote: >> >> That's what versions are all about. It seems sensible to me to leave >> the old bad stuff behind; if people need it, it's all still there if >> they know the tag. >> >> On Tue, Oct 5, 2

[coreboot] Re: Atomic Accesses to Local APIC

ere any more of these buggy pentiums left in the coreboot tree? (If he > chooses to update) I can imagine RMS getting real snippy if we break his > thinkpad. :P > > On Tue, Oct 5, 2021 at 3:53 PM ron minnich wrote: >> >> nice fine. Might be worth adding the text of this comment

[coreboot] Re: Atomic Accesses to Local APIC

nice fine. Might be worth adding the text of this comment (modified as needed) to the CL so that in years to come people understand the reasons. On Tue, Oct 5, 2021 at 12:51 PM Matt B wrote: > > A quick google turned this up: >

[coreboot] Re: Atomic Accesses to Local APIC

I would be happy if all those old buggy systems were gone, good idea Peter! On Mon, Oct 4, 2021 at 9:39 AM Peter Stuge wrote: > > ron minnich wrote: > > The problem, at this point, is that a change this broad must also be > > tested across all platforms to make sure it's not b

[coreboot] Re: Atomic Accesses to Local APIC

Julian Stecklina wrote: > > On Mon, 2021-10-04 at 07:32 -0700, ron minnich wrote: > > that was pre-git but is there any useful comment in git anyway? I only > > have the vaguest memory of why it went in. > > It was introduced in c84c1906b7 and fcd5ace00b3 without expla

[coreboot] Re: PXE on Coreboot

use linuxboot, don't use UEFI payload. That's what we've done at Google, among other companies (ByteDance too). if you use linuxboot, then you get our pxeboot written in Go, and that can use http to pull the image down as well as tftp; http is literally (measured) 100x faster. I would avoid

[coreboot] Re: Atomic Accesses to Local APIC

that was pre-git but is there any useful comment in git anyway? I only have the vaguest memory of why it went in. On Mon, Oct 4, 2021 at 7:14 AM Julian Stecklina wrote: > > Hello, > > I was looking at the Local APIC code in coreboot and was wondering about > `lapic_write_atomic` in

[coreboot] Re: There is a python in our toolchain?!?

Speaking as the person who wrote the first few config tools in python, and was happy to see the python dependency gone, I think bringing python back in would be a mistake. Every single python test framework I've worked with works until there is a problem, and I then find myself having to walk

[coreboot] Re: RFC: On testing and reporting how well coreboot does on real hardware

I think there are two issues here. First, we can't get it all right at once. But, second, we have to think in terms of eventual scale. The system will need to make the status of hundreds of motherboards accessible. The Google doc is wonderful for a deep dive, but a bit overwhelming as the first

Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages

*François > Ozog via TF-A > *Sent:* Thursday, June 17, 2021 12:57 PM > *To:* Simon Glass > *Cc:* Ed Stuber ; Boot Architecture Mailman > List ; Harb Abdulhamid OS < > abdulha...@os.amperecomputing.com>; U-Boot Mailing List < > u-b...@lists.denx.de>; Arjun Khare ; >

Re: [OCP-OSF] Firmware: Sustainability vs planned obsolescence

on space) it can be anything you all think best. On Thu, Apr 15, 2021 at 2:49 PM Desimone, Nathaniel L wrote: > > On Thu, Apr 15, 2021 at 1:29 -0700, ron minnich wrote: > > >I'd rather not take HOB as a given without considering alternatives. > >It's a very 1990s design. > >

Re: [OCP-OSF] Firmware: Sustainability vs planned obsolescence

On Thu, Apr 15, 2021 at 11:25 AM François Ozog wrote: > > > "packed" at least works otherwise no network protocol would be operating > as expected. > that is a very common misconception. C code for networks existed for decades before packed existed. packed does not exist in plan 9 compilers to

Re: [OCP-OSF] Firmware: Sustainability vs planned obsolescence

tainable Firmware" to today's OSF call agenda if > anyone is interested in discussions. > > For instructions on joining the call (it's in 30 mins, but repeats every > second week): https://www.opencompute.org/projects/open-system-firmware > > Thanks, > Ryan > &

Re: [OCP-OSF] Firmware: Sustainability vs planned obsolescence

I do wonder if you have read the OSF doc. That was a lot of work over a near 3 year period, and your doc looks like the very early drafts of that doc. I think it would pay to take a look. On Wed, Apr 14, 2021 at 10:52 PM Loïc Minier wrote: > Hi! > > Sorry for the late reply, here's a draft the

Re: [OCP-OSF] Firmware: Sustainability vs planned obsolescence

You can see how quickly this gets complicated. It is why we tried to keep the OSF requirements as simple as possible. The requirements, in their most basic form, allow owners of systems to modify firmware, install it, and share it. Open source is not required. But for customers to install

Re: [9fans] Transfer of Plan 9 to the Plan 9 Foundation

The LPL is dead. It died when all the Plan 9 IP was transferred to the foundation. Nokia is out of the picture. So let's realign this discussion a bit. The Plan 9 source formerly owned by Nokia is owned by the foundation. That source is released under the MIT license. As for the inclusion of

Re: [9fans] Can compile Plan9 C compiler for windows10?

Nxm built kencen toolchain on Linux. https://github.com/rminnich/NxM We could build all of plan9 on Linux. You might be able to start there and produce .Exe's. Not tested for quite some time now. Derived from nix. On Sun, Mar 28, 2021, 6:17 AM wrote: > uh inferno's 8c compiles .exe file? >

Re: [PATCH] mtd: parser: cmdline: Support MTD names containing one or more colons

It is likely we're missing something -- I am not fully checked out on the Linux patch process and it's Ian's first patch. Guidance appreciated. On Mon, Jan 4, 2021 at 1:08 AM Miquel Raynal wrote: > > Hello Ian, > > Ian Goegebuer wrote on Wed, 23 Dec 2020 13:56:30 > -0800: > > > On Intel

Re: [PATCH] mtd: parser: cmdline: Support MTD names containing one or more colons

Tested-by: Ian Goegebuer On Mon, Dec 7, 2020 at 7:24 AM ron minnich wrote: > > I pinged the person again. Hope to hear today. Sorry for delay. > > On Sun, Dec 6, 2020 at 11:52 PM Sven Eckelmann wrote: > > > > On Friday, 27 November 2020 19:54:30 CET ron minnich w

Re: [PATCH] mtd: parser: cmdline: Support MTD names containing one or more colons

I pinged the person again. Hope to hear today. Sorry for delay. On Sun, Dec 6, 2020 at 11:52 PM Sven Eckelmann wrote: > > On Friday, 27 November 2020 19:54:30 CET ron minnich wrote: > > Thanks, Sven, for your patience, I will indeed try to test this next week. > > Any test

Re: [PATCH] mtd: parser: cmdline: Support MTD names containing one or more colons

Thanks, Sven, for your patience, I will indeed try to test this next week. On Fri, Nov 27, 2020 at 9:35 AM Sven Eckelmann wrote: > > On Friday, 27 November 2020 18:16:54 CET ron minnich wrote: > > What none of the people involved in the original patch knew was that > > th

Re: [PATCH] mtd: parser: cmdline: Support MTD names containing one or more colons

preserve current behavior and support PCI device specifiers? Ron On Fri, Nov 27, 2020 at 9:06 AM Sven Eckelmann wrote: > > On Friday, 27 November 2020 17:32:02 CET ron minnich wrote: > > I'm a bit worried about how tricky this starts to get. I'm inclined to > > go back to an earl

Re: [PATCH] mtd: parser: cmdline: Support MTD names containing one or more colons

possible. Let's fix the parser to gracefully > > handle that case: the last ':' in a partition definition sequence is > > considered instead of the first one. > > > > Signed-off-by: Boris Brezillon > > Signed-off-by: Ron Minnich > > Tested-by

[coreboot] Re: Deprecating spurious PCI bus master enabling (was Re: Planning the next coreboot release)

nice idea! On Tue, Nov 10, 2020 at 7:13 AM Nico Huber wrote: > > On 10.11.20 16:06, Nico Huber wrote: > > If anybody knows or discovers more cases where it needs to be enabled > > in advance by coreboot, please mention it here. > > We just discussed on IRC cases where unfixable OS drivers might

[coreboot] Re: Universal Payload - RFC and Invitation from Universal Payload community

Thanks for the note. I think you're going at this somewhat backwards. While this may seem to you to be a universal payload, to many it appears to be "make everybody support UEFI model." As you have seen, this will not be well received. As Peter points out, the coreboot payload model is simple,

  1   2   3   4   5   6   7   8   9   10   >