Re: [coreboot] Coreboot Purism BIOS is free? open?
On Sat, Dec 23, 2017 at 11:32 PM, taii...@gmx.com wrote: > On 12/23/2017 07:16 PM, Todd Weaver wrote: > >> Intel did not mislead, we told them, and continue to, that we _want_ an >> ME-less design (which is their term for what we asked for). And as we >> grow our leverage will grow, and our influence will grow. This is a >> long-term strategy and is playing out as planned. >> >> They will not adjust based on small quantities, but quantity = >> leverage, and our influence changes as volumes grow. (e.g. $ = >> influence) > > You will never have that type of leverage, if google can't pull it off then > no one can. Yeah, I agree with you on that, I don't think any leverage could make Intel budge on that at this point. > > Even the NSA only got HAP, not a CPU without ME all together and the US > government probably spends hundreds of millions with intel every year. > > x86-64 will always have ME/PSP and it simply can't be disabled, pretending > otherwise is doing a disservice to many who look to the big shots for advice > and pipe dreams like that being spread to the masses are the main reason I > dislike purism so much. You know of the ROM Bypass stuff, right? The first byte of the flash contains a JMP instruction into the ROMB partition in the flash (that's why the IFD magic number is at offset 0x10, not 0x0), so if you put the right flag in the flash to enable ROM Bypass, then you could get full unsigned/unchecked code (since the code in the ROM is what checks signatures). Now, that actually doesn't work because it's a feature that is disabled on production chips, only pre-production chips allow the ROM Bypass feature. What if someone finds a way to enable that feature on a production chip ? What if you can make your CPU think it's in preproduction mode thanks to some microcode update for example ? Then you can get fully user controlled ME from the very first instruction. I'm not saying it's possible or that it will be possible, but I'm saying that it's not a "pipe dream" like you seem to think. Even better, forget HAP, forget ROM Bypass, how about using the exploit that PT announced at BlackHat to get your own unsigned code to execute on the ME. You get full user control of the ME that way, and while we know that the HAP bit happens at the end of the BUP module's task, it's possible the exploit happens at the start (it does happen when it tries to read a config file, so it could be early in the BUP). The entire code from the first instruction all the way to the time the exploit runs, could be reverse engineered, so even if you don't control what happens there, you could at least have the source for it and audit it to make sure it's not doing anything you wouldn't want it to do, then have your exploit run and execute your own user controlled ME firmware. It's not an as perfect solution as being able to do a ROM Bypass and control everything from the very first JMP, but it's something doable today, it's not even a "maybe", so again, it's not a pipe dream. > > People will think "well gee why buy an actually-libre-right-now TALOS 2 when > I can simply wait a few years when the eggheads have cracked ME and I can > keep getting cheap soul-less computers" as tim said the discovery of HAP etc > probably set back libre computing a decade. > > I hope you are buying a TALOS 2. I think people buying a TALOS 2 and people buying a Librem are two very distinct types of people. I very much doubt that someone has ever had to decide between buying a Librem and a TALOS. No one in need of a computer and in need of a open hardware machine will decide to "wait a few years" either.. when you need a new PC, you buy a new PC. If you want a TALOS, then you buy a TALOS, if you don't want it, or you want a laptop, or if you don't have the budget for it, then you look elsewhere, you're not going to just read some article and decide to wait years without a computer in the hope that what you actually want might be released by then. > > > > A good summary is that we want to "bring > > > > blob-free to the hardware that people want", rather than "bring > > > > blob-free hardware to the people who want it". > This is great; and I may quote you on that :) Yeah, Todd, you can quote me. I also really liked that when I thought of it :p And thanks for answering Nico's questions and correcting my statements. I didn't even know an i.mx8 librem 13/15 had already been thought of, that's pretty cool if it's in the plans! -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot Purism BIOS is free? open?
On 12/23/2017 07:16 PM, Todd Weaver wrote: Intel did not mislead, we told them, and continue to, that we _want_ an ME-less design (which is their term for what we asked for). And as we grow our leverage will grow, and our influence will grow. This is a long-term strategy and is playing out as planned. They will not adjust based on small quantities, but quantity = leverage, and our influence changes as volumes grow. (e.g. $ = influence) You will never have that type of leverage, if google can't pull it off then no one can. Even the NSA only got HAP, not a CPU without ME all together and the US government probably spends hundreds of millions with intel every year. x86-64 will always have ME/PSP and it simply can't be disabled, pretending otherwise is doing a disservice to many who look to the big shots for advice and pipe dreams like that being spread to the masses are the main reason I dislike purism so much. People will think "well gee why buy an actually-libre-right-now TALOS 2 when I can simply wait a few years when the eggheads have cracked ME and I can keep getting cheap soul-less computers" as tim said the discovery of HAP etc probably set back libre computing a decade. I hope you are buying a TALOS 2. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot Purism BIOS is free? open?
On 12/23/2017 04:08 PM, Ivan Ivanov wrote: Sadly the ARM processor also have the ME-like backdoor (called "TrustZone). And even MIPS is going this road soon (check out the "MIPS OmniShield" news). Could it be the requirement of US Government - for all the consumer CPU to have backdoors ? My last hopes are on POWER 9 and RISC V now ; meanwhile sticking to the AMD pre-PSP tech I believe that "the No Such Agency did it" is too easy - I doubt they would be able to keep something that big under wraps for long considering how incompetent they are when it comes to security. My bets are on some type of private actor who wants industrial espionage on steroids - blackmailing or bribing key people who work for intel/amd to make it seem like ME/PSP is a good idea. Imagine all the money you could make with that kind of access! -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD "pre-PSP" devices
On 12/23/2017 04:50 PM, eche...@free.fr wrote: (was [coreboot] Coreboot Purism BIOS is free? open?) Regarding the "AMD pre-PSP" devices, I have a very naive question : are some of them still in production or none of them? (i.e all one can buy nowadays are only "pre-owned" devices with a life expectancy far less than that of a new one..) What about the opteron line? Are they still in production? Sorry for hijacking the thread and thank you for answers.. Florentin Yes of course you can still buy a new KGPE-D16 and KCMA-D8 opteron board, performance with their best CPU's is equivilant to AM3+ FX-8310 (or almost two FX-8310 for the 16 core CPU's) Those two boards are owner controlled (no ME/PSP) and have 100% libre firmware (open source silicon init), they also have an open source firmware for the BMC available for secure libre remote management. You can play modern games in a VM on them via IOMMU-GFX, or use qubes (quite nice for that as they have dual USB controllers) MSRP: KCMA-D8 - $315 KGPE-D16: $415 I wouldn't bother buying a new Opteron CPU however as a CPU has an estimated lifespan of 20+ years, but the board should definitely be brand new. There is also the Lenovo G505S, an owner controlled pre-PSP AMD laptop that can run coreboot with open source silicon init. (unlike the purism laptops which use the intel FSP binary blob) which you can find as a refurb. Although I suggest also looking in to a TALOS 2 running POWER9, which is significantly faster and much more secure. https://raptorcs.com -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot Purism BIOS is free? open?
> Intel did not mislead, we told them, and continue to, that we _want_ an > ME-less design (which is their term for what we asked for). This is Mission Impossible. The reasons are Technical (bringing up the platform) and Political => Sales and Marketing domination/implications. > And as we grow our leverage will grow, and our influence will grow. This > is a long-term strategy and is playing out as planned. Actually, it is vice versa. ME gets more and more complicated, as time progresses. Understandable why. If INTEL solves Cannon Lake woes with 10nm technology (INTEL struggles for 20 months with yields), ME will be even more complex to support EUV lithography and its outcomes. > Not binary-blob free. It was always known this will be a large > investment of both time and money. But coreboot ported to hardware > within a few months is an accurate assessment of what I heard, and that > turned out to be much longer, not in technical nature, but finding the > right people/developers to do it properly. Now all our (x86) products > are running coreboot, and will continue to. As well as FSP. It gets more complicated, although it gets more structured. There are three parts of the FSP blob now: FSP-S, FSP-M and FSP-P. Silicon init, MRC and early platform init. And this to disassemble is quite possible, but then the disassembled code will be all magic addresses and magic data (except MRC, at least for LPDDR3). Something like: uint32 read (uint32 * addr), void write (uint32 * addr, uint32 data), where on some magic addr 0xFF87429C magic data are stored: 0x0030CF46, and nobody really knows what address points to (the feature), and what the data mean (since there are fields, usually from 5 fields +)?! And there are gazillion of such registers there, undocumented, which are outlined in C-Specs, NOT all of them??? The only proper way how to solve this problem is to force INTEL to publicly release C-Specs for each and every CORE and ATOM families, which is equivalent to force NSA to release their deepest secrets to the public. Good Luck with all of these efforts! Zoran Stojsavljevic On Sun, Dec 24, 2017 at 1:16 AM, Todd Weaver wrote: > On Fri, 2017-12-22 at 22:06 -0500, Youness Alaoui wrote: >> On Tue, Dec 19, 2017 at 3:54 PM, Timothy Pearson >> wrote: >> > >> > Thank you for the detailed explanation. I guess this is an area in >> > which experience matters; it is absolutely unacceptable (and not >> > unexpected) that Intel misled your CEO, but this is sadly not an >> > uncommon tactic in the industry. > > Intel has not misled anything. We knew the ME/FSP/vBIOS were the issues > (from my first questions to this coreboot mailing list and the replies > from the community), but there was no perfect alternative, so we chose > Intel to get hardware (more) people wanted and work and invest toward > liberating it. > > I can say, without much doubt, that if we chose any other platform we > would have struggled in volume and not advanced any faster or farther > than we have already. > > To liberate hardware, there are three larger paths: > 1) use existing liberated hardware (gets older and older) > 2) design using freed chips (low performance) > 3) use products people want that are not yet fully liberated, invest in > liberating. > > For laptops: > #1 is already being done by many > #2 is also being done > #3 is the path we are doing for laptops. > > For a phone: > #1 doesn't exist > #2 is the path we are doing > #3 others are trying > > We can then cross-polinate our investment efforts into the phone > motherboard into a laptop with #2. > > I have a published business vision page here: > https://puri.sm/about/business-model-and-vision/ > > >> > One item I would like to call out though is the following: >> > >> > > if old or non-x86 architectures were so appealing, you would have >> > > seen that become the norm rather than the exception) > > This statement is accurate. The volume of sales would be significantly > less if we tried non-x86. And then our growth would be smaller; and our > investment toward freeing future hardware would not happen; and then > there would be no advancement toward convenient ethical products, which > is our goal. > >> > Trying to switch architectures may be hard, but it is only >> > going to get harder day after day as people continue to cling to >> > false hope that the x86 platform may ever be brought under their >> > control. > > It's pretty simple. With leverage we can change businesses. This is not > a short-term game, but a long-term... grow-gain leverage-influence > change-repeat. And this is what we are doing at Purism, and will > continue. We are not griping about the state of affairs, we have a plan > to change the future, and are executing on it. > > >> > I wonder, though, if given this information if possibly Raptor and >> > Purism might have some common business ground here? Purism has >> > experience with laptop mechanicals and related concerns, and we >> > have experience wi
Re: [coreboot] Coreboot Purism BIOS is free? open?
On Fri, 2017-12-22 at 22:06 -0500, Youness Alaoui wrote: > On Tue, Dec 19, 2017 at 3:54 PM, Timothy Pearson > wrote: > > > > Thank you for the detailed explanation. I guess this is an area in > > which experience matters; it is absolutely unacceptable (and not > > unexpected) that Intel misled your CEO, but this is sadly not an > > uncommon tactic in the industry. Intel has not misled anything. We knew the ME/FSP/vBIOS were the issues (from my first questions to this coreboot mailing list and the replies from the community), but there was no perfect alternative, so we chose Intel to get hardware (more) people wanted and work and invest toward liberating it. I can say, without much doubt, that if we chose any other platform we would have struggled in volume and not advanced any faster or farther than we have already. To liberate hardware, there are three larger paths: 1) use existing liberated hardware (gets older and older) 2) design using freed chips (low performance) 3) use products people want that are not yet fully liberated, invest in liberating. For laptops: #1 is already being done by many #2 is also being done #3 is the path we are doing for laptops. For a phone: #1 doesn't exist #2 is the path we are doing #3 others are trying We can then cross-polinate our investment efforts into the phone motherboard into a laptop with #2. I have a published business vision page here: https://puri.sm/about/business-model-and-vision/ > > One item I would like to call out though is the following: > > > > > if old or non-x86 architectures were so appealing, you would have > > > seen that become the norm rather than the exception) This statement is accurate. The volume of sales would be significantly less if we tried non-x86. And then our growth would be smaller; and our investment toward freeing future hardware would not happen; and then there would be no advancement toward convenient ethical products, which is our goal. > > Trying to switch architectures may be hard, but it is only > > going to get harder day after day as people continue to cling to > > false hope that the x86 platform may ever be brought under their > > control. It's pretty simple. With leverage we can change businesses. This is not a short-term game, but a long-term... grow-gain leverage-influence change-repeat. And this is what we are doing at Purism, and will continue. We are not griping about the state of affairs, we have a plan to change the future, and are executing on it. > > I wonder, though, if given this information if possibly Raptor and > > Purism might have some common business ground here? Purism has > > experience with laptop mechanicals and related concerns, and we > > have experience with truly blob-free, powerful hardware -- > > combining those two could yield an interesting machine... Ping me off list to discuss. We are always looking for aligned- partnerships or collaboration. > > > The main question I have, and this is an honest question, is why > > > Purism chose to use the x86 platform as a base for libre > > > hardware, when it has been known for some time that said hardware > > > could never be made fully blob-free? See above, I think I laid out and answered this clearly. It's not just technical, there is a strong business model behind our approach. > > > There were (and are) other good ways to make a system that could > > > be fully blob-free, for instance ARM, and given the engineering > > > effort that is said to have been put into the Purism machines I > > > wonder what we could have had if said effort had been put into an > > > aarch64 system instead of an x86 system? Sure, that would sell a small fraction of the quantity, and fail to impact the future of computing in a way we model out. > > > > The second reason is that Todd (CEO) was in talks with Intel > > > > and was unfortunately lead to believe that they were open to > > > > release an ME-less design CPU for his needs, it ended up not > > > > being the case. Intel did not mislead, we told them, and continue to, that we _want_ an ME-less design (which is their term for what we asked for). And as we grow our leverage will grow, and our influence will grow. This is a long-term strategy and is playing out as planned. They will not adjust based on small quantities, but quantity = leverage, and our influence changes as volumes grow. (e.g. $ = influence) > > > > Todd thought that it would be possible to get a binary blob > > > > free coreboot/CPU with a few months of work. Not binary-blob free. It was always known this will be a large investment of both time and money. But coreboot ported to hardware within a few months is an accurate assessment of what I heard, and that turned out to be much longer, not in technical nature, but finding the right people/developers to do it properly. Now all our (x86) products are running coreboot, and will continue to. > > > > A good summary is that we want to "bring > > > > blob-free to the hardware tha
Re: [coreboot] Coreboot Purism BIOS is free? open?
On Sat, 2017-12-23 at 11:39 +0100, Nico Huber wrote: > If you get the i.MX8 for it (and it turns out to be as good > documented), all you have to do is to ask for a board with the most > powerful version that physically fits a Librem 13 [1]. Then you can > offer trustworthy hardware vs. performance and let your customers > chose. "all you have to do" is simplifying the "all we have to do" a little. But let me confirm our top-level plans as it relates... The Librem 5 is the catalyst for us to produce a motherboard that fits into the Librem 13/15 ... etc. So that part is spot-on. We will then offer: Librem 13 i7 Librem 13 i.mx8 Librem 15 i7 Librem 15 i.mx8 etc. This will probably be able to happen in 2019. The "all we have to do" is (not even limited to) design, prototype, test, modify, tool, fund, fabricate, productize, develop, inventory, quality control, ship, publish, and support. > There are ofc alternatives to i.MX. Most use a graphics core where > free drivers are a problem. Though, a proprietary driver in the OS is > far less troublesome than blobs in your firmware (or the ME). I am not convinced this is the consensus. For one critical test that this would fail: PureOS being listed as an FSF endorsed distribution = no proprietary drivers in the OS (plus a lot of other things, but that is the only relevant part to the comparison). So our approach I believe is still the best approach. Start with hardware people want, work to free it (NOTE: This is how GNU started in OS freedom, and I believe that was the best approach there as well). Since we have to invest in i.mx8 for the phone, then we can cross- polinate that investment into a lesser expensive, lesser performance, RYF compatible laptop board that fits into our existing cases. > Once you buy a reasonable quantity of an SoC, you can ask if they can > make the next generation with RISC-V instead of ARM. Unlikely to get > that soon, but way more likely than Intel changing their silicon for > you. Moving to RISC-V is on the "we will evaluate and would love to do it." roadmap, and we will continue to follow the progress there to produce a device that is RISC-V when it crosses the threshold of "stable available product". Part of that determination is based on the talented coreboot community, talking to Ron about this at the last coreboot conference helped guage the tests for "when" this will be able to be put into a product. > > Nico > > [1] I'm convinced that this is easily doable. "easily doable" see above. Todd. signature.asc Description: This is a digitally signed message part -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot Purism BIOS is free? open?
Ivan Ivanov wrote: > Could it be the requirement of US Government - for all the consumer > CPU to have backdoors ? I guess that the private sector is a much stronger force... Nico Huber wrote: > watch Netflix in high resolution //Peter -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] AMD "pre-PSP" devices
(was [coreboot] Coreboot Purism BIOS is free? open?) Regarding the "AMD pre-PSP" devices, I have a very naive question : are some of them still in production or none of them? (i.e all one can buy nowadays are only "pre-owned" devices with a life expectancy far less than that of a new one..) What about the opteron line? Are they still in production? Sorry for hijacking the thread and thank you for answers.. Florentin - Mail d'origine - De: Nico Huber À: Ivan Ivanov , Alberto Bursi , coreboot@coreboot.org Envoyé: Sat, 23 Dec 2017 22:19:14 +0100 (CET) Objet: Re: [coreboot] Coreboot Purism BIOS is free? open? On 23.12.2017 22:08, Ivan Ivanov wrote: > Sadly the ARM processor also have the ME-like backdoor (called "TrustZone). Some have. Some not. Some have it and it's owner-controllable. It's not about the ISA and some optional architectural feature, it's about the chip you buy. > And even MIPS is going this road soon (check out the "MIPS OmniShield" news). > > Could it be the requirement of US Government - for all the consumer > CPU to have backdoors ? > My last hopes are on POWER 9 and RISC V now ; meanwhile sticking to > the AMD pre-PSP tech Forget it. RISC-V already has SMM like tech in the architecture. But that doesn't matter as long as you can buy chip's that are owner con- trollable. Such features make it harder to keep everything secure but they don't force the silicon vendor to lock you out (as long as you don't ask to be able to watch Netflix in high resolution or something like that). Nico -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot Purism BIOS is free? open?
On 23.12.2017 22:08, Ivan Ivanov wrote: > Sadly the ARM processor also have the ME-like backdoor (called "TrustZone). Some have. Some not. Some have it and it's owner-controllable. It's not about the ISA and some optional architectural feature, it's about the chip you buy. > And even MIPS is going this road soon (check out the "MIPS OmniShield" news). > > Could it be the requirement of US Government - for all the consumer > CPU to have backdoors ? > My last hopes are on POWER 9 and RISC V now ; meanwhile sticking to > the AMD pre-PSP tech Forget it. RISC-V already has SMM like tech in the architecture. But that doesn't matter as long as you can buy chip's that are owner con- trollable. Such features make it harder to keep everything secure but they don't force the silicon vendor to lock you out (as long as you don't ask to be able to watch Netflix in high resolution or something like that). Nico -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot Purism BIOS is free? open?
Sadly the ARM processor also have the ME-like backdoor (called "TrustZone). And even MIPS is going this road soon (check out the "MIPS OmniShield" news). Could it be the requirement of US Government - for all the consumer CPU to have backdoors ? My last hopes are on POWER 9 and RISC V now ; meanwhile sticking to the AMD pre-PSP tech Best regards, Ivan Ivanov 2017-12-23 15:08 GMT+03:00 Alberto Bursi : > > > On 12/23/2017 11:54 AM, Nico Huber wrote: >> On 23.12.2017 11:39, Nico Huber wrote: >>> [1] I'm convinced that this is easily doable. At least compared to the >>> effort you already put in liberating the unliberatable. If the i.MX8 >>> turns out to be as controllable and well documented as the i.MX6, >>> you'd be catapulted towards the end of your freedom roadmap. >>> >> Now that I've looked at your roadmap again, there's a flaw at the >> beginning: AUIU, at least Acer, Dell, HP and Lenovo sell products >> that are on par with yours (Chromebooks). Actually you're basing >> your firmware on their investments into it. So it seems unfair to >> list them there. Some even sell ARM devices that are far ahead (in >> terms of freedom and owner-controllability; not in your roadmap >> because that has a very weird order). >> >> Nico >> > > Meh, chromebooks aren't exactly powerful systems anyway. Also I don't > know other ARM devices that are more free than ARM chromebooks (again > not really powerful systems). > > -Alberto > -- > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] ThinkPad X201 compile error
On 23.12.2017 17:12, Federico Amedeo Izzo wrote: This attempt was not a success, because even with the last working commit, when selecting "Normal" mode via nvramcui, it always reboots in Fallback mode. You also need to clear the `reboot_counter` variable. Otherwise the logic assumes "Normal" was already tried x times. Nico -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] ThinkPad X201 compile error
On 12/18/2017 12:14 PM, Nico Huber wrote: > On 18.12.2017 11:44, Federico Amedeo Izzo wrote: >> Hello, >> >> I wanted to update coreboot on my X201 from the Feb 2017 source >> (commit 068edc1c52cb1e5b6376ba7f296ef8797a24cd5f) >> to current master >> (commit f2e7b37c52cac5e7825d0e01b3c45c1506e99253) >> But when compiling it gives the following error >> ``` >> src/northbridge/intel/nehalem/gma.c: In function 'gma_func0_init': >> src/northbridge/intel/nehalem/gma.c:1066:5: error: implicit declaration >> of function 'intel_gma_init' [-Werror=implicit-function-declaration] >> intel_gma_init(conf, res2mmio(gtt_res, 0, 0),``` > Wooops, my fault! Fix here: > https://review.coreboot.org/#/c/coreboot/+/22930 > > You just need to remove the #if and #endif in lines 575 and 1012, > respectively. Thanks, the fix works, and now the master compiles again. >> Now it's configured to load a VGA blob, if I enable "native graphics >> init" instead, the compile error goes away, but the resulting image does >> not boot (beep and flashing leds) > I fear this error is not gfx related. The Nehalem code isn't widely tes- > ted, I suggest trying again with different DIMMS / DIMM combinations. > > Hope that helps, > Nico The current coreboot master does not boot even with VGA blob, and it looks like a memory problem as you were suggesting. In fact watching the serial console it appears that the DIMM training phase does not finish, and after a while the computer turns itself off. I've also tried different DIMMS and combinations but without success. I'm just finished doing a `git bisect` keeping the working commit as Fallback and the one to test as a Normal. This attempt was not a success, because even with the last working commit, when selecting "Normal" mode via nvramcui, it always reboots in Fallback mode. Do you have any other suggestions? Thanks, Federico -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] cbfstool without cloning the whole repository? Use script for <2M download
It looks like there were two typos in this wonderful script : missing " \ " at the end of two " --execute robots=off " lines Other than that, this script is still working. Below is a fixed copy, if you sometimes need cbfstool without cloning the whole coreboot you may try it out: ### SCRIPT BEGIN ### wget --recursive --no-parent --no-host-directories --cut-dirs=3 \ --user-agent="Mozilla/5.0" --execute robots=off \ https://review.coreboot.org/cgit/coreboot.git/plain/util/cbfstool/ wget --recursive --no-parent --no-host-directories --cut-dirs=3 \ --user-agent="Mozilla/5.0" --execute robots=off \ https://review.coreboot.org/cgit/coreboot.git/plain/src/commonlib/ \ --exclude-directories=/cgit/coreboot.git/plain/src/commonlib/storage/ \ --reject=configstring.c,iobuf.c,cbmem_id.h,configstring.h,coreboot_tables.h,\ fmap_serialized.h,iobuf.h,sd_mmc_ctrlr.h,sdhci.h,stdlib.h,storage.h,\ timestamp_serialized.h wget --recursive --no-parent --no-host-directories --cut-dirs=3 \ --user-agent="Mozilla/5.0" --execute robots=off \ https://review.coreboot.org/cgit/coreboot.git/plain/src/vendorcode/intel/edk2/uefi_2.4/ wget --recursive --no-parent --no-host-directories --cut-dirs=3 \ --user-agent="Mozilla/5.0" --execute robots=off \ https://review.coreboot.org/cgit/coreboot.git/plain/src/vendorcode/intel/fsp/fsp1_1/IntelFspPkg/Include/FspInfoHeader.h wget --recursive --no-parent --no-host-directories --cut-dirs=3 \ --user-agent="Mozilla/5.0" --execute robots=off \ --directory-prefix=./3rdparty/vboot/ \ https://review.coreboot.org/cgit/vboot.git/plain/firmware/2lib/ \ --reject=2api.c,2crc8.c,2hmac.c,2misc.c,2nvstorage.c,2rsa.c,2secdata.c,\ 2secdatak.c,2stub.c,2tpm_bootmode.c,2crc8.h,2hmac.h,2misc.h,\ 2nvstorage_fields.h,2nvstorage.h,2rsa.h,2secdata.h,2tpm_bootmode.h wget --recursive --no-parent --no-host-directories --cut-dirs=3 \ --user-agent="Mozilla/5.0" --execute robots=off \ --directory-prefix=./3rdparty/vboot/ \ https://review.coreboot.org/cgit/vboot.git/plain/firmware/include/vb2_api.h cd ./util/cbfstool/ make all ### SCRIPT END ### 2017-07-12 1:53 GMT+03:00 Ivan Ivanov : > Dear friends, sometimes you need to do a few operations with > coreboot.rom (e.g. update its' payload) without changing > coreboot.rom's main code. If you have bad Internet connection or just > want to quickly get the latest version of cbfstool without cloning the > whole coreboot/vboot repositories - my bash script below will really > help you! > > It downloads only the files required for the successful compilation of > cbfstool - whole ./util/cbfstool directory (93 files, ~1,3M size) and > all the dependencies: > ./src/commonlib - 20 files, ~152K > ./src/vendorcode/intel/edk2/uefi_2.4/ - 26 files, 272K > ./src/vendorcode/intel/fsp/fsp1_1/IntelFspPkg/Include/FspInfoHeader.h - ~4K > > ((( I don't understand what Intel is doing here, but I can't build > without these files! ))) > > ./3rdparty/vboot/firmware/2lib/ - 17 files, 170K > ./3rdparty/vboot/firmware/include/vb2_api.h - ~1K > > In total, its 158 files and just 1.9M - less than 2M ! > And it builds OK. Hope it will be useful for you ;-) > > ### SCRIPT BEGIN ### > > wget --recursive --no-parent --no-host-directories --cut-dirs=3 \ > --user-agent="Mozilla/5.0" --execute robots=off \ > https://review.coreboot.org/cgit/coreboot.git/plain/util/cbfstool/ > > wget --recursive --no-parent --no-host-directories --cut-dirs=3 \ > --user-agent="Mozilla/5.0" --execute robots=off \ > https://review.coreboot.org/cgit/coreboot.git/plain/src/commonlib/ \ > --exclude-directories=/cgit/coreboot.git/plain/src/commonlib/storage/ \ > --reject=configstring.c,iobuf.c,cbmem_id.h,configstring.h,coreboot_tables.h,\ > fmap_serialized.h,iobuf.h,sd_mmc_ctrlr.h,sdhci.h,stdlib.h,storage.h,\ > timestamp_serialized.h > > wget --recursive --no-parent --no-host-directories --cut-dirs=3 \ > --user-agent="Mozilla/5.0" --execute robots=off \ > https://review.coreboot.org/cgit/coreboot.git/plain/src/vendorcode/intel/edk2/uefi_2.4/ > > wget --recursive --no-parent --no-host-directories --cut-dirs=3 \ > --user-agent="Mozilla/5.0" --execute robots=off \ > https://review.coreboot.org/cgit/coreboot.git/plain/src/vendorcode/intel/fsp/fsp1_1/IntelFspPkg/Include/FspInfoHeader.h > > wget --recursive --no-parent --no-host-directories --cut-dirs=3 \ > --user-agent="Mozilla/5.0" --execute robots=off > --directory-prefix=./3rdparty/vboot/ \ > https://review.coreboot.org/cgit/vboot.git/plain/firmware/2lib/ \ > --reject=2api.c,2crc8.c,2hmac.c,2misc.c,2nvstorage.c,2rsa.c,2secdata.c,\ > 2secdatak.c,2stub.c,2tpm_bootmode.c,2crc8.h,2hmac.h,2misc.h,\ > 2nvstorage_fields.h,2nvstorage.h,2rsa.h,2secdata.h,2tpm_bootmode.h > > wget --recursive --no-parent --no-host-directories --cut-dirs=3 \ > --user-agent="Mozilla/5.0" --execute robots=off > --directory-prefix=./3rdparty/vboot/ \ > https://review.coreboot.org/cgit/vboot.git/plain/firmware/include/vb2_api.h > > cd ./util/cbfstool/ > > make all > > ### SCRIPT END ### -- coreboot mailing list: co
Re: [coreboot] Coreboot Purism BIOS is free? open?
On 12/23/2017 11:54 AM, Nico Huber wrote: > On 23.12.2017 11:39, Nico Huber wrote: >> [1] I'm convinced that this is easily doable. At least compared to the >> effort you already put in liberating the unliberatable. If the i.MX8 >> turns out to be as controllable and well documented as the i.MX6, >> you'd be catapulted towards the end of your freedom roadmap. >> > Now that I've looked at your roadmap again, there's a flaw at the > beginning: AUIU, at least Acer, Dell, HP and Lenovo sell products > that are on par with yours (Chromebooks). Actually you're basing > your firmware on their investments into it. So it seems unfair to > list them there. Some even sell ARM devices that are far ahead (in > terms of freedom and owner-controllability; not in your roadmap > because that has a very weird order). > > Nico > Meh, chromebooks aren't exactly powerful systems anyway. Also I don't know other ARM devices that are more free than ARM chromebooks (again not really powerful systems). -Alberto -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot Purism BIOS is free? open?
On 23.12.2017 11:39, Nico Huber wrote: > [1] I'm convinced that this is easily doable. At least compared to the > effort you already put in liberating the unliberatable. If the i.MX8 > turns out to be as controllable and well documented as the i.MX6, > you'd be catapulted towards the end of your freedom roadmap. > Now that I've looked at your roadmap again, there's a flaw at the beginning: AUIU, at least Acer, Dell, HP and Lenovo sell products that are on par with yours (Chromebooks). Actually you're basing your firmware on their investments into it. So it seems unfair to list them there. Some even sell ARM devices that are far ahead (in terms of freedom and owner-controllability; not in your roadmap because that has a very weird order). Nico -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot Purism BIOS is free? open?
Hey Youness, hey Todd, On 23.12.2017 04:06, Youness Alaoui wrote: > I think there is a plan to move librems to non-x86 architecture > eventually (considering that RYF is our long term plan, there is no > choice in moving out of x86 eventually), that would be great. > I think the efforts on the > risc-v front are the most promising and I think that's where the true > competition to x86 will be, but to be honest, I don't really follow, > understand or know much of anything that happens in the hardware space > since I'm a software guy at heart (i.e: all I know is that x86, ARM, > PPC and Risc-V use different instruction sets). RISC-V is just a different ISA. Ok, it's free, but as it's BSD licen- sed, silicon vendors can build around it whatever they want. Delivering an owner-controllable platform is not in the scope of an ISA anyway. So RISC-V can't magically change the game by definition. > I hear a lot about PPC > (with Talos for example), but I don't think PPC is as open as Risc-v > (ISA or something). All I know about PPC really is that it was fun to > reverse engineer during my PS3 days :) > Anyways, as far as I know, for risc-v, it's not there yet, so we're > waiting for that to be ready for the masses before moving to it. I > have absolutely no idea if it's "close" or if it's really a long term > plan for risc-v to be able to compete with x86 in terms of > performance/power usage/features/etc... It doesn't matter how close somebody else is. If I understand Purism correctly, the idea is not to jump into a market of owner-controllable devices once it exists, but to pioneer that market. The only thing that matters is what you buy *today*. The choice of i.MX for the Librem 5 is a move into the right direction. i.MX6 was the best thing you can get for mobile devices, IMHO (controllable and publicly documented). If you get the i.MX8 for it (and it turns out to be as good documented), all you have to do is to ask for a board with the most powerful version that physically fits a Librem 13 [1]. Then you can offer trustworthy hardware vs. performance and let your customers chose. There are ofc alternatives to i.MX. Most use a graphics core where free drivers are a problem. Though, a proprietary driver in the OS is far less troublesome than blobs in your firmware (or the ME). And you might find something that is already available and delivers higher performance than the announced i.MX8 versions. Once you buy a reasonable quantity of an SoC, you can ask if they can make the next generation with RISC-V instead of ARM. Unlikely to get that soon, but way more likely than Intel changing their silicon for you. Nico [1] I'm convinced that this is easily doable. At least compared to the effort you already put in liberating the unliberatable. If the i.MX8 turns out to be as controllable and well documented as the i.MX6, you'd be catapulted towards the end of your freedom roadmap. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] T430 fan control
Hello David, >> however it seems the fan control does not >> work for me. The fan spins but at a low >> speed, and does not increase even if I run a >> stresstest like 'stress --cpu 4'. Maybe you try to install tlp in dom0: http://linrunner.de/en/tlp/docs/tlp-linux-advanced-power-management.html I am installing powertop and tlp on all my Linux Laptops. In dom0: sudo qubes-dom0-update tlp powertop [799]-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
