Re: [coreboot] Bayley Bay FSP-based CRB
Hello, Thank you very much for the detailed reply. Vendor's BIOS contains few peripherals initialization. For example: PCIe enumeration, SATA controller, USB etc. In case of PCIe enumeration, the generation of PCIe (1,2,3) can be set. Should vendor supply code for this ? or any other information ? How can I write it from scratch ? Can Intel provide information on how to implement this initialization ? Thank you, Zvika On Mon, Jun 18, 2018 at 11:22 AM Jose Trujillo via coreboot < coreboot@coreboot.org> wrote: > Hello Zvika: > 1.- Usually it is not necessary to change the CBFS size unless the > compiler complain of lack of space. > 2.- You should not worry about this setting to make your system to work. > 3.- You should not use FSP_PACKAGE_DEFAULT if your plan is to use SIO > because it will enable SOC internal COM1, instead (if your plan is to use > FSP) enable FSP and add a VGA bios bin manually (The use of FSP is > optional but I never tried without FSP). > 4.- You need to add them yourself, there are examples to follow in this > mail list. > Good luck! > J.Trujillo > > ‐‐‐ Original Message ‐‐‐ > On June 18, 2018 6:24 AM, Zvi Vered wrote: > > Hello, > I inspected the "Bayley Baay FSP-based CRB" sample in coreboot. after make > distclean I chose: > Mainboard vendor: Intel > Mainboard model: Bayley Bay FSP-based CRB > 1. The size of CBFS is: 0x20. Is it a fix size or should I change it > according to my board (which is also bay trail) ? > 2. According to "dmidecode" I ran on my target, "Address: 0xE" > Should I set this address in coreboot configuration ? How ? > > 3. In this board default configuration, "Configure defaults for the Intel > FSP package" is not selected. Is it possible that this board does not use > Intel FSP at all ? > Under "Generic Drivers", "Use Intel firmware Support Package' is also not > selected. > > 4. Under "chipset", there is no option to set "Super I/O". Can you please > tell why ? > 5. I noticed that the minimum ROM size is 2MB. If I set 4MB, the size of > coreboot.rom is also 4MB. > > Thank you in advance, > Zvika > > > -- > 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] [RFH] Native AMD fam10-15 support
On 06/20/2018 03:39 PM, taii...@gmx.com wrote: > On 06/15/2018 03:33 AM, Kyösti Mälkki wrote: >> On Fri, Jun 15, 2018 at 8:58 AM, taii...@gmx.com wrote: >> >>> On 06/14/2018 08:42 PM, Kyösti Mälkki wrote: On Thu, Jun 14, 2018 at 4:38 AM, qtux wrote: Now, since commit babb2e6 that claims to add S3 support on kgpe-d16 is within the latter period, I do not quite see how S3 support could have worked with that commit on kgpe-d16. Or maybe this feature was never retested once it was rebased and upstreamed. Nor can I see how it could have worked for any commit in 4.6 >>> >>> I just tested S3 again and it worked fine on my v4.6 D16. >>> >> >> Please state the commit hash of the source tree you built and booted from, >> we don't literally have such tag as "v4.6". > > I was using the coreboot-4.6.tar.xz from the coreboot download page > which is why I didn't include the hash. > > [0.00] DMI: ASUS KGPE-D16/KGPE-D16, BIOS > 4.6-db508565d2483394b709654c57533e55eebace51 07/10/2017 > >> >> Repeat tests with current master. > > Thanks, I will have info for you by the end of the this weekend and I > will also investigate things myself if S3 doesn't work... > If you can isolate the commit I have time blocked off this week to work on bringing the D16 back up to date... Thanks! -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Thinkpad SD card controller DMA
On 06/20/2018 04:08 AM, Thomasheidler via coreboot wrote: > Hello, > > I noticed that all Lenovo Thinkpads supported by coreboot have a SD card > controller that is connected as a PCI device. I assume that the controller > runs non-free firmware from its own ROM and because it is a PCI device it > should have DMA, which seems like a security risk, right? > > If so, is there a way to prevent the SD card controller from turning on when > the computer is booted, by changing some code in the source (maybe in > devicetree.cb) or at least to stop the controller from having DMA? If you are using linux IOMMU will protect you after it is initialized (a few seconds after main kernel init) even if you don't add the device to a VM but before then you are SOL in terms of protection from a really slick hardware rootkit like one found in a cheap PCI-e card...but I have no idea if that thinkpad SD card PCI-e device has its own firmware. I asked a question like this quite a long time ago and there was a discussion on how to prevent this issue by not providing DMA access in the coreboot phase which is much more simple vs having coreboot init the IOMMU itself pre-linux. Look at my thread: [coreboot] DMA protection? [AMD-Vi] AFAIK nothing has changed since then in terms of security improvements but I would appreciate it if one of the coreboot expert squad can respond to this. Timothy Pearson from Raptor engineering was also willing to add DMA protection to coreboot under contract. I also suggest: Disabling Option ROM execution or executing them with YABEL. Looking in to the a libre EC replacement such as origami-ec and replacing your EC firmware with a "clean" fresh one from a lenovo update directly without using their update tool (which does a variety of things to it such as adding your serial number) which can be done on various models internally so you don't have to connect an external cable. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFH] Native AMD fam10-15 support
On 06/15/2018 03:33 AM, Kyösti Mälkki wrote: > On Fri, Jun 15, 2018 at 8:58 AM, taii...@gmx.com wrote: > >> On 06/14/2018 08:42 PM, Kyösti Mälkki wrote: >>> On Thu, Jun 14, 2018 at 4:38 AM, qtux wrote: >>> Now, since commit babb2e6 that claims to add S3 support on kgpe-d16 is >>> within the latter period, I do not quite see how S3 support could have >>> worked with that commit on kgpe-d16. Or maybe this feature was never >>> retested once it was rebased and upstreamed. Nor can I see how it >>> could have worked for any commit in 4.6 >> >> I just tested S3 again and it worked fine on my v4.6 D16. >> > > Please state the commit hash of the source tree you built and booted from, > we don't literally have such tag as "v4.6". I was using the coreboot-4.6.tar.xz from the coreboot download page which is why I didn't include the hash. [0.00] DMI: ASUS KGPE-D16/KGPE-D16, BIOS 4.6-db508565d2483394b709654c57533e55eebace51 07/10/2017 > > Repeat tests with current master. Thanks, I will have info for you by the end of the this weekend and I will also investigate things myself if S3 doesn't work... -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Thinkpad SD card controller DMA
Hello, I noticed that all Lenovo Thinkpads supported by coreboot have a SD card controller that is connected as a PCI device. I assume that the controller runs non-free firmware from its own ROM and because it is a PCI device it should have DMA, which seems like a security risk, right? If so, is there a way to prevent the SD card controller from turning on when the computer is booted, by changing some code in the source (maybe in devicetree.cb) or at least to stop the controller from having DMA? Thanks a lot, Thomas-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
