Re: [coreboot] greetings and laptop questions

[Zoran Stojsavljevic]

> Sorry for that. My last sentence probably doesn't even express what
> I was trying to say. Could be my bad English.

Your English is quite good.

> I just meant that there are people who are easily offended by dishonesty.

Tell me about dishonesty, Nico. What Purism does is just a pebble of sand
in the desert of big IT companies' dishonesty!

Zoran Stojsavljevic


On Wed, Oct 11, 2017 at 12:57 AM, Nico Huber  wrote:

> On 10.10.2017 20:02, Youness Alaoui wrote:
> >> 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.
> >
> > ...
> > 3 - By stating that it "bothers honest people", right after saying
> > that it doesn't bother me, you're implying that I'm not an honest
> > person (at least that's how I read it) and that kind of statement
> > doesn't lead to cool headed discussions, so I'll simply withdraw from
> > this one.
>
> Sorry for that. My last sentence probably doesn't even express what
> I was trying to say. Could be my bad English. I just meant that there
> are people who are easily offended by dishonesty. Well, yeah, it does
> imply that I don't count you among them.
>
> Nico
>
> --
> 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] Problems changing payload on Intel Leaf Hill

[Melissa Yi]

Hi Tahnia,
 Have you tried 32-bit UEFI payload? I met  this problem in Denverton
platfrom too with 64-bitUEFI payload.

Thanks.

Regards,
Melissa Yi

BIOS Lead Engineer
Celestica(Shanghai) R Center, China

www.celestica.com
Solid Partners, Flexible Solutions

2017-10-10 16:29 GMT+08:00 Tahnia Lichtenstein :

> Hi,
>
> I am trying to build coreboot for the Intel Apollo Lake-I reference board
> (Oxbow Hill, similar to Leaf Hill).
>
> Intel has provided an implementation for this reference board based on an
> outdated coreboot version.
>
> Along with the coreboot implementation, they provided a compatible
> pre-compiled UEFI payload (with no source, but run-time boot menu looks
> like Tianocore's) and a compatible pre-compiled U-Boot payload (with links
> to U-Boot source on Github along with patch so as to reproduce the
> pre-compiled binary). The pre-compiled binaries have associated .config
> files for coreboot integration. When building coreboot with either of the
> precompiled binaries, and stitching the coreboot output binaries together
> with Intel-provided blobs (using Intel provided FIT application) to produce
> the final firmware image, the firmware works as expected.
>
> Then I built this version of coreboot with a self-compiled payload, such
> as Tianocore UDK2017 CorebootPayloadPkg or SeaBIOS, using the .confg files
> provided by Intel for UEFI payloads or legacy payloads respectively (just
> modified for specific payload type and path, and disabling verified and
> measured boot). I stitched the coreboot output with the Intel-provided
> blobs using the exact same method as before. Then, in run-time, coreboot
> transitions to the payload and nothing happens from then on (i.e. no
> further serial debug messages, no change to display monitor).
>
> I also built U-Boot from github, applying Intel's patch to match Intel's
> precompiled binary, and this self-compiled binary works in run-time (well,
> sort of, there are a couple of problems but point is the payload runs). A
> notable build difference is that this build uses the .config file provided
> by Intel as is, and that the payload that was built is the binary
> equivalent of the Intel pre-compiled binary.
>
> Am I not specifying the correct configuration options for Tianocore and
> SeaBIOS? I.e. is there more to it than just selecting the payload type and
> specifying the payload path? Do I need to configure or update memory
> addresses or ranges to match payload sizes, or some such? Do I need to make
> specific changes to the payloads' source code to support the platform? Any
> advice on how/where to start debugging?
>
> (Serial debug logs and .config files attached.)
>
> Best regards,
> Tahnia
>
> --
> 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] greetings and laptop questions

[Jim Hendrick]

Thanks for all the interesting information for my questions (and - um -
"commentary" :-)
It has given me a lot to think about.

Best,
Jim



On Tue, Oct 10, 2017 at 7:10 PM, taii...@gmx.com  wrote:

> The lenovo G505S is the latest owner controlled coreboot x86-64 laptop,
> running the FT3 platform which is 4 years old.
> It supports VMX, RVI and IOMMU.
>
> While it does have a blob for video and power both of those have no
> hardware code signing features (thus replaceable), and unlike ivy bridge it
> doesn't have a black box supervisor processor.
>
> Had the folks from purism asked me what they should do, I would have
> suggested FT3.
>
> On 10/09/2017 07:54 PM, Youness Alaoui wrote:
>
> 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?
>>
> In the efforts of not getting moderated again we can continue this off
> list but it boils down to the dishonest crowdfunding style "some day we
> will do X" marketing.
>
> I would have recommended your devices at least once if you were selling
> them as they were instead of as they could be.
>
> I dislike:
> * Aspirational marketing "LibreM" "every chip hand selected to respect
> your privacy" "continued efforts to remove ME" that confuses even linux
> veterans and detracts from competitors products.
> * The lobbying for the FSF to decrease the RYF standards
> * (although most companies do this) Not asking the target audience for
> advice on what to do next.
>
> I wouldn't have said anything but on the other lists I visit for every
> person like me there are 5 others who constantly talk up your products. I
> believe everyone needs critical voices.
>
> On 10/09/2017 08:42 PM, Nico Huber wrote:
>
> 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.
>>
> Can you suggest a better way of saying it?
>
> People with EE/CS degrees (non-laymen I suppose) I have conversed with
> over the years still consider "coreboot" to mean what it did circa 2011
> where the only real difference between coreboot and libre* was
> philosophical not technical, when someone says "our devices have coreboot"
> they believe that it is entirely "free firmware".
>
> While an FSP coreboot "port" is still technically superior to an entirely
> closed source firmware no one I have talked to would consider spending an
> extra 1K per device just to cut the vendor out of the trust picture (they
> and I desire silicon init)
>
>
> I propose a kind of freedom-level badge certification system (like "Intel
> Inside" stickers) for this situation with everything clearly explained on a
> central website to solve this situation, similar to the one currently on
> the coreboot wiki.
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] Freedom Inside - certification system

[taii...@gmx.com]

In addition to the existing FSF RYF system I propose the creation of a 
"Freedom Inside" rating and certification system where vendors (now that 
there are more than a few) can have their products certified by a 
central body.


This would have:
Multiple levels of freedom with a clear central website with 
explanations of what each freedom level is (low, med, high, or something 
to that effect).

Standardized requirements for company marketing
Everything agreed upon on by various community experts "request for 
feedback"
Indicators of performance level and market segment on the intel inside 
style badge placed on every device (eg: the laymen could use an ARM 
laptop day to day, but has no idea how it compares to an x86 device - 
nor does he know that $2K is a actually a good deal for performance 
server hardware)
Ease of source-compilation requirement, so that the average power user 
can easily roll their own (ex: no getting unsigned 5 year old libs from 
a shady website)


I also propose a hardware-freedom-generic mailinglist be created for 
philosophy debates, "should I buy X?", newbie questions etc moreso now 
that TALOS 2 is in the picture the hardware freedom world is more than 
just coreboot so I think it would be a great idea.


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

Re: [coreboot] greetings and laptop questions

[taii...@gmx.com]

The lenovo G505S is the latest owner controlled coreboot x86-64 laptop, 
running the FT3 platform which is 4 years old.

It supports VMX, RVI and IOMMU.

While it does have a blob for video and power both of those have no 
hardware code signing features (thus replaceable), and unlike ivy bridge 
it doesn't have a black box supervisor processor.


Had the folks from purism asked me what they should do, I would have 
suggested FT3.


On 10/09/2017 07:54 PM, Youness Alaoui wrote:


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?
In the efforts of not getting moderated again we can continue this off 
list but it boils down to the dishonest crowdfunding style "some day we 
will do X" marketing.


I would have recommended your devices at least once if you were selling 
them as they were instead of as they could be.


I dislike:
* Aspirational marketing "LibreM" "every chip hand selected to respect 
your privacy" "continued efforts to remove ME" that confuses even linux 
veterans and detracts from competitors products.

* The lobbying for the FSF to decrease the RYF standards
* (although most companies do this) Not asking the target audience for 
advice on what to do next.


I wouldn't have said anything but on the other lists I visit for every 
person like me there are 5 others who constantly talk up your products. 
I believe everyone needs critical voices.


On 10/09/2017 08:42 PM, Nico Huber wrote:


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.

Can you suggest a better way of saying it?

People with EE/CS degrees (non-laymen I suppose) I have conversed with 
over the years still consider "coreboot" to mean what it did circa 2011 
where the only real difference between coreboot and libre* was 
philosophical not technical, when someone says "our devices have 
coreboot" they believe that it is entirely "free firmware".


While an FSP coreboot "port" is still technically superior to an 
entirely closed source firmware no one I have talked to would consider 
spending an extra 1K per device just to cut the vendor out of the trust 
picture (they and I desire silicon init)



I propose a kind of freedom-level badge certification system (like 
"Intel Inside" stickers) for this situation with everything clearly 
explained on a central website to solve this situation, similar to the 
one currently on the coreboot wiki.


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

Re: [coreboot] greetings and laptop questions

[Nico Huber]

On 10.10.2017 20:02, Youness Alaoui wrote:
>> 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.
> 
> ...
> 3 - By stating that it "bothers honest people", right after saying
> that it doesn't bother me, you're implying that I'm not an honest
> person (at least that's how I read it) and that kind of statement
> doesn't lead to cool headed discussions, so I'll simply withdraw from
> this one.

Sorry for that. My last sentence probably doesn't even express what
I was trying to say. Could be my bad English. I just meant that there
are people who are easily offended by dishonesty. Well, yeah, it does
imply that I don't count you among them.

Nico

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

Re: [coreboot] greetings and laptop questions

[Rene Shuster]

I actually appreciated your super-long post, as it provided me insight in
the development process that I wasn't aware prior and it changed my view on
Puri.sm from 'they have been debunked' to 'I want to support their
efforts'. Keep up the good work.

On Tue, Oct 10, 2017 at 2:02 PM, Youness Alaoui <
kakar...@kakaroto.homelinux.net> wrote:

> > While I understand your frustration, and agree with the general thrust
> > of your email, and disregarding the "10 years", the Samsung Chromebook
> > Plus (and many other devices of similar age) beg to differ.
> > There are devices from 2016 and 2017 shipping with coreboot and no CPU
> > level blobs in the firmware (the only CPU side blob would be the
> > kernel's GPU driver).
>
> Sorry, I'm so deep into Intel stuff right now that I completely missed
> the possibility of non-x86 hardware. Yes, there is newer hardware with
> no blobs in coreboot, my statement is only true for intel-related
> hardware. I don't even know about AMD actually, but I believe it's a
> similar situation for AMD. But in the case of the Chromebook Plus, I
> checked, and it's an ARM based CPU, which is why coreboot is blob free
> for it.
> The original post was about a laptop to run virtual machines, so I
> assume x86 is a requirement, but my statement was about coreboot
> itself, not about the laptop requirement, which made it false. Thanks
> for the correction!
>
>
>
> >
> > Please keep the dimension right, newest is Ivy Bridge and that is 5
> > years old.
>
> My bad, you're right. The '10 years old' was in reference to ME-less
> CPU designs and I confused it with FSP-less coreboot.
> As for the ivybridge being the newest, that's again my bad, I used
> this to look up when the native intel raminit stopped being supported
> ;
> https://www.coreboot.org/Intel_Native_Raminit#Sandybridge.2FIvybridge
> and it said sandybridge/ivybridge, and I thought they were the same,
> not one being successor of the other.
>
> I guess that will teach me to email while I'm tired and busy/distracted.
>
>
>
> >
> >> 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).
>
> You're not hateful from what I could see. You disagree with Purism and
> you don't like it, but I haven't seen you jumping at every occasion to
> talk bad about it.
> As for our last discussion, that's what it was, a discussion, which
> unfortunately, I got a little over-verbose in my last response and
> killed the discussion, but I don't feel like Taiidan wants to discuss
> anything. Either way, I don't plan on opening any new discussions
> about Purism here.
>
> >
> >>
> >> 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.
>
> I disagree with your statement that it's false advertisement and that
> it's dishonest marketing. I won't explain why I think you're wrong
> here, because :
> 1 - I already explained it in length in my previous long email that
> you never read
> 2 - It doesn't market itself as "being super secure" as you said, but
> rather as being "security and privacy focused", which it is. You are
> free to find anywhere on the 

Re: [coreboot] greetings and laptop questions

[Youness Alaoui]

> While I understand your frustration, and agree with the general thrust
> of your email, and disregarding the "10 years", the Samsung Chromebook
> Plus (and many other devices of similar age) beg to differ.
> There are devices from 2016 and 2017 shipping with coreboot and no CPU
> level blobs in the firmware (the only CPU side blob would be the
> kernel's GPU driver).

Sorry, I'm so deep into Intel stuff right now that I completely missed
the possibility of non-x86 hardware. Yes, there is newer hardware with
no blobs in coreboot, my statement is only true for intel-related
hardware. I don't even know about AMD actually, but I believe it's a
similar situation for AMD. But in the case of the Chromebook Plus, I
checked, and it's an ARM based CPU, which is why coreboot is blob free
for it.
The original post was about a laptop to run virtual machines, so I
assume x86 is a requirement, but my statement was about coreboot
itself, not about the laptop requirement, which made it false. Thanks
for the correction!



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

My bad, you're right. The '10 years old' was in reference to ME-less
CPU designs and I confused it with FSP-less coreboot.
As for the ivybridge being the newest, that's again my bad, I used
this to look up when the native intel raminit stopped being supported
;
https://www.coreboot.org/Intel_Native_Raminit#Sandybridge.2FIvybridge
and it said sandybridge/ivybridge, and I thought they were the same,
not one being successor of the other.

I guess that will teach me to email while I'm tired and busy/distracted.



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

You're not hateful from what I could see. You disagree with Purism and
you don't like it, but I haven't seen you jumping at every occasion to
talk bad about it.
As for our last discussion, that's what it was, a discussion, which
unfortunately, I got a little over-verbose in my last response and
killed the discussion, but I don't feel like Taiidan wants to discuss
anything. Either way, I don't plan on opening any new discussions
about Purism here.

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

I disagree with your statement that it's false advertisement and that
it's dishonest marketing. I won't explain why I think you're wrong
here, because :
1 - I already explained it in length in my previous long email that
you never read
2 - It doesn't market itself as "being super secure" as you said, but
rather as being "security and privacy focused", which it is. You are
free to find anywhere on the website where it says security or privacy
without stating "a focus on" or "-focused" along with it.
2 - It's my opinion/interpretation and you have a different one, and
that's fine, you are entitled to it. Your view/interpretation of a
statement does not mean everyone needs to see it your way and that the
conclusion that it's being dishonest which your drew from it, is going
to be the absolute truth.
3 - By stating that it "bothers honest people", right after saying
that it doesn't bother me, you're implying that I'm 

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

[Zoran Stojsavljevic]

> Last time I was solving a problem of OS suspend-resume sequence with
modern kernels and now it is about working with old kernels

Hello Kostja,

What is modern kernel, and what is old kernel? Any version/revision
examples (you are using), so we can get the/some idea?

Thank you,
Zoran
___

On Tue, Oct 10, 2017 at 10:14 AM, Аладышев Константин 
wrote:

> Hello Zoran!
>
> Yes, I'm working with the same board, but the problem is different. Last
> time I was solving a problem of OS suspend-resume sequence with modern
> kernels and now it is about working with old kernels
>
> From: Zoran Stojsavljevic [mailto:zoran.stojsavlje...@gmail.com]
> Sent: Tuesday, October 10, 2017 9:48 AM
> To: Аладышев Константин
> Cc: coreboot
> Subject: Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards
>
> Hello Kostja,
> We already had this discussion a while ago, didn't we?
>
> https://mail.coreboot.org/pipermail/coreboot/2016-December/082772.html
>
> (BTW, ATOM BYT has exactly the same problem)
>
> 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
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

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

[Zoran Stojsavljevic]

> I'm going to try the hack to disable xhci, as suggested by Zoran and
Аладышев's earlier email.

You might try both variants. Do not forget, both ehci and xhci hubs are on
different clocking domains, so you can set only one at the time (no
workaround/circumventing tricks).

I would advise to try only with xhci first. And use only USBs 2.0. Should
work. Then you can also try vice versa.

Zoran

On Tue, Oct 10, 2017 at 3:44 PM, Trammell Hudson  wrote:

> On Mon, Oct 09, 2017 at 07:55:34PM -0700, Julius Werner wrote:
> > 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.
>
> Even with reversing the patch (modifying the ehci code to always
> read from the command register), my Haswell board still won't
> enumerate the USB devices.  I'm going to try the hack to disable
> xhci, as suggested by Zoran and Аладышев's earlier email.
>
> Likely unrelated, I'm also having a problem enabling ACPI from the Linux
> kernel, although most everything else seems to work with interrupts
> and PCIe, so for the time being I have a hack in acpi_enable to pretend
> things worked.
>
> [0.017031] ACPI: Core revision 20160831
> [0.264132] ACPI: 4 ACPI AML tables successfully acquired and loaded
> [0.271241] ACPI: setting ELCR to 0200 (from 0a00)
> [0.376881] ACPI Error: Hardware did not enter ACPI mode
> (20160831/evxfevnt-113)
> [0.385158] acpi_enable:114 faking ACPI mode
>
> https://github.com/osresearch/heads/issues/260
> https://github.com/osresearch/heads/issues/248
>
> --
> 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] OCP Winterfell, NERF, Linux and u-root (was: Ability to remotely debug the grub menu in case of boot failure)

[ron minnich]

Here's a bit more info.

NERF is the project I mentioned at the  coreboot meeting a few months back.

This is my linuxcon talk a few weeks back.
https://docs.google.com/presentation/d/1rz6ATJ6PNf_iJeDlqJvLqYZmyuJIN5SMli8halvyovY/edit?usp=sharing

HOWTO on the winterfell node, incomplete:
https://docs.google.com/document/d/1jtJ267pGxqWwEopNJsXzR1jOaOPAhulX_PaidKzlMI8/edit?usp=sharing

repos for current state of life: https://github.com/nerfirmware

Trammell's work is really interesting: https://github.com/osresearch
/heads/tree/nerf

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

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

[Trammell Hudson]

On Tue, Oct 10, 2017 at 02:44:02PM +, ron minnich wrote:
> [0.376881] ACPI Error: Hardware did not enter ACPI mode
> (20160831/evxfevnt-113)
> 
> is this the step where it tries to do an outb to 0xb2 to tell smm we are
> taking over?

Yes, it looks like it is attempting to write to 0xB2:

acpi_hw_write_port(acpi_gbl_FADT.smi_command,
(u32) acpi_gbl_FADT.acpi_enable, 8);

Which is in the FACP table:

[030h 0048   4] SMI Command Port : 00B2

Since there in no SMM right now, it looks like Linux would be happy if
that value were zero:

/*
 * ACPI 2.0 clarified that if SMI_CMD in FADT is zero,
 * system does not support mode transition.
 */
if (!acpi_gbl_FADT.smi_command) {
return_UINT32(ACPI_SYS_MODE_ACPI);
}

(this is getting a little further afield from the Haswell USB problems...)

-- 
Trammell

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

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

[ron minnich]

[0.376881] ACPI Error: Hardware did not enter ACPI mode
(20160831/evxfevnt-113)


is this the step where it tries to do an outb to 0xb2 to tell smm we are
taking over?
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Problems changing payload on Intel Leaf Hill

[Nico Huber]

Hi Tahnia,

On 10.10.2017 10:29, Tahnia Lichtenstein wrote:
> ...
> 
> Then I built this version of coreboot with a self-compiled payload, such as
> Tianocore UDK2017 CorebootPayloadPkg or SeaBIOS, using the .confg files
> provided by Intel for UEFI payloads or legacy payloads respectively (just
> modified for specific payload type and path, and disabling verified and
> measured boot). I stitched the coreboot output with the Intel-provided
> blobs using the exact same method as before. Then, in run-time, coreboot
> transitions to the payload and nothing happens from then on (i.e. no
> further serial debug messages, no change to display monitor).

you've only attached config files for your coreboot but not for the
payloads. It's hard to tell what output to expect without that (e.g.
do you have serial output enabled in your SeaBIOS build? if you let
the coreboot build environment configure SeaBIOS it is enabled expli-
citly). So with the current information you've provided, it could
just be that the payloads don't try to output anything on serial.

Output on a monitor is a little more complicated and depends on each
payload. SeaBIOS expects a Video BIOS to be present. This can either
be an option ROM from a gfx adapter card (looking at your logs, you
don't seem to have one), a Video BIOS file in CBFS matching the inte-
grated gfx adapter, or, in case coreboot already configured a frame-
buffer, a Video BIOS shim called SeaVGABIOS (aka. cbvga in this case,
it's a separate component in the SeaBIOS source).

Current CorebootPayloadPkg *should* be able to use a preconfigured
framebuffer. I never tried it, though, and there are reports that it
doesn't always work... It's generally possible that Intel's precom-
piled UEFI payload has it's own gfx driver (GOP) built in.

> ...
> Am I not specifying the correct configuration options for Tianocore and
> SeaBIOS? I.e. is there more to it than just selecting the payload type and
> specifying the payload path? Do I need to configure or update memory
> addresses or ranges to match payload sizes, or some such? Do I need to make
> specific changes to the payloads' source code to support the platform? Any
> advice on how/where to start debugging?

Usually there is nothing more to specify. The best option, IMO, is to
get one of the simpler payloads (SeaBIOS should do) to output on serial.
You can also test your SeaBIOS binary in QEMU to make sure it does out-
put something.

Hope that helps,
Nico

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

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

[Trammell Hudson]

On Mon, Oct 09, 2017 at 07:55:34PM -0700, Julius Werner wrote:
> 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.

Even with reversing the patch (modifying the ehci code to always
read from the command register), my Haswell board still won't
enumerate the USB devices.  I'm going to try the hack to disable
xhci, as suggested by Zoran and Аладышев's earlier email.

Likely unrelated, I'm also having a problem enabling ACPI from the Linux
kernel, although most everything else seems to work with interrupts
and PCIe, so for the time being I have a hack in acpi_enable to pretend
things worked.

[0.017031] ACPI: Core revision 20160831
[0.264132] ACPI: 4 ACPI AML tables successfully acquired and loaded
[0.271241] ACPI: setting ELCR to 0200 (from 0a00)
[0.376881] ACPI Error: Hardware did not enter ACPI mode 
(20160831/evxfevnt-113)
[0.385158] acpi_enable:114 faking ACPI mode

https://github.com/osresearch/heads/issues/260
https://github.com/osresearch/heads/issues/248

-- 
Trammell

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

Re: [coreboot] ECC2017: organized dinner on Thursday?

[Zaolin]

Hey,

I have already organized the Dinner for Thursday and Friday. ;)


Best Regards, Philipp

On 10.10.2017 10:46, Goetz Salzmann wrote:
> Dear list,
>
> looking at the ECC2017 Schedule there is an organized "Social Event" on
> Friday.  For Sat./Sun. we will probably have pizza in the hackcenter.
>
> But after the great experience with organized dinners during the
> EuroBSDCon 2017, I would like to ask someone from Bochum to
> organize a dinner on Thursday, please.
>
> Thanks,
> Goetz.
>
>




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] how to implement variable read/write variable in coreboot

[Felix Held]

Hi Nico!


I'm not sure how to use a per erase-block counter? When would it update?
we could only do that on every erase. A per variable counter might be
useful, but I still hope it will work without.
I was thinking of putting a number in the first word of a block. Every 
time a new block is allocated, this value is written once. The value 
is the highest number already used plus 1. Also beware of wraparounds 
there.
Maybe a better option would be to have a maybe 64bit field in the header 
of every erase-block that gets gets erased with the whole block and 
every time blocks are erased an additional bit will get written in the 
other erase blocks that contain valid data.
Your proposal to first mark an entry for update, then write the new 
entry and after that invalidate the old entry would solve this problem 
better though.



Updated scheme: With n erase blocks, the first n-1 blocks would be num-
bered 0..n-2. The last block would be the "spare block". The spare block
has a header (or footer, with size <= size of an entry's header) that
contains the number of another block (or 0x).
I wouldn't use a dedicated spare block, since that will be the block 
that wears out first, since every time the same block is used. Just use 
one of the blocks in the ring buffer for that; that also eliminates a 
special case. Just make sure that always at least one erase-block isn't 
used for data.



Updated write: Before each write, check if the spare block is marked
with another blocks number. If it is, find the first block with free
space and continue the defragmentation process at this point.

Defragmentation:

 Find duplicate entries and invalidate the ones added later
Hm, with using the older of the two entries, we make sure that we won't 
use an entry that isn't written completely. Good idea.



 Find the first block m with invalid entries
 Write m into the spare block's footer
 Copy all valid entries from m into the spare block
 (it will fit, because there was at least one invalidated entry in m)
 For i in m .. n-3
 Erase i
 For j in m+1 .. n-3
 Copy all valid entries from j that fit into i,
 invalidating each!
 End For
 End For
 Add back all entries from spare block, invalidating each
 Erase the spare block
My proposal would be doing the normal mark, update, invalidate routine 
until only one erase block is left unused after the current write. If 
less than at least a full erase-block would be left after a write, a 
garbage collection/defragmentation run has to be done. In this run the 
non-invalidated entries from the first/oldest block get written to the 
last empty block. Then the valid data of the next block gets written to 
the space that might be left in the block where the contents of the 
block that was processed before the current source block were written 
to; if there isn't enough space for an entry, the next erased block will 
be used. With this the whole ring buffer will be defragmented.
Sure, with another strategy the number of block erases could be further 
decreased, but the code should kept short and understandable; finding 
and fixing bugs that don't occur often isn't that fun.


To keep things simple, I'd also introduce the limitation that an entry 
mustn't be longer than the size of an erase-block.


Regards
Felix

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

[coreboot] ECC2017: organized dinner on Thursday?

[Goetz Salzmann]

Dear list,

looking at the ECC2017 Schedule there is an organized "Social Event" on
Friday.  For Sat./Sun. we will probably have pizza in the hackcenter.

But after the great experience with organized dinners during the
EuroBSDCon 2017, I would like to ask someone from Bochum to
organize a dinner on Thursday, please.

Thanks,
Goetz.


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

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

[Аладышев Константин]

Hello Zoran!

Yes, I'm working with the same board, but the problem is different. Last time I 
was solving a problem of OS suspend-resume sequence with modern kernels and now 
it is about working with old kernels

From: Zoran Stojsavljevic [mailto:zoran.stojsavlje...@gmail.com]
Sent: Tuesday, October 10, 2017 9:48 AM
To: Аладышев Константин
Cc: coreboot
Subject: Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards

Hello Kostja,
We already had this discussion a while ago, didn't we?

https://mail.coreboot.org/pipermail/coreboot/2016-December/082772.html

(BTW, ATOM BYT has exactly the same problem)

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



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

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

[Аладышев Константин]

I've dumped original ACPI tables from original BIOS, but I can't see any such 
hooks.

https://pastebin.com/Mniskv3f   part1 of dsdt
https://pastebin.com/hnpgvCMN   part2 of dsdt (starts from EHCI/XHCI 
controllers)
 
I hope it is not in SMM cause I really have no idea how to edit it to solve 
this problem

-Original Message-
From: jwer...@google.com [mailto:jwer...@google.com] On Behalf Of Julius Werner
Sent: Tuesday, October 10, 2017 5:56 AM
To: Аладышев Константин
Cc: Coreboot
Subject: Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards

> 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

[Patrick Georgi via coreboot]

Hi Youness,

2017-10-10 1:54 GMT+02:00 Youness Alaoui :
> 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).
While I understand your frustration, and agree with the general thrust
of your email, and disregarding the "10 years", the Samsung Chromebook
Plus (and many other devices of similar age) beg to differ.
There are devices from 2016 and 2017 shipping with coreboot and no CPU
level blobs in the firmware (the only CPU side blob would be the
kernel's GPU driver).


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

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

Re: [coreboot] how to implement variable read/write variable in coreboot

[Melissa Yi]

Thank you very much for all your advice, especially for Nico, Felix, Peter

Thanks.

Regards,
Melissa Yi

BIOS Lead Engineer
Celestica(Shanghai) R Center, China

www.celestica.com
Solid Partners, Flexible Solutions

2017-10-02 4:22 GMT+08:00 Felix Held :

> Hi Nico!
>
> The question I have here is what to do if there is more than one valid
>>> entry. Just using the first one introduces a bit of undetermined
>>> behavior (block order in the flash might be different after
>>> defragmentation).
>>>
>> No, always choosing the first would be determined behavior. In case we
>> keep things in order it's also the better choice when it comes to sear-
>> ching the current, valid entry (we'd have to always search the whole
>> used space for a newer version otherwise). I'd treat it like this: If
>> the old version wasn't invalidated, the update didn't finish. So we can
>> ignore the new version.
>>
> I was assuming the ring buffer case here where the first entry in the raw
> flash address space doesn't have to be the oldest one.
>
> So either use some counter (beware of overflows!) on
>>> either the flash erase block (small overhead and rather efficient) or
>>> the entry (full region has to be either cached or read every time and
>>> needs more bytes than the counter per erase block) or accept the
>>> possibility of undetermined behavior (IMHO not a good idea).
>>>
>> I'm not sure how to use a per erase-block counter? When would it update?
>> we could only do that on every erase. A per variable counter might be
>> useful, but I still hope it will work without.
>>
> I was thinking of putting a number in the first word of a block. Every
> time a new block is allocated, this value is written once. The value is the
> highest number already used plus 1. Also beware of wraparounds there.
>
> Might be done in a sanitation phase before each write. But if we define
>> the first entry to be the valid one, we probably don't need it. Update:
>> I didn't come around in my scheme below... maybe we should make the
>> update in three steps: tag for update, insert new value, invalidate.
>> This way we would only have to search for duplicates for valid entries
>> tagged for update.
>>
> Good idea.
>
> Defragmentation:
>>
> Haven't really looked at and thought about your defragmentation phase
> idea; maybe I'll comment on that next week.
>
> Regards
> Felix
>
>
> --
> 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

[Zoran Stojsavljevic]

Hello Kostja,

We already had this discussion a while ago, didn't we?

https://mail.coreboot.org/pipermail/coreboot/2016-December/082772.html

(BTW, ATOM BYT has exactly the same problem)

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