coreboot January 2017

coreboot@coreboot.org

75 participants
186 discussions

Re: [coreboot] Question about PCIe separate reference clock(solved)
by Predrag Vidic 19 Jan '17

19 Jan '17

Great work Zheng, I'm happy for your success! Best regards, Predrag On Thu, Jan 19, 2017 at 4:35 AM, Zheng Bao <fishbaoz(a)hotmail.com> wrote: > This problem is solved by setting the CPU internal clock as NON-SSC(spread > spectrum clock). > > > PCIe spec says seperate ref clock should be Non-SSC. We only set device > clock as Non-SSC before, > > ignoring the clock at CPU side. > > > Now the system is stable. The"slot clock configuration" and "common clock > configuration" are both still 1. > > It doesn't seem to matter. > > > Thanks to you all. > > > Zheng > > > ------------------------------ > *From:* Kyösti Mälkki <kyosti.malkki(a)gmail.com> > *Sent:* Friday, January 13, 2017 4:58 PM > *To:* Zheng Bao > *Cc:* Predrag Vidic; coreboot(a)coreboot.org; Zoran Stojsavljevic > *Subject:* Re: [coreboot] Question about PCIe separate reference clock > > > On Fri, Jan 13, 2017 at 6:01 PM, Zheng Bao <fishbaoz(a)hotmail.com> wrote: > >> About "Asynchronous clock mode on mainboard side", I guess. >> >> >> Both the device and bridge have the fields "slot clock configuration" >> and "common clock configuration". >> > Again assuming the mainboard side is CPU (some AMD SoC) and you are > running coreboot and can bodify binaryPI / AGESA firmware. > > You can spoof this in the firmware and leave "Common Clock Configuration" > bit unset on both sides, even if they report "Slot Clock Configuration = > 1". This affects the ASPM L0s and L1 latencies devices report in the Link > Capabilities register, but may also change hardware behaviour since specs > require link retraining after bit is set. > > On our board, both the"slot clock configuration" of device (E8860) and >> bridge are 1. >> >> >> Does it mean the "on mainboard" side it does not support "Asynchronous >> clock mode"? >> > So, any specs from the mainboard or CPU side of the link? Ultimately your > 100MHz clock stability and jitter is affected by the choice of your 25MHz > crystal part and PCB layout, right? > > Kyösti > > > >> ------------------------------ >> *From:* Predrag Vidic <pvidic(a)gmail.com> >> *Sent:* Friday, January 13, 2017 10:29 AM >> >> *To:* Zheng Bao >> *Cc:* Zoran Stojsavljevic; coreboot(a)coreboot.org >> *Subject:* Re: [coreboot] Question about PCIe separate reference clock >> >> Hi Zheng, >> >> Schematic is simple and OK. I assume you are trying to run Wolf >> VPXxx-E8860-xxxx or similar GPU borad. You can't do much there if there is >> a hardware problem but it is most possibly a software setup problem. >> >> VPX does not have incomming clock so it is by default in async_clock >> mode. The question is did you allowed that mode on the main board side? >> >> Asynchronous clock mode is not default mode for a motherboard. Check if >> the mode is allowed. Second, check if the other PCIe device can work on the >> motherboard PCIe slot. >> >> Regards, >> Predrag >> >> >> On Fri, Jan 13, 2017 at 6:44 AM, Zheng Bao <fishbaoz(a)hotmail.com> wrote: >> >>> Here is the ref clk part. Please review. >>> >>> No refclk routes to VPX connector. >>> >>> >>> Thanks. >>> >>> >>> Zheng >>> ------------------------------ >>> *From:* Predrag Vidic <pvidic(a)gmail.com> >>> *Sent:* Thursday, January 12, 2017 6:53 PM >>> *To:* Zheng Bao >>> *Cc:* Zoran Stojsavljevic; coreboot(a)coreboot.org >>> >>> *Subject:* Re: [coreboot] Question about PCIe separate reference clock >>> >>> Hi Zheng, >>> >>> Without knowing the particular solution for the PCIe transmitter you >>> have on your board, I'd check refclk pins on your design for the proper >>> termination. The problem can be in irregular readings from the pins. >>> >>> Reragds, >>> Predrag >>> >>> On Thu, Jan 12, 2017 at 3:26 PM, Zheng Bao <fishbaoz(a)hotmail.com> wrote: >>> >>>> Q: do you use local xtal attached to Si52111-B5 to generate local >>>> PCIe 25MHz clock? >>>> >>>> Zheng: yes >>>> >>>> >>>> Q: If you dothis, my next question is how you synchronize these two >>>> clocks: Local >>>> PCIe 25 MHz and common reference clock from CPU? >>>> >>>> Zheng: We do NOT sync these two. >>>> >>>> >>>> Q: Since these two clocks, as I understand above scenario, are >>>> asynchronous to each other?! >>>> >>>> Zheng: yes. Asynchronous. >>>> >>>> >>>> The VPX connector does not have a PCIe ref clock signal, so we can not >>>> send CPU PCIe ref clock to >>>> >>>> device. The PCIe spec says if the separate refclk on devices should be >>>> 100MHz ± 300PPM, with SSC >>>> >>>> off. We believe our board meet this requirement. So we doubt the >>>> problem lies in PCI configration space. >>>> >>>> >>>> Zheng >>>> >>>> >>>> >>>> ------------------------------ >>>> *From:* Zoran Stojsavljevic <zoran.stojsavljevic(a)gmail.com> >>>> *Sent:* Thursday, January 12, 2017 9:22 AM >>>> *To:* Zheng Bao; Predrag Vidic >>>> *Cc:* coreboot(a)coreboot.org >>>> *Subject:* Re: [coreboot] Question about PCIe separate reference clock >>>> >>>> Hello Zheng, >>>> >>>> For decades, I've been FW/SW engineer, but I do understand a little >>>> bit of a HW. I have looked into the Si52111-B5 data sheet for >>>> clarification. >>>> >>>> My problem here is to understand, your use case: do you use local xtal >>>> attached to Si52111-B5 to generate local PCIe 25MHz clock? If you do >>>> this, my next question is how you synchronize these two clocks: Local >>>> PCIe 25 MHz and common reference clock from CPU? >>>> >>>> Since these two clocks, as I understand above scenario, are >>>> asynchronous to each other?! >>>> >>>> Please, clarify for us your use case. >>>> >>>> Thank you, >>>> Zoran >>>> _______ >>>> >>>> On 1/12/17, Zheng Bao <fishbaoz(a)hotmail.com> wrote: >>>> > Our VPX design uses separate reference clock source, which is >>>> Si52111-B5 (No >>>> > spread), instead of common ref clock from CPU. >>>> > Now The system is unstable. Reading PCIE configuration space is >>>> unstable >>>> > too. (If we add some fly wire to make it work with common ref clock, >>>> the >>>> > system becomes stable.) >>>> > >>>> > (abstracted from PCIe spec: 12 Slot Clock Configuration - This bit >>>> indicates >>>> > that the >>>> > component uses the same physical reference clock that the >>>> > platform provides on the connector. If the device uses an >>>> > independent clock irrespective of the presence of a reference >>>> > clock on the connector, this bit must be clear. >>>> > For a multi-Function device, each Function must report the >>>> > same value for this bit.) >>>> > >>>> > Based on my understanding, the BIOS need to read bit "Slot Clock >>>> > Configurationclear" to see if >>>> > separate ref clock is used. BIOS then write bit "Common Clock >>>> > Configuration". >>>> > >>>> > On our board, the bit "Slot Clock Configuration" is always 1, which I >>>> assume >>>> > should be 0. >>>> > >>>> > My question is, how the hardware affect the bit "Slot Clock >>>> Configuration"? >>>> > How do we need to design our board to make the bit "Slot Clock >>>> > Configuration" be 0? >>>> > >>>> > Thanks. >>>> > >>>> > Zheng >>>> > >>>> > >>>> >>> >>> >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://www.coreboot.org/mailman/listinfo/coreboot >> > >

1 0

Coreboot binary for ASUS F2A85-M
by Maxim Gusev 19 Jan '17

19 Jan '17

Good afternoon! I'm trying to start the coreboot 4.5 on my motherboard ASUS F2A85M/CM1745 but when I load it nothing works (AMD Athlon X2 340). No Post codes (im using Post card - 0000 is shown) and there is no information on the monitor screen (is empty). For flashing I'm using the programmer CH341A and the SPI flash WINBOND W25Q64BV. Can you send me the working binary for this motherboard (and maybe config file). Maybe it will be not 4.5 version! I would like to see how it works on real hardware... Thank you very much !!! Sorry to have disturbed you... With best wishes, Max.

1 0

[Resend] Tapping into the core (33C3)
by Denis 'GNUtoo' Carikli 19 Jan '17

19 Jan '17

Hi, I saw your presentation "Tapping into the core"[1] that you gave at the last CCC. As I understand from the slides DCI can be activated trough: - The flash descriptor - UEFI - The P2SB register Are skylake platform safe if: - DCI is disabled in the flash descriptor. - DCI is not activated by the boot firmware(UEFI or coreboot). - DCI is not activated troug the P2SB register. All the above require either code execution on the machine or to open the machine with a screwdriver and reprogram the flash with an external flash programmer. If DCI is enabled in the flash descriptor, then the following attacks can benefit from an enabled-by-default DCI: - Malicious USB devices trying to take over the computer. - Evil maid attacks when trying to bypass the TPM. This might or might not work depending on how the TPM application inside the Management engine works. If I understand correctly, when DCI is disabled in the flash descriptor, such attacks are not possible and the computer is safe. Since skylake computer can be secured, the feature would become an enormous advantage: Coreboot developers might be able to use that feature to make debugging and replacing intel blobs faster and easier. Having more information on the protocol or free software and open source tools would help. This might also be useful for debugging the Linux kernel or other hardware related projects. It might also be possible to run coreboot on laptops with bootguard: Some programable[1] USB3 device controller exist, if a tiny enough USB key can be made, it might be possible to bypass bootguard this way. Users doing that would then be able to use coreboot on more recent computers. Some questions: - Can the debug port be used as an usb device controller? - What is the relationship between DCI and the Management Engine? Can the Management Engine be controlled trough DCI? - Do you have more documentation on the protocol? Is it possible to have the slides? By the way, coreboot and libreboot have several utilities related to the flash descriptor: - ifdtool[3] - ich9gen[4] PS: Sorry for the inconvenience, due to bad exim configuration which will hopefully be fixed now, I've to resend the mail. References: ----------- [1]https://media.ccc.de/v/33c3-8069-tapping_into_the_core [2]http://www.cypress.com/products/ez-usb-fx3-superspeed-usb-30-peripheral-c… [3]utils/ifdtool in coreboot sources. [4]resources/utilities/ich9deblob in libreboot sources. Denis.

7 11

Warning: changed location of EC nvram settings on thinkpad X60 and T60
by Arthur Heymans 19 Jan '17

19 Jan '17

Hi EC nvram parameters on Lenovo thinkpad X60 and T60, which allow to configure things like wlan, bluetooth, trackpoint, etc are not checksummed. This means that defaults for these parameters are never applied when the checksum is invalid, which happens for instance when cmos is cleared or when coming from vendor bios. This patch https://review.coreboot.org/#/c/17041/ puts these parameters in the checksummed area to overcome this issue. A problem with this is that the checksum is most likely already valid so that after this patch these nvram parameters will be at whatever the nvram currently is at these locations. To overcome this issue either: - have coreboot set defaults on next boot by making checksum invalid: "nvramtool -c 0" where 0 is a checksum which is hopefully not correct - reboot and manually set your desired nvram settings "nvramtool -w wlan=Enable, nvramtool -w bluetooth=Enable, etc" Kind regards -------------- Arthur Heymans

1 0

Biostar AM1MHP compatibility?
by Taiidan＠gmx.com 19 Jan '17

19 Jan '17

I can't find the AM1ML anywhere (lame... a real short run for an embedded system) and I was wondering if the AM1MHP is compatible too as it seems (to the naked eye) like a sister model (I figure they wouldn't bother messing with the design that much) Anyone know? or does anyone know of another 1080p supporting low power board that you can buy new? Thanks

1 0

Re: [coreboot] Question about PCIe separate reference clock(solved)
by Zheng Bao 19 Jan '17

19 Jan '17

This problem is solved by setting the CPU internal clock as NON-SSC(spread spectrum clock). PCIe spec says seperate ref clock should be Non-SSC. We only set device clock as Non-SSC before, ignoring the clock at CPU side. Now the system is stable. The"slot clock configuration" and "common clock configuration" are both still 1. It doesn't seem to matter. Thanks to you all. Zheng ________________________________ From: Kyösti Mälkki <kyosti.malkki(a)gmail.com> Sent: Friday, January 13, 2017 4:58 PM To: Zheng Bao Cc: Predrag Vidic; coreboot(a)coreboot.org; Zoran Stojsavljevic Subject: Re: [coreboot] Question about PCIe separate reference clock On Fri, Jan 13, 2017 at 6:01 PM, Zheng Bao <fishbaoz(a)hotmail.com<mailto:fishbaoz@hotmail.com>> wrote: About "Asynchronous clock mode on mainboard side", I guess. Both the device and bridge have the fields "slot clock configuration" and "common clock configuration". Again assuming the mainboard side is CPU (some AMD SoC) and you are running coreboot and can bodify binaryPI / AGESA firmware. You can spoof this in the firmware and leave "Common Clock Configuration" bit unset on both sides, even if they report "Slot Clock Configuration = 1". This affects the ASPM L0s and L1 latencies devices report in the Link Capabilities register, but may also change hardware behaviour since specs require link retraining after bit is set. On our board, both the"slot clock configuration" of device (E8860) and bridge are 1. Does it mean the "on mainboard" side it does not support "Asynchronous clock mode"? So, any specs from the mainboard or CPU side of the link? Ultimately your 100MHz clock stability and jitter is affected by the choice of your 25MHz crystal part and PCB layout, right? Kyösti ________________________________ From: Predrag Vidic <pvidic(a)gmail.com<mailto:pvidic@gmail.com>> Sent: Friday, January 13, 2017 10:29 AM To: Zheng Bao Cc: Zoran Stojsavljevic; coreboot(a)coreboot.org<mailto:coreboot@coreboot.org> Subject: Re: [coreboot] Question about PCIe separate reference clock Hi Zheng, Schematic is simple and OK. I assume you are trying to run Wolf VPXxx-E8860-xxxx or similar GPU borad. You can't do much there if there is a hardware problem but it is most possibly a software setup problem. VPX does not have incomming clock so it is by default in async_clock mode. The question is did you allowed that mode on the main board side? Asynchronous clock mode is not default mode for a motherboard. Check if the mode is allowed. Second, check if the other PCIe device can work on the motherboard PCIe slot. Regards, Predrag On Fri, Jan 13, 2017 at 6:44 AM, Zheng Bao <fishbaoz(a)hotmail.com<mailto:fishbaoz@hotmail.com>> wrote: Here is the ref clk part. Please review. No refclk routes to VPX connector. Thanks. Zheng ________________________________ From: Predrag Vidic <pvidic(a)gmail.com<mailto:pvidic@gmail.com>> Sent: Thursday, January 12, 2017 6:53 PM To: Zheng Bao Cc: Zoran Stojsavljevic; coreboot(a)coreboot.org<mailto:coreboot@coreboot.org> Subject: Re: [coreboot] Question about PCIe separate reference clock Hi Zheng, Without knowing the particular solution for the PCIe transmitter you have on your board, I'd check refclk pins on your design for the proper termination. The problem can be in irregular readings from the pins. Reragds, Predrag On Thu, Jan 12, 2017 at 3:26 PM, Zheng Bao <fishbaoz(a)hotmail.com<mailto:fishbaoz@hotmail.com>> wrote: Q: do you use local xtal attached to Si52111-B5 to generate local PCIe 25MHz clock? Zheng: yes Q: If you dothis, my next question is how you synchronize these two clocks: Local PCIe 25 MHz and common reference clock from CPU? Zheng: We do NOT sync these two. Q: Since these two clocks, as I understand above scenario, are asynchronous to each other?! Zheng: yes. Asynchronous. The VPX connector does not have a PCIe ref clock signal, so we can not send CPU PCIe ref clock to device. The PCIe spec says if the separate refclk on devices should be 100MHz ± 300PPM, with SSC off. We believe our board meet this requirement. So we doubt the problem lies in PCI configration space. Zheng ________________________________ From: Zoran Stojsavljevic <zoran.stojsavljevic(a)gmail.com<mailto:zoran.stojsavljevic@gmail.com>> Sent: Thursday, January 12, 2017 9:22 AM To: Zheng Bao; Predrag Vidic Cc: coreboot(a)coreboot.org<mailto:coreboot@coreboot.org> Subject: Re: [coreboot] Question about PCIe separate reference clock Hello Zheng, For decades, I've been FW/SW engineer, but I do understand a little bit of a HW. I have looked into the Si52111-B5 data sheet for clarification. My problem here is to understand, your use case: do you use local xtal attached to Si52111-B5 to generate local PCIe 25MHz clock? If you do this, my next question is how you synchronize these two clocks: Local PCIe 25 MHz and common reference clock from CPU? Since these two clocks, as I understand above scenario, are asynchronous to each other?! Please, clarify for us your use case. Thank you, Zoran _______ On 1/12/17, Zheng Bao <fishbaoz(a)hotmail.com<mailto:fishbaoz@hotmail.com>> wrote: > Our VPX design uses separate reference clock source, which is Si52111-B5 (No > spread), instead of common ref clock from CPU. > Now The system is unstable. Reading PCIE configuration space is unstable > too. (If we add some fly wire to make it work with common ref clock, the > system becomes stable.) > > (abstracted from PCIe spec: 12 Slot Clock Configuration - This bit indicates > that the > component uses the same physical reference clock that the > platform provides on the connector. If the device uses an > independent clock irrespective of the presence of a reference > clock on the connector, this bit must be clear. > For a multi-Function device, each Function must report the > same value for this bit.) > > Based on my understanding, the BIOS need to read bit "Slot Clock > Configurationclear" to see if > separate ref clock is used. BIOS then write bit "Common Clock > Configuration". > > On our board, the bit "Slot Clock Configuration" is always 1, which I assume > should be 0. > > My question is, how the hardware affect the bit "Slot Clock Configuration"? > How do we need to design our board to make the bit "Slot Clock > Configuration" be 0? > > Thanks. > > Zheng > > -- coreboot mailing list: coreboot(a)coreboot.org<mailto:coreboot@coreboot.org> https://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Proposal: "Freedom level" field for boards supported by coreboot
by Merlin Büge 19 Jan '17

19 Jan '17

On Wed, 18 Jan 2017 18:11:21 -0800 Julius Werner <jwerner(a)chromium.org> wrote: > I think it's fair to penalize boards for this, but not as hard as for > other components. The machine is still perfectly useable with text > mode or software rendering. I would say this is way less severe than a > non-free EC (which essentially means you can't trust your keyboard), > for example. It should rank somewhere among the low inconveniences, > maybe similar to a non-free WiFi chip. Couldn't one just use a separate USB keyboard to circumvent that? > >> A. Everything free. > >> B. Non-essential component (e.g. GPS sensor) requiring proprietary > >> firmware. C. Network component (e.g. WiFi) requiring proprietary > >> firmware if it can be bypassed (e.g. USB, expansion card). > >> D. Input/output-sniffing component (pointing device, keyboard, > >> display, audio) requiring proprietary firmware if it can be > >> bypassed, or CPU requiring microcode if it can be bypassed (e.g. > >> just using factory ROM code). > >> E. CPU or equivalently privileged processor requiring non-resident > >> proprietary boot firmware. > >> F. Network component requiring proprietary firmware that cannot be > >> bypassed (e.g. no USB ports). > >> G. Input/output-sniffing component requiring proprietary firmware > >> that cannot be bypassed, or CPU requiring microcode that cannot be > >> bypassed. > >> H. CPU or equivalently privileged processor requiring resident > >> proprietary firmware (e.g. Intel ME, Qualcomm TrustZone). > > > > My concern is mainly the number of levels. If we make this too > > much of a smooth gradient type thing people won't really understand > > just how bad G and H really are. > > Okay, sure... colors or naming could make that more clear, or just > squash some of these categories together. I didn't really want to > exemplify the granularity here, just how I think different non-free > components should be weighted against each other to fairly represent > the risk to the user. I like how most boards (with ME & Co.) would just get an 'H' :) > We could also try a system of points that get added together to reach > a certain category (e.g. proprietary microcode is worth 5 malus > points, proprietary WiFi could be 2, and resident proprietary firmware > with full access short-circuits to the lowest category). Personally, I like the category-based approach more, as I assume most people would bother less about how many points their hardware scores, instead of in what "freedom" or "security" category their hardware is classified. I think the category approach pulls people more towards libre-friendly hardware. Btw, great effort and interesting discussion :) Regards, Merlin > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot -- Merlin Büge <toni(a)bluenox07.de>

1 0

Re: [coreboot] Proposal: "Freedom level" field for boards supported by coreboot
by Timothy Pearson 19 Jan '17

19 Jan '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/18/2017 07:06 PM, Julius Werner wrote: > Sounds like a good idea in general, but I think the categories might > need some more tweaking. I guess we all have different favorites that > we care about here (e.g. I'm partial to most ARM platforms), we should > have a balanced discussion about what should be weighted more than > what and why to make sure the categories end up fair to all platforms. > > For example, it seems like you're trying to slot RK3288 as "bronze", > which I'd say is argueably the most free platform coreboot supports > right now. I assume your rating comes from the external board > components requiring proprietary firmware in this case. So a few > points to start discussion: The only reason for the Bronze classification is the GPU firmware / driver. I'll admit I'm not as familiar with the RK3822 GPU as I'd like, so if I made an error and it operates without binary blobs then the C201 would be reclassified Platinum. You can't exactly stick a third-party GPU on that SoC to get around the built-in GPU, so if it's not free it's a major problem. > - Is it fair to make external board components weigh more heavily than > processor internals? I think at least external board components that > are not essential (e.g. anything but keyboard, pointing device, > display, network, maybe audio) or can be replaced with other > components (e.g. USB can replace almost everything) should have the > least impact on freedom level. In particular, it's not really fair to > punish a board for including an optional non-free component that other > boards don't have at all (like a laptop with a WiFi chip which > essentially always require proprietary firmware vs. a desktop board > that has nothing but empty PCIe slots). I am trying to head off the easiest thing possible for the manufacturer - -- that is, produce a board that has one feature set for Windows, and another very limited feature set for libre software. I don't think the rankings should be able to be gamed in that manner; when a consumer buys a board they expect that the advertised features of that board work, and without proprietary software so if we've listed it as Gold or Platinum. > - Anything required on the processor (e.g. microcode) should always > weigh more heavily than external components. Disabling an external > component (even something like keyboard/display) still leaves the > system somewhat functional, whereas you can never disable the > processor. Since microcode can essentially do anything I think it > should always give a harsh rating unless it's feasible to run the > board with the ROM-internal version. Why are you assuming the internal ROM microcode is safe? I certainly wouldn't go there; in fact, the errata sheets for most processors show the exact opposite. > - Why are you making an exception for the EC, of all things? The EC is > usually the keyboard controller which is one of the most highly > sensitive things there are. I think a proprietary keyboard controller > should definitely be counted worse than a proprietary WiFi chip, for > example (because they WiFi chip cannot sniff into your HTTPS stream, > but the keyboard controller can totally read the password you typed). I make a very limited exception for an EC that is only an EC; that is, it has no ability to transmit any information it gleans to a third party. I'd like to see that exception disappear ASAP, but I think we should wait until the free EC implementation for the Lenovo machines is finished so that we at least have some examples of true Silver class machines. > So as a quick brainstorming, I'd rather suggest a ranking roughly like > this to fairly reflect the risk the user is exposed to: > > A. Everything free. > B. Non-essential component (e.g. GPS sensor) requiring proprietary firmware. > C. Network component (e.g. WiFi) requiring proprietary firmware if it > can be bypassed (e.g. USB, expansion card). > D. Input/output-sniffing component (pointing device, keyboard, > display, audio) requiring proprietary firmware if it can be bypassed, > or CPU requiring microcode if it can be bypassed (e.g. just using > factory ROM code). > E. CPU or equivalently privileged processor requiring non-resident > proprietary boot firmware. > F. Network component requiring proprietary firmware that cannot be > bypassed (e.g. no USB ports). > G. Input/output-sniffing component requiring proprietary firmware that > cannot be bypassed, or CPU requiring microcode that cannot be > bypassed. > H. CPU or equivalently privileged processor requiring resident > proprietary firmware (e.g. Intel ME, Qualcomm TrustZone). My concern is mainly the number of levels. If we make this too much of a smooth gradient type thing people won't really understand just how bad G and H really are. - -- 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 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJYgBKnAAoJEK+E3vEXDOFba1kIALeBwN+Mx14WB3feh7f0PUzd 33hz3OgDtGnXeU+pzbTmM0m5Qsjl1EHUTiHDoAAdPvYA26TYWxcEMRHO0ntqfpF3 E87UJ7S5LJdwsF+qyVfUE43MD5l5UT17noGnFZYDq0tuPuto26RTQ+T7J07bcEfq zYx7oHy+0ljHLaBqCTHn4bt5EhZDN0SRjjI+Kc09SBWe+Xaf8A/XCMT2RrU/nX5G braFykJFvDljAjdne0ugJV5rVxzF5Dca8w981wGlmAyWENphVaDsFDX3BrRJ2iI9 A72H9cmYWrfCGM8lO7ktPz6+zali2b2tCrFQgZymVwi1PwGD9ewWkzVXA5ThMYg= =T9uo -----END PGP SIGNATURE-----

2 1

Would anyone like a free ASMB4-iKVM module?
by Taiidan＠gmx.com 19 Jan '17

19 Jan '17

Early bird gets the worm, send me an address and I'll drop it in the mail for you. This is a (currently closed source non libre) network kvm module for certain ASUS motherboards including the kgpe-d16 and kcma-d8 Obviously remove the list reply address so your addy doesn't end up public.

1 1

Re: [coreboot] SMBIOS table enablement in coreboot
by David Hendricks 17 Jan '17

17 Jan '17

Hi Mayuri, On Sun, Jan 15, 2017 at 5:40 PM, Mayuri Tendulkar < mayuri.tendulkar(a)aricent.com> wrote: > Hi David > > > > Yes, below are settings for our system. As we are using Intel Baytrail, > does this SMBIOS manufacturer shd be Intel? > That's up to you. Mainboard manufacturer, along with product name, serial number, and version, are strings which are expected to be assigned by the vendor. You may set these in your mainboard's Kconfig file. The Macbook 2.1 port shows an example of how to do this: https://review.coreboot.org/cgit/coreboot.git/tree/src/mainboard/apple/macb… . Other SMBIOS tables such as memory info is generated automatically by coreboot. For example, the type 4 table should have details about your processor manufacturer (Intel) as well as information which implies Baytrail (CPU family, model, and stepping). > > > CONFIG_MAINBOARD_SMBIOS_MANUFACTURER="xxxxx" > > # CONFIG_SMBIOS_PROVIDED_BY_MOBO is not set > > CONFIG_GENERATE_SMBIOS_TABLES=y > > CONFIG_MAINBOARD_SMBIOS_PRODUCT_NAME="yyyy" > > > > Regards > > Mayuri > > > > *From:* David Hendricks [mailto:dhendrix@google.com] > *Sent:* 14 January 2017 08:19 > *To:* Mayuri Tendulkar <mayuri.tendulkar(a)aricent.com> > *Cc:* coreboot <coreboot(a)coreboot.org> > *Subject:* Re: [coreboot] SMBIOS table enablement in coreboot > > > > Hi Mayuri, > > Do you have GENERATE_SMBIOS_TABLES enabled in your config? > > > > On Fri, Jan 13, 2017 at 12:56 AM, Mayuri Tendulkar < > mayuri.tendulkar(a)aricent.com> wrote: > > Hi > > We are using coreboot for our board based on Intel Baytrail 3845. > > > > When we use *dmidecode –t *to get DDR details, we get empty. It means > data is missing in SMBIOS. > > > > Are there any settings in coreboot to enable this? > > > > Regards > > Mayuri > > "DISCLAIMER: This message is proprietary to Aricent and is intended solely > for the use of the individual to whom it is addressed. It may contain > privileged or confidential information and should not be circulated or used > for any purpose other than for what it is intended. If you have received > this message in error, please notify the originator immediately. If you are > not the intended recipient, you are notified that you are strictly > prohibited from using, copying, altering, or disclosing the contents of > this message. Aricent accepts no responsibility for loss or damage arising > from the use of the information transmitted by this email including damage > from virus." > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot > > > > > > -- > > David Hendricks (dhendrix) > Systems Software Engineer, Google Inc. > "DISCLAIMER: This message is proprietary to Aricent and is intended solely > for the use of the individual to whom it is addressed. It may contain > privileged or confidential information and should not be circulated or used > for any purpose other than for what it is intended. If you have received > this message in error, please notify the originator immediately. If you are > not the intended recipient, you are notified that you are strictly > prohibited from using, copying, altering, or disclosing the contents of > this message. Aricent accepts no responsibility for loss or damage arising > from the use of the information transmitted by this email including damage > from virus." > -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.

1 0

← Newer
1
...
8
9
10
11
12
13
14
...
19
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 January 2017