Re: [coreboot] Further coreboot releases, setting new standards
FYI https://review.coreboot.org/c/coreboot/+/29820/3/MAINTAINERS#219 We will take care of the SoC support. I think Werner will jump in as well. On 28.11.18 22:04, Nico Huber wrote: > On 28.11.18 02:59, Jay Talbott wrote: >> Although I have participated in a number of reviews of coreboot patches, >> I/we have not directly upstreamed any patches to coreboot.org. As a pure >> consulting service, the ports and customizations that we have made to >> coreboot to support our clients' hardware (including the work done for >> Intel) is turned over to the client at the end of each project to do >> with as they please. If they choose to upstream it or not to >> coreboot.org is really up to them, and if they do, it would get >> upstreamed by them, not by us, since they then own the code. > You could change the terms, I guess. Many people don't care that much. > So you could ask your clients ahead if they'd agree to license the code > under the GPL (or maybe only the parts that are not in their mainboard/ > dir). If somebody agrees and it turns out later that there is a commit > that could benefit upstream, you can push it. > > Nico > -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboots Board Status have privacy issues for contributors
Sounds like something that should be pretty simple to automate in the uploader script? While it's probably good to also have a warning and clarify that the final obligation lies with the uploader, there's no reason we can't help them by adding sanitization for common issues as we find them. We're doing something similar when we collect Chrome OS crash reports (these don't get made public so the impact isn't as high, but the basic idea is the same), so we could just steal or at least take inspiration from that code: https://chromium.googlesource.com/chromiumos/platform2/+/master/crash-reporter/crash_collector.cc#262 (Note in particular the extra care taken to distinguish MAC addresses from ATA ACPI commands, that's probably useful for our case as well? Although maybe not anymore these days...) On Sun, Nov 25, 2018 at 10:42 PM David Hendricks wrote: > > > > On Sun, Nov 25, 2018 at 9:25 AM wrote: >> >> I was thinking of contributing to the Board Status but i dont want to >> release any private data and wont contribute now. What is the usage of >> the world to know what mac address the people are using? > > > Thanks for pointing out these issues. > > For what it's worth, the user must use the '-u' option to upload results. And > as Arthur points out you can edit logs and such yourself to scrub any private > data. The script just automates a few steps for convenience, though obviously > we'd like a reasonably uniform data set to compare with. You're right that we > don't need to know anyone's MAC address for coreboot development; however as > others have pointed out a full kernel log is useful since firmware issues > often manifest themselves there (memory map incorrect, devices not enabled, > etc) so it's good to have them for comparison. > > Still, a pause as Mike suggested and perhaps a scary warning or two could be > useful. > >> Then there can be for example a simple live linux iso that people can boot >> with LAN cable connected. No requirement of installation software, of >> setting things up or anything like that. > > > There is one - See util/board_status/set_up_live_image.sh . > > -- > 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] Further coreboot releases, setting new standards
On 28.11.18 02:59, Jay Talbott wrote: > Although I have participated in a number of reviews of coreboot patches, > I/we have not directly upstreamed any patches to coreboot.org. As a pure > consulting service, the ports and customizations that we have made to > coreboot to support our clients' hardware (including the work done for > Intel) is turned over to the client at the end of each project to do > with as they please. If they choose to upstream it or not to > coreboot.org is really up to them, and if they do, it would get > upstreamed by them, not by us, since they then own the code. You could change the terms, I guess. Many people don't care that much. So you could ask your clients ahead if they'd agree to license the code under the GPL (or maybe only the parts that are not in their mainboard/ dir). If somebody agrees and it turns out later that there is a commit that could benefit upstream, you can push it. Nico -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Further coreboot releases, setting new standards
On 28.11.18 16:10, Jay Talbott wrote: >> "Jay Talbott" writes: >>> I know I don't post much here, but I feel like I need to chime in on this >>> thread... Perhaps it's time that SysPro becomes a louder voice in the >>> community. >>> >>> Bay Trail and Broadwell DE are both still very popular platforms, yet >>> neither one of them meets the cut for any of the three criteria. So I >>> caution against removing the support for either of them too hastily. >>> >> >> I looked into that FSP 1.0 integration code a little. It would seem to >> me that relocatable ramstage and C_ENVIRONMENT_BOOTBLOCK are >> possible. >> NO_CAR_GLOBAL_MIGRATION however seems rather impossible as the FSP >> has >> total control over the environment and destroys the CAR environment >> itself. Since I propose the standards I could offer some help to reach >> them. >> >> It looks like FSP 1.0 will be dragging coreboot down for some time. >> Maybe we can agree not to integrate such monsters into coreboot in the >> future? > > As far as I'm aware, Intel won't be developing anymore FSP 1.0 FSPs. It was > all part of a learning curve on everybody's part during the early days of > the FSP. At the same time, even for popular platforms, they won't be going > back and respinning old FSP 1.0 FSPs as FSP 2.0 FSPs. So as long as these > platforms are still popular, we will need to continue to support these > platforms for a while even though they don't nicely fit into the utopian > future of coreboot. Well, support what you want to support. It doesn't have to happen upstream. I really don't understand what all the fuss is about. Apart from build tests, these platforms are effectively unmaintained. They gain nothing on the master branch unless somebody is forced to update them in any way (and when that happens, it's unlikely to get tested before the commits land). The code looks ugly, it was never really reviewed. Apart from being a disgrace for the project, I don't see what difference it makes. Nico -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Further coreboot releases, setting new standards
On 28.11.18 14:25, Arthur Heymans wrote: > "Jay Talbott" writes: >> I know I don't post much here, but I feel like I need to chime in on this >> thread... Perhaps it's time that SysPro becomes a louder voice in the >> community. >> >> Bay Trail and Broadwell DE are both still very popular platforms, yet >> neither one of them meets the cut for any of the three criteria. So I >> caution against removing the support for either of them too hastily. >> > > I looked into that FSP 1.0 integration code a little. It would seem to > me that relocatable ramstage and C_ENVIRONMENT_BOOTBLOCK are possible. > NO_CAR_GLOBAL_MIGRATION however seems rather impossible as the FSP has > total control over the environment and destroys the CAR environment > itself. Since I propose the standards I could offer some help to reach > them. > > It looks like FSP 1.0 will be dragging coreboot down for some time. One way to mitigate would be to port the x86emu to CAR stages. Then just do what we always did with incompatible binaries, cage them. Would be a nice exercise for those that think FSP 1.0 needs to be maintained up- stream. > Maybe we can agree not to integrate such monsters into coreboot in the > future? BTW baytrail has a non FSP port that will likely be in better > shape. Yes please. Nico -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Further coreboot releases, setting new standards
> -Original Message- > From: Arthur Heymans [mailto:art...@aheymans.xyz] > Sent: Wednesday, November 28, 2018 6:26 AM > To: Jay Talbott > Cc: Patrick Georgi via coreboot; Patrick Georgi > Subject: Re: [coreboot] Further coreboot releases, setting new standards > > "Jay Talbott" writes: > > > I know I don't post much here, but I feel like I need to chime in on this > thread... Perhaps it's time that SysPro becomes a louder voice in the > community. > > > > Bay Trail and Broadwell DE are both still very popular platforms, yet neither > one of them meets the cut for any of the three criteria. So I caution against > removing the support for either of them too hastily. > > > > I looked into that FSP 1.0 integration code a little. It would seem to > me that relocatable ramstage and C_ENVIRONMENT_BOOTBLOCK are > possible. > NO_CAR_GLOBAL_MIGRATION however seems rather impossible as the FSP > has > total control over the environment and destroys the CAR environment > itself. Since I propose the standards I could offer some help to reach > them. > > It looks like FSP 1.0 will be dragging coreboot down for some time. > Maybe we can agree not to integrate such monsters into coreboot in the > future? As far as I'm aware, Intel won't be developing anymore FSP 1.0 FSPs. It was all part of a learning curve on everybody's part during the early days of the FSP. At the same time, even for popular platforms, they won't be going back and respinning old FSP 1.0 FSPs as FSP 2.0 FSPs. So as long as these platforms are still popular, we will need to continue to support these platforms for a while even though they don't nicely fit into the utopian future of coreboot. > BTW baytrail has a non FSP port that will likely be in better shape. > > Kind regards > > Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Further coreboot releases, setting new standards
"Jay Talbott" writes: > I know I don't post much here, but I feel like I need to chime in on this > thread... Perhaps it's time that SysPro becomes a louder voice in the > community. > > Bay Trail and Broadwell DE are both still very popular platforms, yet neither > one of them meets the cut for any of the three criteria. So I caution against > removing the support for either of them too hastily. > I looked into that FSP 1.0 integration code a little. It would seem to me that relocatable ramstage and C_ENVIRONMENT_BOOTBLOCK are possible. NO_CAR_GLOBAL_MIGRATION however seems rather impossible as the FSP has total control over the environment and destroys the CAR environment itself. Since I propose the standards I could offer some help to reach them. It looks like FSP 1.0 will be dragging coreboot down for some time. Maybe we can agree not to integrate such monsters into coreboot in the future? BTW baytrail has a non FSP port that will likely be in better shape. Kind regards Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Further coreboot releases, setting new standards
Hello Mike, Am 28.11.18 um 13:27 schrieb Mike Banon: >> As a pure consulting service, the ports and customizations that we have >> made to coreboot to support our clients' hardware (including the work >> done for Intel) is turned over to the client at the end of each project >> to do with as they please. If they choose to upstream it or not to >> coreboot.org is really up to them, and if they do, it would get >> upstreamed by them, not by us, since they then own the code. <--- ??? > > Almost all the coreboot source code is GPLv2 licensed, not some > commercial closed-source proprietary license, and you will not be > breaking this GPLv2 license by contributing your patches even though > they have been created by the request of your clients. They wouldn't break "this GPLv2 license" (what ever that means) *but* they'd likely break copyright as the changes aren't GPLv2 licensed (yet) in this case. But... I'm not a lawyer, you are not a lawyer (I assume), please *do not give legal advice on this mailing list*. And please read the GPL. Don't make claims about it, unless you under- stood it as a whole (hint: there's a part about products and distri- bution in binary form, iirc, that you should read carefully). I agree that the changes might contain cherries to pick. But that doesn't change the way licenses work. If you want to change that, go out on the street, protest against copyright. Nico 0xBD56B4A4138B3CE3.asc Description: application/pgp-keys -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Further coreboot releases, setting new standards
I strongly agree with you that no currently-used-boards should be dropped from coreboot, because even a person who is "just a user" could become a contributor eventually, and it would have been really foolish to artificially reduce the userbase/coderbase by "forking out" the people... However, > As a pure consulting service, the ports and customizations that we have made > to coreboot to support our clients' hardware > (including the work done for Intel) is turned over to the client at the end > of each project to do with as they please. If they choose > to upstream it or not to coreboot.org is really up to them, and if they do, > it would get upstreamed by them, not by us, > since they then own the code. <--- ??? Almost all the coreboot source code is GPLv2 licensed, not some commercial closed-source proprietary license, and you will not be breaking this GPLv2 license by contributing your patches even though they have been created by the request of your clients. If you are providing the coreboot consulting to your clients, it is quite likely that they don't know much about coreboot (at least compared to you) and would not be able to contribute the patches in the mergeable quality even if they wanted, so you shouldn't rely on them here. It would be really nice if you could look through your patches and contribute at least those which are "not motherboard-specific". If you would start giving back more than you are currently, there would be smaller chance of your boards dropped. And your clients should understand that, although no client's approval is required to contribute these patches for GPLv2 open source software Best regards, Mike Banon On Wed, Nov 28, 2018 at 5:00 AM Jay Talbott wrote: > > Hi Paul, > > > -Original Message- > > From: coreboot [mailto:coreboot-boun...@coreboot.org] On Behalf Of Paul > > Menzel > > Sent: Sunday, November 25, 2018 7:29 AM > > To: Jay Talbott; Arthur Heymans; Patrick Georgi > > Cc: coreboot@coreboot.org > > Subject: Re: [coreboot] Further coreboot releases, setting new standards > > > > Dear Jay, > > > > > > Am Freitag, den 23.11.2018, 19:20 -0700 schrieb Jay Talbott: > > > I know I don't post much here, but I feel like I need to chime in on > > > this thread... Perhaps it's time that SysPro becomes a louder voice > > > in the community. > > > > > > Bay Trail and Broadwell DE are both still very popular platforms, yet > > > neither one of them meets the cut for any of the three criteria. So I > > > caution against removing the support for either of them too hastily. > > > > It’d be nice if you gave a little bit more background, what your > > company does. > > > > Normally I wouldn't promote what we do in this forum, but since you asked... > > SysPro Consulting is a team of low-level software/firmware engineers. > Developing coreboot+FSP solutions for Intel-based systems is one of our key > areas of expertise, and currently makes up the majority of our business. > SysPro is one of the licensed coreboot consulting services listed on the > coreboot website. We are also one of Intel's firmware ecosystem partners. > > Starting back when Intel first came out with the very first FSP, I spent > several years providing consulting services directly to Intel working with > Intel's FSP team to help enable coreboot+FSP solutions on customer boards and > systems based on various Intel platforms (including Bay Trail and > Broadwell-DE, which are still popular platforms today, but are potentially on > the chopping block for coreboot, which is why I chimed into this discussion). > > Since then, I have worked directly with a number of Intel customers to > develop custom coreboot+FSP solutions for their products. During 2018 I have > expanded SysPro from being just myself as an independent consultant to become > a whole team of consultants, and we are anticipating continued growth in 2019 > and beyond. Developing custom BIOS and BIOS alternative (e.g. coreboot+FSP) > firmware solutions is anticipated to be a significant part of our business > going forward. > > We also have an FSP source license from Intel so that we can generate custom > FSPs as needed for clients that need certain workarounds, bug fixes, or > enhanced functionality. > > > I can’t find any commits from you for example. > > > > git log --author=sysproc > > > > Although I have participated in a number of reviews of coreboot patches, I/we > have not directly upstreamed any patches to coreboot.org. As a pure > consulting service, the ports and customizations that we have made to > coreboot to support our clients' hardware (including the work done for Intel) > is turned over to the client at the end of each project to do with as they > please. If they choose to upstream it or not to coreboot.org is really up to > them, and if they do, it would get upstreamed by them, not by us, since they > then own the code. > > > > Yes, it can be a pain to keep maintaining old platforms, and > > >
Re: [coreboot] Skylake (XHCI): System self start just after suspend S3.
Naresh: > Can you provide kernel logs Partial kernel logs are attached showing failed and successful s3. > Also can you provided MMIO dump of PORTSC before & after S3 entry. I still don't know how to dump memory from fedora (could you suggest some tool?). > XHCI MMIO base can be found using command: > lspci -s 00:14.0 -vvvk # I guess bus 0, device 0x14, func 0 is XHCI ctrl. > region 0 is MMIO base Region 0: Memory at d122 (64-bit, non-prefetchable) [size=64K] > PORTSC for USB3 is in offset range 0x500-0x580. Still pending because I need a memory dumping tool/command... (I am investigating /dev/crash memory dump) please advise. Thank you, Jose. Suspend_OK_Kernel_Log Description: Binary data Failed_S3_Kernel_Log Description: Binary data XHCI_MMIO_base Description: Binary data -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Asus Chromebox Panther: no HW RNG?
Sorry but I think that relying on Intel RNG is a _Terrible_ idea regarding the security and not sure you should be pursuing it. If you really want a hardware RNG that is also secure, why not take a look at some USB dongles like FST-01 or Librem key? Here is a ( sadly deleted recently! ) Wikipedia comparison page - https://web.archive.org/web/20180812092012/https://en.wikipedia.org/wiki/Comparison_of_hardware_random_number_generators - You can check it to find the best price/performance USB TRNG dongle which is also open hardware Best regards, Ivan Ivanov вт, 27 нояб. 2018 г. в 22:50, Grant Grundler : > > On Tue, Nov 27, 2018 at 4:10 AM Nico Huber wrote: > > > > Hi Grant, > > > > I don't know how it is supposed to work on Haswell, but can give you > > some pointers anyway. > > > > tl;dr I don't think you are looking for a PCI device. > > If intel-rng support is required, a PCI device will be advertised > because of how the linux kernel binds PCI devices to drivers. See > "alias" field of "modinfo intel-rng" as an example. > > One of the search results pointed at a response that said "load > intel-rng driver" as the solution to this problem... that's the only > reason I'm exploring this path. > > > Am 27.11.18 um 08:11 schrieb Grant Grundler: > > > Asus Chromebox (Panther) with Celeron 2995U processor is supposed to > > > have a HW Random Number Generator: > > > > > > https://ark.intel.com/products/75608/Intel-Celeron-Processor-2955U-2M-Cache-1-40-GHz- > > > > > > (Intel calls it Secure Key) > > > > > > But "modprobe intel-rng" is failing with "No such device" (Debian > > > 4.18.0-2-amd64 kernel). > > > > This driver is for very old Firmware Hub (FWH) hardware which would > > be controlled through the LPC PCI device. You have such a PCI device > > (00:1f.0) but there's no FWH to be expect with Haswell. > > Hrm. OK. But that would explain why intel-rng driver only binds with > PCI devices. > > > What you are probably looking for is the RDRAND instruction. I don't > > know if it can be controlled by the firmware, but would check first if > > your OS is prepared to make use of it. > > Linux kernel has supported RDRAND for a long time. There is even a > public debate about *excluding* RDRAND use since some people were > hypothesizing that RDRAND was "compromised" by Intel so "goverment > agencies" could break encrypted traffic which used RDRAND exclusively > to generate encryption keys. Linux kernel does NOT exclusively use > RDRAND and Ted Tyso made compelling arguments that RDRAND would still > add "entropy" to key generation. > > What I don't know is how linux figures out it can or should use > RDRAND. RDRAND appears to be a "CPU feature": > > arch/x86/include/asm/cpufeatures.h:#define X86_FEATURE_RDRAND > ( 4*32+30) /* RDRAND instruction */ > > And as notedin original email, Intel says this CPU (Celeron 2995U) > supports "Secure Key" which is the new marketing name for HW RNG > support (could be only via RDRAND now). > > > > > Why do I care about HW RNG? > > > Because of this: > > > ... > > > [8.560270] r8169 :01:00.0 enp1s0: link up > > > [8.560287] IPv6: ADDRCONF(NETDEV_CHANGE): enp1s0: link becomes ready > > > [19039.712644] random: crng init done > > > [19039.712649] random: 7 urandom warning(s) missed due to ratelimiting > > > [19044.485625] wlp2s0: authenticate with ... > > > ... > > > > > > Yes, several *hours* until the crng was initialized and then > > > wpa_supplicant could start talking on WIFI. :( > > > > > > The length of the delay varies...shortest was 7 minutes. > > > > Well, even without a hardware rng, I wouldn't expect that. > > Exactly. I didn't either. My NUC5 completes typically in 3 second from > the time the kernel is loaded. But this is a different CPU (Intel Core > i5 6260) and completely different firmware (If Coreboot was available > for this, I'd prefer Coreboot). > > > With antennas > > available, I would say after 10s for the paranoid there should be enough > > entropy available. But that's probably just how I'd do OS development > > (and depends on what the wifi driver can do). > > I don't know if the kernel has access to any radios (or antennas) > until the 80211 link is brought up... which in turn won't happen until > wpa_supplicant is running. So something else is wrong here. My > suspicion is still on Coreboot not providing something that tells the > linux kernel a quick method to generate random numbers. > > I saw Matt DeVillier's response as well and I'll follow up once I've > updated the SeaBIOS firmware, installed rng-tools5, and determined > which CPU features are advertised by both Panther and NUC CPUs. For > some reason my "phone home" (SSH) is getting rejected right now. :( > > cheers, > grant > > > 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
