[coreboot] Re: Monochrome coreboot logo as BMP?
Hi Nico, On Mon, 20 Nov 2023 at 02:45, Nico Huber wrote: > > Hi, > > On 19.11.23 19:39, Simon Glass wrote: > > Could I get your sign-off somehow? You could add it here, or reply on > > the U-Boot ML when I send the patch. > > oh, right. Signing off on my modification of the logo. > > Signed-off-by: Nico Huber > > Additionally, the logo's license applies: > https://coreboot.org/Logo#coreboot_Logo_License OK, thank you, this is sent[1]. I cannot add the licence in the BMP but I did mention it in the patch. I'm not sure if there is another way to tag the file, but we'll see what people think. Regards, Simon [1] https://patchwork.ozlabs.org/project/uboot/patch/20231129105207.1.Ia8c2d0b6bfb7953ea8943f41521be911a03fad6d@changeid/ ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: commit 0eab62b makes menuconfig more strict regarding the old configs
Thank you, the patch at https://review.coreboot.org/c/coreboot/+/79298 really helps, I +1 it now On Wed, Nov 29, 2023 at 8:39 PM Mike Banon wrote: > > At the moment none of the suggestions work (tried make oldconfig, make > olddefconfig, make menuconfig KCONFIG_WERROR=0 > KCONFIG_WARN_UNKNOWN_SYMBOLS=0 "). Any workaround alternative to git > revert of this commit would be nice > > On Wed, Nov 29, 2023 at 1:41 PM Patrick Georgi via coreboot > wrote: > > > > On 29.11.23 00:20, Martin Roth via coreboot wrote: > > > Hey Mike, > > > I think you should be able to just append change the kconfig values when > > > you run make to override the current settings. > > > > > > something like > > > `make menuconfig KCONFIG_WERROR=0 KCONFIG_WARN_UNKNOWN_SYMBOLS=0` > > > > > > if we update where they're set in the makefile from := to ?=, you could > > > even just have them set as environment variables so they don't need to be > > > on the command line. > > > > Kconfig doesn't check for the value in the variables, just for their > > presence. Therefore we'd need to unexport the variables, and that's not > > possible per-target (despite the gnu make docs claiming otherwise) or on > > the make command line. > > > > I started a discussion in another thread on that, maybe we could discuss > > this over at > > https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/M543FU2OIHEMLAFAFAPCFHAD36ISAEKO/? > > ___ > > coreboot mailing list -- coreboot@coreboot.org > > To unsubscribe send an email to coreboot-le...@coreboot.org > > > > -- > Best regards, Mike Banon > Open Source Community Manager of 3mdeb - https://3mdeb.com/ -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/ ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: commit 0eab62b makes menuconfig more strict regarding the old configs
At the moment none of the suggestions work (tried make oldconfig, make olddefconfig, make menuconfig KCONFIG_WERROR=0 KCONFIG_WARN_UNKNOWN_SYMBOLS=0 "). Any workaround alternative to git revert of this commit would be nice On Wed, Nov 29, 2023 at 1:41 PM Patrick Georgi via coreboot wrote: > > On 29.11.23 00:20, Martin Roth via coreboot wrote: > > Hey Mike, > > I think you should be able to just append change the kconfig values when > > you run make to override the current settings. > > > > something like > > `make menuconfig KCONFIG_WERROR=0 KCONFIG_WARN_UNKNOWN_SYMBOLS=0` > > > > if we update where they're set in the makefile from := to ?=, you could > > even just have them set as environment variables so they don't need to be > > on the command line. > > Kconfig doesn't check for the value in the variables, just for their > presence. Therefore we'd need to unexport the variables, and that's not > possible per-target (despite the gnu make docs claiming otherwise) or on the > make command line. > > I started a discussion in another thread on that, maybe we could discuss this > over at > https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/M543FU2OIHEMLAFAFAPCFHAD36ISAEKO/? > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/ ___ 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: RFC: Behavior of make *config
29. November 2023 12:14, "Poeche, Uwe via coreboot" schrieb: > Your above mentioned patch helps (I'm a reviewer of this). When I tried I > also noticed that this > does not point out loudly if you have problems in your config. So the > approach without the patch > (in result more strict) is from my opinion better if we have a workaround > beside edit config > manually. In the parallel thread here Martin mentioned the same workaround as > you mentioned on IRC > on Monday. But I get not work. Right, because the code checks for the variables' presence, not for their value. I was mistaken on that, as was Martin apparently. I modified the changeset so that it still doesn't fail on warnings during *config, but still prints them. That doesn't matter a whole lot with menuconfig and nconfig because they proceed to clear the screen immediately after, but oldconfig and olddefconfig are somewhat more helpful now: $ make oldconfig /home/pgeorgi/coreboot/.config:152:warning: unknown symbol: VBT_DATA_SIZE_KB * * Restart config... * ... $ make olddefconfig /home/pgeorgi/coreboot/.config:152:warning: unknown symbol: VBT_DATA_SIZE_KB # # configuration written to /home/pgeorgi/coreboot/.config # Does that help? Patrick ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: RFC: Behavior of make *config
Hi Patrick, we two had an IRC conversation on monday about this topic but didn't finish this. Your above mentioned patch helps (I'm a reviewer of this). When I tried I also noticed that this does not point out loudly if you have problems in your config. So the approach without the patch (in result more strict) is from my opinion better if we have a workaround beside edit config manually. In the parallel thread here Martin mentioned the same workaround as you mentioned on IRC on Monday. But I get not work. I added for test a line in a working .config with "NOT_KNOWN_SWITCH=1234" which produces the error and changed now the coreboot toplevel Makefile according: -KCONFIG_WERROR:= 1 -KCONFIG_WARN_UNKNOWN_SYMBOLS:= 1 +KCONFIG_WERROR ?= 1 +KCONFIG_WARN_UNKNOWN_SYMBOLS ?= 1 And did as Martin and also you mentioned make menuconfig KCONFIG_WERROR=0 KCONFIG_WARN_UNKNOWN_SYMBOLS=0 But the error still exist. Can the cause be a dependency from make? We use v4.2.1 on Red Hat 8.8. Regards Uwe ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: commit 0eab62b makes menuconfig more strict regarding the old configs
On 29.11.23 00:20, Martin Roth via coreboot wrote: Hey Mike, I think you should be able to just append change the kconfig values when you run make to override the current settings. something like `make menuconfig KCONFIG_WERROR=0 KCONFIG_WARN_UNKNOWN_SYMBOLS=0` if we update where they're set in the makefile from := to ?=, you could even just have them set as environment variables so they don't need to be on the command line. Kconfig doesn't check for the value in the variables, just for their presence. Therefore we'd need to unexport the variables, and that's not possible per-target (despite the gnu make docs claiming otherwise) or on the make command line. I started a discussion in another thread on that, maybe we could discuss this over at https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/M543FU2OIHEMLAFAFAPCFHAD36ISAEKO/? ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
