coreboot May 2018

coreboot@coreboot.org

51 participants
137 discussions

Start a nNew thread

MX66l51235f
by ron minnich 14 May '18

14 May '18

anyone got the incantation to flash this with an sf100 ;-)

1 0

Re: [coreboot] FSP 2.0 headers in coreboot
by Timothy Pearson 11 May '18

11 May '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Not to jump too far into the fray, but couldn't this be handled by simply not blocking coreboot development on proprietary blobs? For instance, if someone wants to implement a feature that requires repository-wide changes (e.g. the timestamp stuff that went in a couple of years back) that happens to break only some blobby boards, that the feature should be implemented anyway and the broken blobby boards added back in as the vendor has time / inclination to fix? Basically, this seems to be what Linux already does for kernel work. The benefit of upstreaming open code is that other people will maintain it for you, but if you really need to publish a binary only driver (NVIDIA) then you have the full burden of maintenance on yourself as the vendor. This encourages contribution back without putting an arbitrary administrative limit on what kind of blob level is acceptable. On 05/10/2018 06:32 PM, Aaron Durbin via coreboot wrote: > On Thu, May 10, 2018 at 5:10 PM, Nico Huber <nico.h(a)gmx.de> wrote: >> Ok, I'll try to break this loop here. You are repeating the great bene- >> fits for a user (that I agree to) even if a blob is involved. And I keep >> asking why it should happen on our master branch (I don't see how we >> would take something away by not maintaining everything. Also, I never >> tried to exclude all blobs). It seems somehow we talk past each other. > > I've been meaning to respond to your original response, but I haven't > had a lot of time to articulate things. You've brought this up > numerous times; it sounds like you care what is in the master branch. > But maybe not any other branches? And what is the threshold for being > in master branch? And what audience is the master branch for? I'm > trying to envision what the development and eventual result will be. > > You have been focusing on FSP talking about maintaining it, etc, but I > don't think that maintainership is falling on people > disproportionately any more than other parts of the tree. I do find it > a bit ironic that you were te one using FSP for some of your work. > > As for the github fsp proper, the license in the headers is weird, as > Youness pointed out. But in addition to that, it says IOTG Kabylake H > as a release. It doesn't say anything beyond that from a support > standpoint. Empirically it may work, but so does the FSP generated by > Chrome OS. As I'm sure you know assets can be extracted from recovery > images for those FSPs. What's the bar for picking one over the other? > I don't believe either can be submitted into coreboot.org blobs repo? > Or did I miss where that was concluded? > > Anyway, just lots of questions -- not many statements. I'm trying to > understand the distinction when I don't see many differences of a > situation I think most people would agree is unfortunate. > >> On 10.05.2018 23:26, Julius Werner wrote: >>>> You really seem to miss the point of free software. >>> >>> Okay, now this is starting to get personal again, let's please not go >>> there. You too have been among those who spoke out against that in that >>> derailment thread recently. It's insulting to insinuate that some of us >>> don't understand or don't care about free software just because we're >>> working for a big company. You also don't need to educate me about the >>> spirit of the GPL or the fundamental travesty of jumping back and forth >>> between blobs and GPL code a dozen times during a single boot and calling >>> it okay because it's "technically not linking". I am aware of these things >>> and I'm not happy about them either. But there have been blobs in most >>> boards that were added to this project since before I started working on it >>> and there will keep being blobs for the foreseeable future. You are not >>> going to convince Intel to open-source their FSP by yelling at fellow >>> coreboot developers about it. It's the reality we live in. This discussion >>> started (as I understood it) about how we can make the blob situation we >>> *are* living with a little better, so let's keep it focused on that. >>> >>>> As long as everybody >>>> adheres to the copyleft, you can do things on your own. If a blob ends >>>> up being only useful for a single board, ok. Should somebody be able to >>>> sell his product with it, sure. But why should the community maintain >>>> that shit (partially on the shoulders of volunteers) if it doesn't pro- >>>> vide what free software provides? >>> >>> "That shit" allows people to build custom firmware for the hardware that >>> they bought, which I think is a very important and worthwhile benefit on >>> its own. For Chromebooks, a whole little ecosystem of custom ROMs and build >>> instructions has developed around this. Do you want to take that away from >>> everyone just because some of the blobs may be mainboard specific? (And >>> again, as far as I am aware most blobs aren't really tied to a specific >>> mainboard, they're just SoC support which may or may not have been written >>> to include whatever peripheral support a particular mainboard needs. You >>> are really just complaining that peripheral support which the existing >>> mainboards didn't need is not implemented yet, which is a situation that >>> can happen just as well on a fully blob-free board.) >>> >>> It's not just free software when you can port it to a completely new >>> mainboard, in the same way that the coreboot core code is still free >>> software even though you can't automatically port it to any new chipset. >>> You can still add features or make changes to customize behavior for an >>> existing board. You can make it boot your own operating system with custom >>> calling convention, add some code signing or measuring framework, or make >>> it play the Jeopardy melody on the speaker while it's booting. That, too, >>> is a benefit of free software. >>> > - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJa9Ng5AAoJEK+E3vEXDOFb7dsIAI50Zb77V97IPaspCSUJsAvm eG/yAwrdutPUVrXptGVfq3sshO2ZnyKeWNbeQPCWC2P+NsZZqCxMEo1Ozer+drPM 3euUWqv/CUIOkyjncEjcmEwvlskkGLNygTSa/NCpOHGhRaYR8RjVpD7GI5Y8E5NI +OKfZ06R4WL2tEBL6f8fr0CPA3W7jbscvwsQfV173QCrKbMX/KelkKof7gvT9JGh OJY6KqnGGtrtuRtNB0bFC0gTz1/UYGwlVhy3iW30OcXTbnvA4kiR6qv3w7k/Y95D 68wI0OdTo9Jy6lvm3BjiZwLImKiZqJmDb0nCZOPU8tqPnnc9F5zd9FMMl61UeQU= =fEKP -----END PGP SIGNATURE-----

3 2

Re: [coreboot] flashrom on osx ...
by ron minnich 11 May '18

11 May '18

not late enough, sadly, and why the heck won't this build from github repo ... uses packagemanager which is no longer a thing. On Fri, May 11, 2018 at 11:07 AM Alberto Bursi <alberto.bursi(a)outlook.it> wrote: > > On 11/05/2018 19:42, ron minnich wrote: > > if I just want to use a dediprog sf100 what's the best way to build > > flashrom on osx? > > > > besides "throw the macbook in the trash and get a real computer" :-) > > > > ron > > > > > > There is "homebrew" package manager for OSX/MacOS, see here > https://brew.sh/ > > They have latest flashrom https://formulae.brew.sh/formula/flashrom > among a big list of other commandline stuff you might find useful. > > -Alberto > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] flashrom on osx ...
by Alberto Bursi 11 May '18

11 May '18

On 11/05/2018 19:42, ron minnich wrote: > if I just want to use a dediprog sf100 what's the best way to build > flashrom on osx? > > besides "throw the macbook in the trash and get a real computer" :-) > > ron > > There is "homebrew" package manager for OSX/MacOS, see here https://brew.sh/ They have latest flashrom https://formulae.brew.sh/formula/flashrom among a big list of other commandline stuff you might find useful. -Alberto

1 0

flashrom on osx ...
by ron minnich 11 May '18

11 May '18

if I just want to use a dediprog sf100 what's the best way to build flashrom on osx? besides "throw the macbook in the trash and get a real computer" :-) ron

1 0

Building coreboot for Apollo Lake: missing 'IFWI' region
by Hal Martin 10 May '18

10 May '18

Hi all, I am trying to build coreboot for an Apollo Lake platform. I've read the coreboot presentation on Apollo Lake, and some of the threads about the IFWI on the coreboot mailing list: https://www.coreboot.org/images/2/23/Apollolake_SoC.pdf https://mail.coreboot.org/pipermail/coreboot/2017-November/085482.html https://mail.coreboot.org/pipermail/coreboot/2017-September/085217.html After reading this and digesting the information for a week, I'm still no closer to understanding how the build process is supposed to work. I have extracted the descriptor from the SPI image, and put the entire 16MB image in the 3rdparty directory. When I try to build coreboot, I'm getting the following error: Image written successfully to build/cbfs/fallback/ifwi.bin.tmp. Image does not contain sub-partition OBBP(6). Sub-partition IBBP(4) entry IBBL replaced from file build/cbfs/fallback/bootblock.bin. Image written successfully to build/cbfs/fallback/ifwi.bin.tmp. E: Image is missing 'IFWI' region E: The image will be left unmodified. src/soc/intel/apollolake/Makefile.inc:137: recipe for target 'files_added' failed make: *** [files_added] Error 1 Attached is the output of ifdtool and ifwitool for the SPI dump of the vendor firmware for platform I'm working on. A few interesting observations (from my perspective): - There doesn't seem to be an OBBP in this image. - My ifwitool output seems to match the output of others (e.g. https://mail.coreboot.org/pipermail/coreboot/2017-September/085210.html ) - This platform (CompuLab Fitlet 2) only has SPI flash, no EMMC. My understanding is that IFWI is the same whether it's on EMMC or SPI. Some open questions I have: - Is it possible to build a flashable image using only coreboot and a dump of the vendor firmware, or does one need to use the Intel FSP and FIT tools and some "stitching" to get a flashable image with a coreboot payload? - Is there any public documentation available describing the FSP 2.0/IFWI flash layout? - Is it possible to obtain FIT for Apollo Lake without having an NDA or corporate account with Intel? It seems that absolutely everything about Apollo Lake is classified as "confidential" on Intel's website: https://www.intel.com/content/www/us/en/design/products-and-solutions/proce… Can anyone who was working on an FSP 2.0 platform (e.g. Cameron Craig, Paul Penz, Morris) follow up on how they managed to build a flashable image? Thanks, Hal

1 0

Re: [coreboot] FSP 2.0 headers in coreboot
by Nico Huber 10 May '18

10 May '18

On 11.05.2018 01:32, Aaron Durbin wrote: > On Thu, May 10, 2018 at 5:10 PM, Nico Huber <nico.h(a)gmx.de> wrote: >> Ok, I'll try to break this loop here. You are repeating the great bene- >> fits for a user (that I agree to) even if a blob is involved. And I keep >> asking why it should happen on our master branch (I don't see how we >> would take something away by not maintaining everything. Also, I never >> tried to exclude all blobs). It seems somehow we talk past each other. > > I've been meaning to respond to your original response, but I haven't > had a lot of time to articulate things. You've brought this up > numerous times; it sounds like you care what is in the master branch. > But maybe not any other branches? And what is the threshold for being > in master branch? And what audience is the master branch for? I'm > trying to envision what the development and eventual result will be. As I tried to explain in my other (just sent) mail, I care most about other developers being able to pick up coreboot and use it for their boards. And this is something where we can improve a lot regarding the blob situation, IMO. I just hope, if we had rules that recommend redis- tributable blobs and push into this direction, one day, somebody new to the game (i.e. without prior contact to a silicon vendor) could again just use coreboot. > > You have been focusing on FSP talking about maintaining it, etc, but I > don't think that maintainership is falling on people > disproportionately any more than other parts of the tree. I do find it > a bit ironic that you were te one using FSP for some of your work. Well, it wasn't my choice. And after many months struggling to get a single board working, I wouldn't do it again for a new platform. Now that I know the Sky-/Kaby Lake code another board port would work out. But if things don't get better, I'd rather start reverse engineering right away for a new platform. I'm sure that would save us some time on average if somebody else would use the code, too. > > As for the github fsp proper, the license in the headers is weird, as > Youness pointed out. But in addition to that, it says IOTG Kabylake H > as a release. It doesn't say anything beyond that from a support > standpoint. Empirically it may work, but so does the FSP generated by > Chrome OS. As I'm sure you know assets can be extracted from recovery > images for those FSPs. What's the bar for picking one over the other? Can I use the CrOS FSP for a product? I'm convinced that I can use the one from GitHub. > I don't believe either can be submitted into coreboot.org blobs repo? > Or did I miss where that was concluded? If it was, I missed that too. AFAIR, I checked that once for the License on GitHub (and did not see a way). Nico > > Anyway, just lots of questions -- not many statements. I'm trying to > understand the distinction when I don't see many differences of a > situation I think most people would agree is unfortunate. > >> On 10.05.2018 23:26, Julius Werner wrote: >>>> You really seem to miss the point of free software. >>> >>> Okay, now this is starting to get personal again, let's please not go >>> there. You too have been among those who spoke out against that in that >>> derailment thread recently. It's insulting to insinuate that some of us >>> don't understand or don't care about free software just because we're >>> working for a big company. You also don't need to educate me about the >>> spirit of the GPL or the fundamental travesty of jumping back and forth >>> between blobs and GPL code a dozen times during a single boot and calling >>> it okay because it's "technically not linking". I am aware of these things >>> and I'm not happy about them either. But there have been blobs in most >>> boards that were added to this project since before I started working on it >>> and there will keep being blobs for the foreseeable future. You are not >>> going to convince Intel to open-source their FSP by yelling at fellow >>> coreboot developers about it. It's the reality we live in. This discussion >>> started (as I understood it) about how we can make the blob situation we >>> *are* living with a little better, so let's keep it focused on that. >>> >>>> As long as everybody >>>> adheres to the copyleft, you can do things on your own. If a blob ends >>>> up being only useful for a single board, ok. Should somebody be able to >>>> sell his product with it, sure. But why should the community maintain >>>> that shit (partially on the shoulders of volunteers) if it doesn't pro- >>>> vide what free software provides? >>> >>> "That shit" allows people to build custom firmware for the hardware that >>> they bought, which I think is a very important and worthwhile benefit on >>> its own. For Chromebooks, a whole little ecosystem of custom ROMs and build >>> instructions has developed around this. Do you want to take that away from >>> everyone just because some of the blobs may be mainboard specific? (And >>> again, as far as I am aware most blobs aren't really tied to a specific >>> mainboard, they're just SoC support which may or may not have been written >>> to include whatever peripheral support a particular mainboard needs. You >>> are really just complaining that peripheral support which the existing >>> mainboards didn't need is not implemented yet, which is a situation that >>> can happen just as well on a fully blob-free board.) >>> >>> It's not just free software when you can port it to a completely new >>> mainboard, in the same way that the coreboot core code is still free >>> software even though you can't automatically port it to any new chipset. >>> You can still add features or make changes to customize behavior for an >>> existing board. You can make it boot your own operating system with custom >>> calling convention, add some code signing or measuring framework, or make >>> it play the Jeopardy melody on the speaker while it's booting. That, too, >>> is a benefit of free software. >>>

1 0

Re: [coreboot] FSP 2.0 headers in coreboot
by Nico Huber 10 May '18

10 May '18

On 11.05.2018 01:31, Julius Werner wrote: >> Ok, I'll try to break this loop here. You are repeating the great bene- >> fits for a user (that I agree to) even if a blob is involved. And I keep >> asking why it should happen on our master branch (I don't see how we >> would take something away by not maintaining everything. Also, I never >> tried to exclude all blobs). It seems somehow we talk past each other. > > Why should it not be on our master branch? What is your exclusion criteria? > To my knowledge the only reason why we ever remove boards from the master > branch is because they become a maintenance burden when it's hard to make > them fit into new/changing APIs and there's no developer volunteering to > keep testing for that board. And in those cases, whether that burden is > related to a blob or not, I totally agree that we can consider removing > them from master. But I don't see how that has anything to do with whether > a blob is mainboard-specific or not. If a board with those blobs is still > easy to pull along with the changes we want to make on master and there's > someone willing to regularly test it and keep it healthy, I see no reason > for exclusion. Well, every added platform and board increases the maintenance burden. And we can't maintain everything. I'm just very biased towards keeping things that are easier to port to new boards, to spread coreboot. And what I called "shit", i.e. not board-agnostic blobs, obviously isn't easy to port to new boards. > > On the other side, the general benefits of keeping stuff in master are > obvious -- users of that board can benefit from the continued development > of coreboot core features. For example, if you have a 3 year old Chromebook > like Veyron_Jerry today then the firmware Google ships you is still frozen > on a three year old branch, but since it's alive and healthy in coreboot > master you can build your own image from there and automatically get cool > new features like the persistent CBMEM console. Ideally, it would be best > if we could keep everything in master forever... we just decide to drop > stuff as a trade-off if it actively prevents us from making forward > progress on other boards, but that decision is not directly related to the > presence or absence of blobs. > What if something "passively" prevents us from making progress? It's hard to measure how much more work patching and reviewing is because of additional platforms. Alas, I can only speak for Intel platforms, because that's what I work most with. Maybe everywhere else blobs look better, then I'd probably need to apologize to the makers of greater blobs. But here is what I experienced in the last year: The time I spent on fixing bugs that crossed FSP platforms was about 500% of the time I usually spent for comparable things. Mostly because something interacted with the undocumented blob in an implicit way (eg. you see things happen in a specific order and don't know why or if it matters). So I couldn't just fix things without a deeper investigation (asking very unresponsive persons, often falling back on Aaron as a last resort). So, yeah, it might just be the code surrounding FSP, but at least there it's an incredibly increased maintenance burden. Oh, forgot to mention, I also hit about three times as many bugs as usual (both inside and outside of the blob). Anyway, lamented enough again. There are better targets to remove to decrease maintenance costs (e.g. whole platforms that are only used by reference boards and are kept for political reasons only). If some board is actively used and that's visible to us, I agree, we shouldn't remove it (although, I still have strong feelings about platforms where users have to carve the binary out somewhere because we can't provide it; nor even a pointer to it). Nico

1 0

Re: [coreboot] FSP 2.0 headers in coreboot
by Nico Huber 10 May '18

10 May '18

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

3 2

Re: [coreboot] FSP 2.0 headers in coreboot
by Nico Huber 10 May '18

10 May '18

On 10.05.2018 00:17, Julius Werner wrote: >> Yes, I agree and already did so when writing the above. That's why I >> made it a recommendation and not a requirement. I also intentionally >> didn't write "vendor". Just whoever provides the blob should sign it. > > I still don't really get what signing in general is solving here. Digital > signatures are only useful if you want the signer to be able to make a new > release without having to update the thing that's checking the signature. No, it's about convenience, trust, security. Even if you only sign once. If you can get the public key for verification out-of-band, an attacker would have to compromise both, the repository and the key distribution. The signee has nothing more to do than sign it, keep the signature along with the binary. That's easier than comparing hashes. > Otherwise you can just store a list of allowed hashes, which is much easier That's another way for an out-of-band trust anchor. IMHO more incon- venient but ok if you keep that list far away from the repository. > (and already implicit in Git if you use the coreboot.org blobs repository). Sounds just more error-prone and inconvenient to me. Sure you can follow hashes in Git, but if you cherry-pick somewhere, you can't. With our process with Gerrit for instance, you'd have to verify that the file that ended up upstream is still the same (doable, sure, but checking another time? I'm getting bored). And where do you store the information that you actually did check? If somebody asks you two years later if you did, what would you say? > In the Intel case maybe signing them makes sense, but it shouldn't be a big > deal to just maintain a list of FSP releases with their hashes in the > coreboot repo either... at least that way you maintain control over which > blobs are valid Who is `you` in "you maintain control"? It's one thing to trust a single person who provided the blob (hopefully the silicon vendor if you need it for a product). But a very different thing to trust everybody who can write to our repository. Or should somebody who checks the hash also check the history of the list? check who changed it? (or who was imper- sonated to change it) Blobs aren't reviewable, are they? > (e.g. you could enforce that they have been tested with > coreboot before inclusion). How? You can make it a rule, yes. But how enforce it? > If you just let Intel sign stuff, you're giving > them complete control over this thing that I think you intend as a > protection for our users. They could sign a special blob for the NSA and > you'd never know until you accidentally catch it running on someone's > system. I don't understand your reasoning here. Ofc, the blob vendor can screw you. But that's the point of blobs, isn't it? > (Or do I misunderstand and you're talking about signatures checked > at runtime? That wouldn't really make sense on a per blob basis when the > rest of coreboot isn't signed, I think. If you want runtime signatures, > it's better to use a system like vboot that covers the whole image, > coreboot and blobs and all.) No, you understood me correctly. I just want a trustworthy distribution of the binaries. To wrap it a little up, I really only had the bigger players in mind when I wrote my draft rules. And I understand your point for a one time blob submission (why set a key pair up for that). You get equivalent security with a hash that is distributed out-of-band. So that option should be added if we ever agree on such rules. Still, if somebody pushes a platform for inclusion on the master branch, and thereby asking to maintain it, I don't see why he shouldn't take the time to sign the blob (ofc, if he runs off later, somebody else (i.e. who already verified the original signature) could take that responsi- bility over). > >>> Of course it would be nice if every chipset was implemented well enough >>> that you can bring up a new mainboard without any help from the vendor, but >>> that's not always that simple, and I don't think it should be a requirement >>> for inclusion. > >> Sorry, I thought that is what free software is about. Must have been >> confused to mix that up with coreboot. IMO, blobs are already a huge >> offense, a disgrace of coreboot and the GPL. But having to sign an NDA >> to be able to use a GPL licensed project in a product? WTF?!? > >> I don't care if people think that their loopholes are safe enough and >> use coreboot that way. But why should the community, including many >> volunteers, maintain that junk on the master branch? > >> If that is the attitude moving forward, maybe we should stop licensing >> new code under the GPL? Just as a courtesy towards free-software develo- >> pers. And to make it clear for new contributors what they sign up for. > > I think you're getting pretty absurd for the sake of argument here. A > different mainboard is a completely different device, of course it may not > run with the firmware meant for another device. Complaining about this as a > GPL violation is like saying that Intel was violating the GPL by adding a > Haswell port to coreboot and then not allowing you to support a Skylake > board with that. No idea what you are trying to tell here? I didn't talk about (strong feelings about) violations. But let me clarify my point of view: Everybody with the time and resources to put things into a blob seems to be excluded from the copyleft nature of the GPL (so we don't get much contribution from the big players). Yet, OTOH, we force the more humble that don't have the big resources to adhere to the copyleft. If we accept that, the GPL has failed us and we shouldn't keep it, IMHO. > It's a completely different thing, of course the code > meant for something else doesn't work on there. Yeah, but once this was a free-software project. Which implies that you can adapt the code to something new. Which you can't with a blob. > > Of course I think we should try to keep blobs mainboard-agnostic, and > whenever I have a chance to influence that I do. But it's not always that > simple. Often you may not realize that it won't work on another board until > you actually build that board and try it out. It's not like anyone is > actively preventing or disallowing you from bringing up another mainboard > with the same blob that's already there, and if your other board uses 100% > the same components as the original then that should always work... but if > you find out you need to use some controller or I/O pad that this blob > didn't initialize because other mainboards didn't need it, then yeah, > sorry, it won't work. It's not like anyone did that intentionally, it's > just bad luck. I think this is conceptually the same as when you have a > completely blob-free platform but you want to use some peripheral that > nobody ever implemented a driver for before. You'll need help from the > vendor then as well. You really seem to miss the point of free software. As long as everybody adheres to the copyleft, you can do things on your own. If a blob ends up being only useful for a single board, ok. Should somebody be able to sell his product with it, sure. But why should the community maintain that shit (partially on the shoulders of volunteers) if it doesn't pro- vide what free software provides? Nico

2 1

← Newer
1
...
5
6
7
8
9
10
11
...
14
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot May 2018