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
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
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
>
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
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.
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.
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.
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
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
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
