September 2018 - coreboot - mail.coreboot.org

Re: [coreboot] USB 2.0 EHCI debug dongle doesn't print logs (at Lenovo G505S)
by Nico Huber Sept. 30, 2018

Sept. 30, 2018

Hi Ivan, On 9/28/18 11:50 PM, Ivan Ivanov wrote: > Thank you for spkmodem comments, now I'm trying out a more reliable > way - FT232H dongle - to extract the logs from AMD Lenovo G505S. I > plug it into the correct port - USB 2.0 at laptop's right side. > However it doesn't print anything except this short test message: > --- /* Perform a small write. */ > --- ret = dbgp_bulk_write_x(&pipe[DBGP_CONSOLE_EPOUT], "USB\r\n", 5); > ------ line 322 of ./coreboot/src/drivers/usb/gadget.c > > Thinking that it breaks during the relocation from romstage to > ramstage (migrate_ehci_debug function at ehci_debug.c ?) , I disabled > CONFIG_USBDEBUG_IN_ROMSTAGE - but the results are the same: only "USB" > message. I could see > --- dprintk(BIOS_INFO, "Test write done\n"); > ------ line 328 of ./coreboot/src/drivers/usb/gadget.c > at cbmem logs, but even that doesn't get copied to FT232H output. the purpose of dprintk() here is to only print when EHCI debug is _not_ activated yet. Otherwise the code trying to print something would be called recursively. But it might actually work at this early point, with proper configuration (see below). > > Please could you take a look at my coreboot .config and cbmem logs, > what if this FT232H dongle doesn't get selected as console output for > some reason? CONFIG_CONSOLE_CBMEM is still enabled, but maybe I should > disable it? You are missing CONFIG_CONSOLE_USB. Nico

2 1

Re: [coreboot] 8GB graphics cards work on coreboot - in case anyone is wondering
by Jonathan Seefelder Sept. 30, 2018

Sept. 30, 2018

As for the PSU: Personally, i favor the Seasonic Prime Titanium 1000w. I can confirm that the Radeon RX 560 and 580 work also. Also the Nvidia 710, its probably the choice if low power is your aim(i believe like 19w), and some other nvidia quadcore, but i would still recommend to stay away from nvidia (they are not particular open source friendly, more like the opposite) cheers On 9/30/18 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. If nobody has been > able to test this, and you (or someone else) has the opportunity this > might be an interesting thing to test. > > 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. > > On another note, does anyone have a favorite PSU for these boards? > 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. > > Sincerely, > -Matt > > > > On Sat, Sep 1, 2018 at 4:15 PM Mike Banon <mikebdp2(a)gmail.com > <mailto:mikebdp2@gmail.com>> wrote: > > Taiidan, thank you very much for your valuable feedback! When I've > been thinking of getting KGPE-D16 my main concern was that some high > end GPUs wouldn't work for some reason and it was difficult to find > any info... Luckily your RX580 doesn't have a Security Processor > inside it ! Did you know AMD started putting this "security processor" > crap into their GPUs also, starting with Vega? Hopefully RX line would > be safe for a while, maybe I'd get RX680 when it comes out if it will > not be tainted by this "security" :P Wish you to get a second nice > Opteron one day > On Sat, Sep 1, 2018 at 10:41 PM Taiidan(a)gmx.com > <mailto:Taiidan@gmx.com> <Taiidan(a)gmx.com > <mailto:Taiidan@gmx.com>> wrote: > > > > I was worried that it wouldn't work for some reason like due to > lack of > > 64bit MMIO in coreboot but I just installed an AMD Raden RX580 > 8GB on my > > KGPE-D16 and it works great. > > > > I am playing the latest games on max settings in a VM with a GPU > > bottleneck at 1080p with my single 6328 CPU...it is nice to > finally have > > good smooth gameplay with high fps. > > > > -- > > coreboot mailing list: coreboot(a)coreboot.org > <mailto:coreboot@coreboot.org> > > https://mail.coreboot.org/mailman/listinfo/coreboot > > -- > coreboot mailing list: coreboot(a)coreboot.org > <mailto:coreboot@coreboot.org> > https://mail.coreboot.org/mailman/listinfo/coreboot > > -- Kind Regards Jonathan Seefelder

1 0

Re: [coreboot] 8GB graphics cards work on coreboot - in case anyone is wondering
by Matt B Sept. 30, 2018

Sept. 30, 2018

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. If nobody has been able to test this, and you (or someone else) has the opportunity this might be an interesting thing to test. 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. On another note, does anyone have a favorite PSU for these boards? 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. Sincerely, -Matt On Sat, Sep 1, 2018 at 4:15 PM Mike Banon <mikebdp2(a)gmail.com> wrote: > Taiidan, thank you very much for your valuable feedback! When I've > been thinking of getting KGPE-D16 my main concern was that some high > end GPUs wouldn't work for some reason and it was difficult to find > any info... Luckily your RX580 doesn't have a Security Processor > inside it ! Did you know AMD started putting this "security processor" > crap into their GPUs also, starting with Vega? Hopefully RX line would > be safe for a while, maybe I'd get RX680 when it comes out if it will > not be tainted by this "security" :P Wish you to get a second nice > Opteron one day > On Sat, Sep 1, 2018 at 10:41 PM Taiidan(a)gmx.com <Taiidan(a)gmx.com> wrote: > > > > I was worried that it wouldn't work for some reason like due to lack of > > 64bit MMIO in coreboot but I just installed an AMD Raden RX580 8GB on my > > KGPE-D16 and it works great. > > > > I am playing the latest games on max settings in a VM with a GPU > > bottleneck at 1080p with my single 6328 CPU...it is nice to finally have > > good smooth gameplay with high fps. > > > > -- > > coreboot mailing list: coreboot(a)coreboot.org > > https://mail.coreboot.org/mailman/listinfo/coreboot > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] flashrom and 256 MiB S256FL256S
by Nico Huber Sept. 30, 2018

Sept. 30, 2018

On 9/28/18 11:20 PM, ron minnich wrote: > I spoke too soon. It just flat out does not work to have sf100 and 256Mbit > part AFAICT Ah, crap. I just gave this another thought and now I'm convinced that it can't work with the current code. dediprog_spi uses its own functions for read/write that likely don't call into the common, 4BA aware code. I'll try to provide a patch later tonight... Nico

1 1

Re: [coreboot] SPI controller and Lock bits
by Sam Kuper Sept. 30, 2018

Sept. 30, 2018

On 29/09/2018, ron minnich <rminnich(a)gmail.com> wrote: > On Sat, Sep 29, 2018 at 1:59 PM Sam Kuper <sam.kuper(a)uclmail.net> wrote: >> Small momentary switches cost pennies and laptops usually have about a >> hundred of them fitted, of various kinds. (Power on/off/suspend; >> volume up/down; keyboard keys; maybe others.) So, fitting laptops with >> momentary switches is definitely acceptable to manufacturers. > > I'm guessing you don't work in a company that designs or builds laptops :-) True enough. I have worked at a company that designed and built other consumer electronics, though, and spent time with people speccing PCBs and custom silicon. > b/c they agonize over parts like this. I ran into one situation where the > ODM removed a single pulldown to save cost. One little > almost-too-small-to-see part which cost a fraction of a cent. But a laptop > BOM is a consequence of thousands of decisions of this type. > > Nope, the switch is definitely a non-starter, esp. given that there are > solutions that don't require it. > > 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.

1 0

Re: [coreboot] SPI controller and Lock bits
by ron minnich Sept. 29, 2018

Sept. 29, 2018

On Sat, Sep 29, 2018 at 1:59 PM Sam Kuper <sam.kuper(a)uclmail.net> wrote: > Small momentary switches cost pennies and laptops usually have about a > hundred of them fitted, of various kinds. (Power on/off/suspend; > volume up/down; keyboard keys; maybe others.) So, fitting laptops with > momentary switches is definitely acceptable to manufacturers. > I'm guessing you don't work in a company that designs or builds laptops :-) b/c they agonize over parts like this. I ran into one situation where the ODM removed a single pulldown to save cost. One little almost-too-small-to-see part which cost a fraction of a cent. But a laptop BOM is a consequence of thousands of decisions of this type. Nope, the switch is definitely a non-starter, esp. given that there are solutions that don't require it. 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.

1 0

Re: [coreboot] SPI controller and Lock bits
by Sam Kuper Sept. 29, 2018

Sept. 29, 2018

On 29/09/2018, ron minnich <rminnich(a)gmail.com> wrote: > It's not a screw in Chromebooks any more, see vadim's excellent OSFC.io > talk on how it works now. Vadim Bendebury? This talk below? https://osfc.io/talks/google-secure-microcontroller-and-ccd-closed-case-deb… If so, is there a video or audio recording available? Thanks. > I think the momentary switch would not be acceptable to anyone for cost Small momentary switches cost pennies and laptops usually have about a hundred of them fitted, of various kinds. (Power on/off/suspend; volume up/down; keyboard keys; maybe others.) So, fitting laptops with momentary switches is definitely acceptable to manufacturers. > and reliability reasons. Such switches are often rated for ~100,000 cycles. It seems unlikely that any laptop or its owner would live long enough to flash the ROM chip even close to 100,000 times. So, I don't anticipate a reliability problem. > The way chromebooks do the protection now is really well done. I look forward to reading Vadim's slides, and perhaps also to watching or listening to his talk. Thanks for the pointer.

1 0

Re: [coreboot] flashrom and 256 MiB S256FL256S
by Peter Stuge Sept. 29, 2018

Sept. 29, 2018

ron minnich wrote: > yeah, also is there a programmer you recommend for 32MiB parts? I don't have a recommendation just yet, but a question: Speed aside, is single bit IO good enough for 32MiB, or is DIO/QIO required? //Peter

2 1

Re: [coreboot] SPI controller and Lock bits
by Peter Stuge Sept. 29, 2018

Sept. 29, 2018

Youness Alaoui wrote: > avoid any malware writing to the flash Just disallow flash writes by the platform. Allow flash writes only by dedicated hardware (maybe ChromeEC?) which implements a simple and efficient security protocol. Looking for a software solution is IMO like Intel trying to secure SMM. //Peter

3 2

Re: [coreboot] SPI controller and Lock bits
by Nico Huber Sept. 29, 2018

Sept. 29, 2018

On 9/28/18 4:18 AM, Sam Kuper wrote: > On 28/09/2018, Peter Stuge <peter(a)stuge.se> wrote: >> Youness Alaoui wrote: >>> avoid any malware writing to the flash >> >> Just disallow flash writes by the platform. Allow flash writes only >> by dedicated hardware (maybe ChromeEC?) which implements a simple and >> efficient security protocol. > > Relevant URL: https://www.chromium.org/chromium-os/ec-development#TOC-Write-Protect This seems to state the opposite of what Peter suggested, i.e. the host firmware is responsible of validating the EC firmware('s update) and not the other way around. IMHO, a good idea. Nico

2 1