← Back to team overview

firmware-testing-team team mailing list archive

Re: Fwd: Re: Using FWTS for Certification

 

On 05/10/12 15:43, Chris Van Hoof wrote:
Seems like a good UDS topic, I've added it to the blueprint:

https://blueprints.launchpad.net/ubuntu/+spec/hardware-r-fwts-features

Brendan -- Will you be at UDS to talk through some of the issues you've
seen during Cert runs?
Hi Chris,

Sorry for the late reply - I hadn't been syncing this list. I'll be there in Copenhagen and would be happy to talk about this. The idea of profiles sounds good.

--chris

On 10/05/2012 06:09 AM, Alex Hung wrote:
I agree with Colin's viewpoints.

Profiles for different purposes (development cycle vs. certificate
cycle) seem to be a good way to solve this.

Cheers,
Alex Hung

On 10/05/2012 04:25 PM, Colin Ian King wrote:
I've been thinking a lot about this a lot while I'm currently in bed
fighting a bad case of shingles :-/

fwts was designed to catch firmware errors - from my perspective it was
a way to automate the kind of work I did in HWE to catch any problem
early in the enablement phase so we could get firmware fixed or detect
issues that we could fix in the kernel before we shipped a product. The
mind set to fwts is: "automatically spot potential errors and get them
fixed early".   Honestly, it looks *REALLY* poor if the kernel spews out
lots of warning and error messages on hardware that we've enabled.

This is a different use-case from what CERT requires.  The firmware is
not really fixable - the machine is already released and on the market
and firmware upgrades are less likely.

  From the enablement viewpoint, I wrote fwts to be pedantic so we can
spot specific issues (such as missing controls like _BQC) because the
kernel has to bodge and work around this features (it kind of works, but
is not ideal) and it is good to get these fixed in firmware if we can.
This is obviously not the case in the certification phase.

Some issues are marked "CRITICAL" such as _OSC as it most probably (or
though possibly not) may lead to a poor configuration (e.g. poor power
configuration) and it requires an engineer to look at.  We don't want to
fail energy star compliance tests do we? :-)

So, I think once you understand that fwts was designed to catch
potential poorly written firmware issues so that can be investigated and
fixed you can see that design feature does not match the requirements of
certification.   I suspect we may need to add a profile setting to fwts
so it can be used for different use-cases.

Anyhow, that's just my view.  Others may disagree. I'm very happy to
discuss this and thrash out some kind of workable solution.

Colin

_______________________________________________
Mailing list: https://launchpad.net/~firmware-testing-team
Post to     : firmware-testing-team@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~firmware-testing-team
More help   : https://help.launchpad.net/ListHelp


_______________________________________________
Mailing list: https://launchpad.net/~firmware-testing-team
Post to     : firmware-testing-team@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~firmware-testing-team
More help   : https://help.launchpad.net/ListHelp


_______________________________________________
Mailing list: https://launchpad.net/~firmware-testing-team
Post to     : firmware-testing-team@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~firmware-testing-team
More help   : https://help.launchpad.net/ListHelp




Follow ups

References