coreboot October 2018

coreboot@coreboot.org

53 participants
145 discussions

Re: [coreboot] SPI controller and Lock bits
by Youness Alaoui 01 Oct '18

01 Oct '18

Oh boy, lots of emails to answer! So first, thanks for everyone who shared their input, I very much appreciate it. > I think you can decide what hardware your products include, right? I meant dedicated hardware on the mainboard. Yes, but I'm currently looking for a solution to existing hardware, not for the next laptop Purism produces. And by 'dedicated hardware' I thought you meant only allow users to update their BIOS using an external SPI flasher, which would be impractical of course. > > > > It's not just the part. A single simple part like that has all kinds of > > follow-on effects that are not obvious unless you've been at a company > > which designs and builds consumer electronics. > > Thank you for the perspective. I do understand that changing one > component can affect others. > > Purism isn't a typical laptop company. The addition of hardware > switches, to control webcam, mic and Wi-Fi, is one of the USPs for > their Librem models. These undoubtedly had knock-on effects for the > BOM. Purism was undeterred by that. In that context... > > I'm just asking for one more switch. > > So, Youness and others at Purism: if you are reading this, please do > spec a momentary switch to control flashing on future Librems. Your > security-conscious users will thank you for it. Yes, I already suggested it for the next iteration. It wouldn't be a switch though, but rather a low profile 90-degrees jumper on the motherboard. As for your question earlier about someone forgetting it. I would assume that it would be easy to have the Heads menu show a big warning to the user if it's left unprotected (I assume there would be a way to detect if WP# is 1/0 through a GPIO (or other method) without being able to use that GPIO to override the WP# value). Right now, if you boot into linux while ignoring tampering, you get your ttys in red, as a huge and very visible warning. Also, yes Sam, you did understand me perfectly, thanks! > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] microcode blob or ascii
by Jose Trujillo 01 Oct '18

01 Oct '18

Hello Ranga: It is ASCII just not properly formatted.... Just remove the text from this: 0x00000001, /* Header Version */ 0x00000901, /* Patch ID */ 0x04212014, /* DATE */ 0x00030679, /* CPUID */ 0x69c4e6f1, /* Checksum */ 0x00000001, /* Loader Version */ 0x00000001, /* Platform ID */ 0x0000cbd0, /* Data size */ 0x0000cc00, /* Total size */ 0x00000000, /* reserved */ 0x00000000, /* reserved */ 0x00000000, /* reserved */ to this format: 0x00000001, \ 0x00000901, \ 0x04212014, \ 0x00030679, \ 0x69c4e6f1, \ 0x00000001, \ 0x00000001, \ 0x0000cbd0, \ 0x0000cc00, \ 0x00000000, \ 0x00000000, \ 0x00000000, And try again... Jose Trujillo. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, September 28, 2018 7:28 PM, galla rao <galla.rao80(a)gmail.com> wrote: > Hi , > > How does the coreboot picks the cpu microcodes > > as a blob or ASCII ? > > Tried both option GENERATE FROM TREE and INCLUDE EXTERNAL HEADER > > In Memory it appears it picks the ASCII file, but not a blob > > intel/cpu/baytrail/microcode/M0130679901.h > > 0x00000001, /* Header Version */ > 0x00000901, /* Patch ID */ > 0x04212014, /* DATE */ > 0x00030679, /* CPUID */ > 0x69c4e6f1, /* Checksum */ > 0x00000001, /* Loader Version */ > 0x00000001, /* Platform ID */ > 0x0000cbd0, /* Data size */ > 0x0000cc00, /* Total size */ > 0x00000000, /* reserved */ > 0x00000000, /* reserved */ > 0x00000000, /* reserved */ > > Help me out in understanding this issue > > Regards > Ranga

1 0

Re: [coreboot] Porting coreboot to another Intel's bay-trail
by Jose Trujillo 01 Oct '18

01 Oct '18

Zvika: You are lucky If the model of your board appears in the list of supported nodels because you have to do not much, but, if not, you have to do a "motherboard porting" for your specific system. Is essential you add the correct microcode and configure correctly FSP on memory settings otherwise the system will not boot. Get focused into the "mainboard" tree in the folder where devicetree for your board is located. The most notable files are: devicetree.cb gpio.h Kconfig Makefile.inc and the ACPI folder. Remember: you also need to initialize EC or superio. You need to select the right video framebuffer depending of the payload. etc... To edit devicetree.cb you need to understand the specific architecture of your board and you can enable/disable and add devices there (you can see examples from another boards). To edit gpio.h you need to dump from ypur original "BIOS" the GPIO settings using inteltool (find more details in the text document I already sent you). To edit Kconfig to enable features. To edit Makefile.inc to enable code. To edit ACPI files to provide hardware information to the OS and tell the processor what to do in case of a power event and other many things. This is generally what you have to do to port to your board. Maybe someone else can add something else or correct me if Iam wrong. Good luck, Jose Trujillo. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Saturday, September 29, 2018 9:46 AM, Zvi Vered <veredz72(a)gmail.com> wrote: > Hello, > > I created a new mainboard based on "Bayley Bay FSP-based CRB" > It seems that (at least) the following files are mandatory for build: > > cmos.layout > devicetree.cb > romstage.c > > Am I right ? > If yes - what info required to write those files ? > Can I use coreboot default files instead ? > > Honestly - I thought that FSP binary configuration is all I have to do. > And few changes in menuconfig (e.g ROM size). > > Thank you, > Zvika

1 0

Re: [coreboot] Burn 2MB coreboot.rom on 8MB flash chip
by Jose Trujillo 01 Oct '18

01 Oct '18

Zvika: There are 2 ways to build coreboot: (choose one).... 1.- Including IFD, TXE, GBE etc.... inside coreboot CBFS. 2.- Using the original firmware(FW) with IFD, TXE, GBE already in flash and just rewrite coreboot on top of the BIOS block. Your original computer Firmware = Intel FW + "BIOS" Intel FW = IFD +PD+ME/TXE+GBE BIOS=AMI-Phoenix etc... IFD=Intel Firmware Descriptor Table. PD=Parameters ME=Management Engine (For "Core" kind of processors). TXE=Trusted Execution Engine (For "Atom" kind of processors). GBE=Network card firmware. Zvika said: "After creating coreboot.rom should I always use the original BIOS with ifdtool to convert rom to bin ?" Answer: No, there are other methods and tools that can do the merge.... (ifdtool and Intel's FIT are working fine for me) After the creation of the coreboot build you have 2 ways of doing the flashing for your case: (with fpt). 1.- Flash the full 8MB (Intel FW+coreboot) if the SPI flash is blank or have unknown firmware. Use IFDTool in this case to inject coreboot to Intel FW..... then flash it with fpt . 2.- Flash only the BIOS block (5MB your specific case) in this case ask someone else how to do it with fpt.... I hope this answered your questions. Jose.. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Saturday, September 29, 2018 12:24 AM, Zvi Vered <veredz72(a)gmail.com> wrote: > Hi Jose, > > You wrote: > "My recommended approach is using the original Intel FW with already included the FD, TXE". > > What is "original intel FW" ? > What is FD, TXE ? > > After creating coreboot.rom should I always use the original BIOS with ifdtool to convert rom to bin ? > > Thank you, > Zvika > > On Wed, Sep 26, 2018 at 7:27 PM Jose Trujillo <ce.autom(a)protonmail.com> wrote: > >> You are right Nico, >> >> I just forgot the troubles this caused me. >> I am sorry Vika... My mistake. >> >> I can confirm with Nico: >> ROM chip size = 8MB (your case) >> CBFS_SIZE = 2 to 5MB (your specific case) >> >> My recommended approach is using the original Intel FW with already included the FD, TXE. >> >> I never tested adding regions to coreboot but you can try. >> >> To have better chances of success you should be dumping hardware settings booting with your original "BIOS" (look for the attached file). >> >> Check if the system is "Memory down"or/and ECC because it will be needed to edit FSP (if using it). >> Dump memory settings with the following commands: >> >> sudo dnf install i2c-tools-perl >> sudo modprobe eeprom >> decode-dimms >> >> If you have not done this already there is still a long way to go. >> Don't get intimidated, just do it, if you have questions just ask.... I will try to help >> >> Good luck, >> Jose. >> >> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >> On Wednesday, September 26, 2018 6:28 PM, Nico Huber <nico.h(a)gmx.de> wrote: >> >>> Hi, >>> >>> On 9/26/18 9:19 AM, Jose Trujillo via coreboot wrote: >>> >>> > No, don't change it, you change the size of coreboot only if during the >>> > building process "make" complain that there is not enough space but in >>> > your case your build was already successful leave it like that. >>> >>> this advice seems very weird to me. I'm not experienced with Bay Trail. >>> But unless there is a bug in the Bay Trail code, you should always set >>> the correct ROM_SIZE (to the full flash chip size). Otherwise you may >>> introduce bugs in code that relies on this setting (e.g. saving the >>> MRC cache might fail and so would S3 resume). >>> >>> CBFS_SIZE however is the setting to adjust according to your needs. It >>> should be at most the size of the BIOS region. >>> >>> > In the rare circumstance that more space is required you can increase >>> > coreboot size to 4MB and istill will fit into your system 5MB of space >>> > available. >>> > "ifdtool" will inject coreboot in the top of the BYT_orig.bin and save >>> > as BYT_orig.bin.new that you can flash to your system. >>> >>> I assume this doesn't work oob if you set ROM_SIZE correctly. But it is >>> unnecessary to craft a single file by hand. You can either only flash >>> the BIOS region (recommended) or add the other regions in coreboot's >>> config (HAVE_{IFD,ME,GBE}_BIN). >>> >>> Nico

1 0

Re: [coreboot] 8GB graphics cards work on coreboot - in case anyone is wondering
by Taiidan＠gmx.com 01 Oct '18

01 Oct '18

On 09/30/2018 11:14 AM, Matt B wrote: > Hi, > > One thing I just noticed about the page: > https://www.coreboot.org/Board:asus/kgpe-d16 > > Here "Crossfire XDMA" is listed as needing testing. I added that table. > If nobody has been able > to test this, and you (or someone else) has the opportunity this might be > an interesting thing to test. It is simply PCI-e P2P DMA nothing special so I see no reason why it shouldn't work. I don't have the money/need for a second RX580 so I can't test it. If you want to play games the G34 6328 is what you want, or if you get a KCMA-D8 the C32 4386 - the piledriver cpus are faster than the bulldozer ones. > After learning that this board can take a more modern CPU (family 15h) I'm > now considering it more strongly for a future computer. My K10 box is > *currently* mitigated against Spectre V2 (IBP disabled under CentOS via a > chicken bit) but I don't think it's wise to expect further mitigations to > be forthcoming from AMD should more bugs rear their ugly head. Moving up to > a family 15h CPU means getting updated Spectre V2-mitigating microcode and > a much more realistic expectation of support in the immediate future. I'll > probably even move up to piledriver (like the G505s I'm currently working > on), since a microcode patch will also fix the NMI issue (and I'll be > applying one to the stock microcode anyway). > > I'd be really interested to learn if Crossfire and other features of modern > cards work on these older boards under coreboot, since they may come in > REALLY handy when running any machine learning loads on these boards. Like I said it works fine - you can have a total of 2 dual width cards or 4 single width PCI-e cards plus the PIKE HBA/RAID slot which is actually just a PCI-e x4 reversed slot on the data side (the longer side is the ports fan-out) Of course I would suggest you instead purchase a TALOS 2 as it would be faster, less expensive and give you much more options. Obviously you can't play x86 games on one but folks have already ported a few foss indie games to POWER and unreal engine has a demo. Note the lite version has only two pci-e slots and the recc'ed regular talos 2 must have dual cpus for all the slots to be used so dual 4 core is better than one 8 core. Arguably the most impressive TALOS 2 home setup yet :D https://wiki.raptorcs.com/wiki/User:JSharp#T2.2Fx86_FSC_Heterogeneous_Clust… As always if you require more PCI-e slots on a single board for whatever reason you can purchase a PCI-e expansion system from cyclone microsystems, of course one should consider their uplink requirements (and get at least pci-e 2.0 x16 uplink) although for P2P and VM assignment the onboard PCI-e switch supports ACS so there is no issue there. They appear on fleabay now and again and seem to be made in usa just like the talos 2! > On another note, does anyone have a favorite PSU for these boards? I recommend something from seasonic they seem to make the best stuff these days. > Preferably something that will last a bit longer than crappy consumer gear? > This thing already requires two 8-pin connectors for a dual CPU setup, and > graphics cards demand them now too. The PCI-e power connector is different and not compatible be careful when you hook up your stuff!

1 0

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 October 2018