Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards

2017-10-09 Thread Julius Werner 
> And now I'm kinda stuck. The effect of this commit doesn't seem to interface
> with bios for me. So how does original IBASE/DFI bios can overcome code
> error before this commit?
>
> What can be the source of my problem? What should I investigate more precise
> based on result that I've got?

My gut feeling would be to blame ACPI. The Linux patch is about
caching a host controller register in the kernel, and in some cases
(e.g. ehci_reset()), the patch re-reads the cached version from the
hardware whereas the previous code didn't. If some BIOS ACPI mucks
with that register, it's possible that this got the kernel's cached
copy out of sync before this patch, but with the patch the kernel will
re-read it from the hardware at the right time. Maybe only coreboot's
ACPI routines touch the register in that path, or maybe the vendor
BIOS' routines were more careful to restore the original state
afterwards.

Besides ACPI this could also be in SMM code, I guess (especially if
the problem occurs around system suspend/resume, although it sounds
like it doesn't for you).

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] greetings and laptop questions

2017-10-09 Thread Nico Huber 
On 10.10.2017 01:54, Youness Alaoui wrote:
> On Sun, Oct 8, 2017 at 6:15 PM, taii...@gmx.com  wrote:
>>
>>>
>>> (I also am looking at system76 and Purism but I am bit leery of spending a
>>> lot with a small / new company - comments appreciated)
>>
>> Purism dishonestly markets their products - while they claim that their
>> laptops "respect freedom and privacy" their version of coreboot is nothing
>> more than a wrapper layer for intel FSP (binary blob that does all the
>> hardware init) which is next to pointless for the amount of money you would
>> spend on one as all it does is move trust from vendor to OEM not avoiding
>> the hypothetical OEM firmware backdoors.
>>
>> System76 is a fine choice if all you want is a laptop that runs linux
>> without difficulty.
>>
> 
> I don't get why you constantly try to discredit Purism and insult
> everything we do. You complain about coreboot being "useless" because
> it uses FSP, but you fail to mention that anything using coreboot will
> use the FSP unless it's 10 year old hardware (Sandybridge is the
> latest FSP-free supported CPU).

Please keep the dimension right, newest is Ivy Bridge and that is 5
years old.

> The original email asked about a
> coreboot port, not a libreboot port. Every time I see purism
> mentioned, you have to jump in to insult and dishonestly say that
> Purism is dishonest. If you want to claim bullshit like that, at least
> find something real and concrete to back it up. I've ignored you many
> times, but I'm fed up of your one-man vendetta against Purism. What
> happened to you for you to have so much hate against us?

It's not him alone, you might remember our discussion about it (it
ended with you writing poems that I didn't even had the time to read
in the end, please don't do that again).

> 
> Extremely funny how you then say that System76 is "a fine choice"
> considering that System76 doesn't even come with coreboot, and even if
> it did come with coreboot, it would of course, still depend on the
> FSP. Also, System76 hardware depends on components which do require
> binary blobs, as opposed to Purism laptops, so I don't get why
> System76 is "a fine choice" if Purism isn't.

It's pretty simple, System76 seems to advertise what say sell, Purism
doesn't. I'd say they do most things right, but not the advertisement.
Most Linux supporting vendors are honest about their products. Yet,
Purism makes claims such as:

   "Only by selecting each and every chip in our Librem laptops can
we guarantee your privacy, security and freedom are protected."

Where I still argue, it's the opposite with Intel inside.

Everything else, they seem to do alright. I'd fully support them if
they'd stop the false advertisement of being super secure. They are
not, just a little better than the rest (by hardware design, don't
know about the details of their software and how secure the hard-
ware is configured).

So my conclusion, Purism draws customers from other Linux supporting
vendors with dishonest marketing. If that doesn't bother you, fine.
But please don't get angry if it bothers honest people.

Nico

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] greetings and laptop questions

2017-10-09 Thread Nico Huber 
On 09.10.2017 00:15, taii...@gmx.com wrote:
> their version of coreboot is
> nothing more than a wrapper layer for intel FSP (binary blob that does
> all the hardware init) which is next to pointless for the amount of
> money you would spend on one as all it does is move trust from vendor to
> OEM not avoiding the hypothetical OEM firmware backdoors.

I've seen that mentioned a lot and can only say: Please stop spreading
that FUD about coreboot. Even with blobed silicon init, coreboot still
gives you about 80% of the freedom of a free firmware. You only have
to trust in one party that provides the blob and not in n parties that
put their code into the usual Windows booting firmware. coreboot, even
blobed, also gives you much more freedom about the platform configu-
ration and the boot process as a whole.

Don't get me wrong, I don't like FSP either (from a developer point of
view, it makes coreboot porting twice as hard and 10 times more frus-
trating if something doesn't work right away). You can stomp on it as
you wish. But please don't disgrace coreboot.

Nico

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] greetings and laptop questions

2017-10-09 Thread Nico Huber 
On 09.10.2017 02:39, Duncan wrote:
> Hi,
> 
> I am not aware of a Coreboot port for the W530. Do you have any more
> information?

The W5xx and T5xx models usually share the same motherboard. The only
difference I know of is that the W530 comes more likely (maybe always)
with 4 DIMM slots. 4 DIMMs is not much tested with the native code but
you can always use the MRC blob as last resort (should be doable in a
day with some community support (if flashing and debugging are already
set up)).

Nico

> 
> Best,
> Duncan
> 
> taii...@gmx.com:
>> On 10/08/2017 11:06 AM, Jim Hendrick wrote:
>>
>>> Just subscribed - I will mostly "lurk" but I do have a few questions for
>>> the group.
>>>
>>> I am looking at a new laptop, and one of my options is a Dell Precision
>>> 7510 (I like the quad-core and loads of RAM available) but I would
>>> like to
>>> not use a vendor BIOS.
>>>
>>> Has anyone put coreboot on one of these?
>> Assuming there is no hardware code signing enforcement anti-feature
>> ("boot guard") for the firmware enabled you would have to port coreboot
>> to it, this would take around 6 months for a skilled firmware engineer.
>>> Anyone tried and failed?
>>>
>>> Any recommendations for something similar (a good laptop ~15 in.
>>> quad-core,
>>> 32GB RAM and fast SSD storage)?
>>> I will be running multiple virtual machines - hence the RAM and cores...
>> W530, supports open source hardware init coreboot and me cleaner.
>> Buy one, install your own SSD, RAM upgrade and W520 keyboard/armrest if
>> you don't like the chiclet layout.
>>
>> Alternatively you could get a G505S (owner controlled) if you don't want
>> ME/PSP - but that only supports 16GB RAM.
>>> (I also am looking at system76 and Purism but I am bit leery of
>>> spending a
>>> lot with a small / new company - comments appreciated)
>> Purism dishonestly markets their products - while they claim that their
>> laptops "respect freedom and privacy" their version of coreboot is
>> nothing more than a wrapper layer for intel FSP (binary blob that does
>> all the hardware init) which is next to pointless for the amount of
>> money you would spend on one as all it does is move trust from vendor to
>> OEM not avoiding the hypothetical OEM firmware backdoors.
>>
>> System76 is a fine choice if all you want is a laptop that runs linux
>> without difficulty.
>>
> 


-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] greetings and laptop questions

2017-10-09 Thread Youness Alaoui 
On Sun, Oct 8, 2017 at 6:15 PM, taii...@gmx.com  wrote:
>
>>
>> (I also am looking at system76 and Purism but I am bit leery of spending a
>> lot with a small / new company - comments appreciated)
>
> Purism dishonestly markets their products - while they claim that their
> laptops "respect freedom and privacy" their version of coreboot is nothing
> more than a wrapper layer for intel FSP (binary blob that does all the
> hardware init) which is next to pointless for the amount of money you would
> spend on one as all it does is move trust from vendor to OEM not avoiding
> the hypothetical OEM firmware backdoors.
>
> System76 is a fine choice if all you want is a laptop that runs linux
> without difficulty.
>

I don't get why you constantly try to discredit Purism and insult
everything we do. You complain about coreboot being "useless" because
it uses FSP, but you fail to mention that anything using coreboot will
use the FSP unless it's 10 year old hardware (Sandybridge is the
latest FSP-free supported CPU). The original email asked about a
coreboot port, not a libreboot port. Every time I see purism
mentioned, you have to jump in to insult and dishonestly say that
Purism is dishonest. If you want to claim bullshit like that, at least
find something real and concrete to back it up. I've ignored you many
times, but I'm fed up of your one-man vendetta against Purism. What
happened to you for you to have so much hate against us?

Extremely funny how you then say that System76 is "a fine choice"
considering that System76 doesn't even come with coreboot, and even if
it did come with coreboot, it would of course, still depend on the
FSP. Also, System76 hardware depends on components which do require
binary blobs, as opposed to Purism laptops, so I don't get why
System76 is "a fine choice" if Purism isn't.

To answer Jim, the Purism Librem 15 doesn't support 32 GB of RAM, but
it does run coreboot and will come with a disabled ME (blog post
announcing that is pending). If you need a laptop which runs linux
without the need for any of the binary firmware blobs (firmware-linux
package in debian), where the company is actively working on
eliminating the remaining blobs in the system (the ME, the FSP and
VGABIOS) then you might want to look at Purism, if you don't care
about those issues and/or require 32GB of RAM (which our laptops don't
support), then you should discard Purism from your list of choices and
look for something else.

I hope that helps.
.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards

2017-10-09 Thread Zoran Stojsavljevic 
Potihon6ky rebjatiski... Tiho! Daite mne vremja razobratsja!

Thank you,
Zoran

On Mon, Oct 9, 2017 at 11:58 AM, Аладышев Константин 
wrote:

> I try to port coreboot on boards with Haswell CPU and Lynxpoint LP chipset
> (IBASE IB908AF-4650 board, DFI HU968) and I've encountered a strange
> problem. USB devices stop working shortly after OS boot (or after USB
> device
> replug in OS) with flooding system with messages:
>
> hub 1-1:1.0: cannot reset port 5 (err = -110)
> hub 1-1:1.0: cannot reset port 5 (err = -110)
> hub 1-1:1.0: Cannot enable port 5.  Maybe the USB cable is bad?
> hub 1-1:1.0: cannot disable port 5 (err = -110)
> hub 1-1:1.0: connect-debounce failed, port 5 disabled
> hub 1-1:1.0: unable to enumerate USB device on port 5
> hub 1-1:1.0: cannot disable port 5 (err = -110)
> hub 1-1:1.0: hub_port_status failed (err = -110)
> hub 1-1:1.0: hub_port_status failed (err = -110)
>
> Through some digging I've found out that this problem persist on kernels
> <3.5. I've investigated this problem more closely and come down to the fact
> that the kernel commit that solves this problem is:
>
> 3d9545c EHCI: maintain the ehci->command value properly
>
> https://github.com/torvalds/linux/commit/3d9545cc375d117554a9b35dfddadf
> 9189c
> 62775?diff=split
>
>
> And now I'm kinda stuck. The effect of this commit doesn't seem to
> interface
> with bios for me. So how does original IBASE/DFI bios can overcome code
> error before this commit?
>
> What can be the source of my problem? What should I investigate more
> precise
> based on result that I've got?
>
>
> --
> 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] USB problem with Haswell+LynxPointLP motherboards

2017-10-09 Thread ron minnich 
this kind of thing is pretty common. Linux has intermittent problems
working on machines built without a real(TM) bios. Few people test in
unnatural(TM) coreboot environments so you see errors you might not expect.
I've had this off and on since we started in 1999 

On Mon, Oct 9, 2017 at 5:26 AM Trammell Hudson  wrote:

> On Mon, Oct 09, 2017 at 12:58:25PM +0300, Аладышев Константин wrote:
> > I try to port coreboot on boards with Haswell CPU and Lynxpoint LP
> chipset
> > (IBASE IB908AF-4650 board, DFI HU968) and I've encountered a strange
> > problem. USB devices stop working shortly after OS boot (or after USB
> device
> > replug in OS) with flooding system with messages:
>
> Interesting -- I ran into the exact same bug with Haswell while porting
> the NERF firmware and a 4.9.x kernel, and had attributed it to my not
> setting up something right.  It's good to hear that maybe it isn't my
> fault (maybe).
>
> > [...]
> > Through some digging I've found out that this problem persist on kernels
> > <3.5. I've investigated this problem more closely and come down to the
> fact
> > that the kernel commit that solves this problem is:
> >
> > 3d9545c EHCI: maintain the ehci->command value properly
> >
> >
> https://github.com/torvalds/linux/commit/3d9545cc375d117554a9b35dfddadf9189c
> 62775?diff=split
>
> Does it work if you back out that patch?  For my purpose it might be
> enough to maintain a patch until we figure out what is really going on.
>
> --
> Trammell
>
> --
> 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] USB problem with Haswell+LynxPointLP motherboards

2017-10-09 Thread Trammell Hudson 
On Mon, Oct 09, 2017 at 12:58:25PM +0300, Аладышев Константин wrote:
> I try to port coreboot on boards with Haswell CPU and Lynxpoint LP chipset
> (IBASE IB908AF-4650 board, DFI HU968) and I've encountered a strange
> problem. USB devices stop working shortly after OS boot (or after USB device
> replug in OS) with flooding system with messages:

Interesting -- I ran into the exact same bug with Haswell while porting
the NERF firmware and a 4.9.x kernel, and had attributed it to my not
setting up something right.  It's good to hear that maybe it isn't my
fault (maybe).

> [...]
> Through some digging I've found out that this problem persist on kernels
> <3.5. I've investigated this problem more closely and come down to the fact
> that the kernel commit that solves this problem is:
> 
> 3d9545c EHCI: maintain the ehci->command value properly
> 
> https://github.com/torvalds/linux/commit/3d9545cc375d117554a9b35dfddadf9189c 
> 62775?diff=split

Does it work if you back out that patch?  For my purpose it might be
enough to maintain a patch until we figure out what is really going on.

-- 
Trammell

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] OCP Winterfell, NERF, Linux and u-root (was: Ability to remotely debug the grub menu in case of boot failure)

2017-10-09 Thread Rene Shuster 
Haven't heard of it either, so looked it up Friday:
* https://trmm.net/NERF
* https://firmwaresecurity.com/2017/10/02/more-on-google-nerf
* WiWynn (codename: Winterfell):
http://www.opencompute.org/wiki/Server/SpecsAndDesigns

On Sat, Oct 7, 2017 at 5:40 AM, Paul Menzel <
paulepan...@users.sourceforge.net> wrote:

> Dear Ron,
>
>
> Am Freitag, den 06.10.2017, 16:10 + schrieb ron minnich:
> > 2 weeks ago I started an OCP winterfell node booting this way. This was
> > NERF with linux and u-root in flash.  it was about 20 seconds for a full
> > cycle of linux in flash, dhclient, wget, kexec. I ran it 10,000 times,
> got
> > bored, turned it off. It works really, really well.
>
> Do you have more information about that system, and the setup? I’d be
> very much interested in that.
>
>
> Thanks,
>
> Paul
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>



-- 
Tech III * AppControl * Endpoint Protection * Server Maintenance
Buncombe County Schools Technology Department Network Group
ComicSans Awareness Campaign 
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] USB problem with Haswell+LynxPointLP motherboards

2017-10-09 Thread Аладышев Константин 
I try to port coreboot on boards with Haswell CPU and Lynxpoint LP chipset
(IBASE IB908AF-4650 board, DFI HU968) and I've encountered a strange
problem. USB devices stop working shortly after OS boot (or after USB device
replug in OS) with flooding system with messages:

hub 1-1:1.0: cannot reset port 5 (err = -110)
hub 1-1:1.0: cannot reset port 5 (err = -110)
hub 1-1:1.0: Cannot enable port 5.  Maybe the USB cable is bad?
hub 1-1:1.0: cannot disable port 5 (err = -110)
hub 1-1:1.0: connect-debounce failed, port 5 disabled
hub 1-1:1.0: unable to enumerate USB device on port 5
hub 1-1:1.0: cannot disable port 5 (err = -110)
hub 1-1:1.0: hub_port_status failed (err = -110)
hub 1-1:1.0: hub_port_status failed (err = -110)

Through some digging I've found out that this problem persist on kernels
<3.5. I've investigated this problem more closely and come down to the fact
that the kernel commit that solves this problem is:

3d9545c EHCI: maintain the ehci->command value properly

https://github.com/torvalds/linux/commit/3d9545cc375d117554a9b35dfddadf9189c
62775?diff=split


And now I'm kinda stuck. The effect of this commit doesn't seem to interface
with bios for me. So how does original IBASE/DFI bios can overcome code
error before this commit?

What can be the source of my problem? What should I investigate more precise
based on result that I've got?


-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot