[coreboot] Re: Revoke of Gerrit privileges and asking to fork (was: Gerrit etiquette)

[David Hendricks via coreboot]

Hi Paul,

> [Your plain text email part of the mail is strangely indented.]

Thanks for pointing that out. I use my coreboot.org e-mail address sparingly 
and it seems there were some minor issues in how I was using the webmail 
client. Let's see if this message shows up better...

> 1. Who is the current coreboot leadership? How many of those voted, and
> what was the result?

It's currently Stefan, Werner, and myself. When things blew up in the patch you 
cited we started an e-mail thread to discuss what was to be done, and we agreed 
that rules/guidelines need to be enforced.

We tried to reach a consensus quickly, taking into account timezone 
differences, then discussed the issue in the leadership meeting on Jan. 29 and 
followed-up with an e-mail to the list (a poorly formatted one - sorry).

The project structure was put into place when coreboot joined the Software 
Freedom Conservancy, and is described in the following PDF (note: I stepped in 
when Marc Jones withdrew): 
https://www.coreboot.org/images/b/b4/Coreboot_and_the_Software_Freedom_Conservancy.pdf


> 2. Which comment violated the guidelines? I guess it’s about change-set
> [2]? Reading the comments, and considering, that English is not the
> mother tongue of some participants, and reading an apology, I’d really
> like to know what Gerrit guide lines were violated.
> 
> 3. Why did the coreboot leadership not step in earlier to avoid further
> escalation despite being added early on as reviewer so was made aware of
> the discussion?

Although the patch is what spurred action in this case, what happened was the 
result of tensions that had built up over several months. I think this is 
generally true of past incidents as well - Frustration builds and people 
eventually burn out or lose their temper.

coreboot is a highly active project and we have a large, global community. It 
is practically impossible for a small handful of people with day jobs to 
monitor every interaction and Gerrit comment.

That said, there is room for improvement in our guidelines and earlier 
intervention. We obviously don't like losing developers, so waiting for things 
to explode is not a viable path forward. I hope we can reach a better 
understanding of the underlying issues and develop guidelines to avoid the 
build-up of tensions we saw here. The "Workflows and Guidelines" thread is a 
good start.

> Hopefully, there will be an amicable outcome nevertheless.

For sure! If this were about some troll who just showed up then dealing with 
the problem and moving on would be easy. Dealing with the fallout in this case 
will take a lot more time and effort but I hope we can eventually be whole 
again.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

Re: [coreboot] SMBIOS table enablement in coreboot

[David Hendricks via coreboot]

Hi Mayuri,

On Sun, Jan 15, 2017 at 5:40 PM, Mayuri Tendulkar <
mayuri.tendul...@aricent.com> wrote:

> Hi David
>
>
>
> Yes, below are settings for our system. As we are using Intel Baytrail,
> does this SMBIOS manufacturer shd be Intel?
>

That's up to you. Mainboard manufacturer, along with product name, serial
number, and version, are strings which are expected to be assigned by the
vendor. You may set these in your mainboard's Kconfig file. The Macbook 2.1
port shows an example of how to do this:
https://review.coreboot.org/cgit/coreboot.git/tree/src/mainboard/apple/macbook21/Kconfig#n32
.

Other SMBIOS tables such as memory info is generated automatically by
coreboot. For example, the type 4 table should have details about your
processor manufacturer (Intel) as well as information which implies
Baytrail (CPU family, model, and stepping).


>
>
> CONFIG_MAINBOARD_SMBIOS_MANUFACTURER="x"
>
> # CONFIG_SMBIOS_PROVIDED_BY_MOBO is not set
>
> CONFIG_GENERATE_SMBIOS_TABLES=y
>
> CONFIG_MAINBOARD_SMBIOS_PRODUCT_NAME=""
>
>
>
> Regards
>
> Mayuri
>
>
>
> *From:* David Hendricks [mailto:dhend...@google.com]
> *Sent:* 14 January 2017 08:19
> *To:* Mayuri Tendulkar 
> *Cc:* coreboot 
> *Subject:* Re: [coreboot] SMBIOS table enablement in coreboot
>
>
>
> Hi Mayuri,
>
> Do you have GENERATE_SMBIOS_TABLES enabled in your config?
>
>
>
> On Fri, Jan 13, 2017 at 12:56 AM, Mayuri Tendulkar <
> mayuri.tendul...@aricent.com> wrote:
>
> Hi
>
> We are using coreboot for our board based on Intel Baytrail 3845.
>
>
>
> When we use *dmidecode –t *to get DDR details, we get empty. It means
> data is missing in SMBIOS.
>
>
>
> Are there any settings in coreboot to enable this?
>
>
>
> Regards
>
> Mayuri
>
> "DISCLAIMER: This message is proprietary to Aricent and is intended solely
> for the use of the individual to whom it is addressed. It may contain
> privileged or confidential information and should not be circulated or used
> for any purpose other than for what it is intended. If you have received
> this message in error, please notify the originator immediately. If you are
> not the intended recipient, you are notified that you are strictly
> prohibited from using, copying, altering, or disclosing the contents of
> this message. Aricent accepts no responsibility for loss or damage arising
> from the use of the information transmitted by this email including damage
> from virus."
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
>
>
>
>
> --
>
> David Hendricks (dhendrix)
> Systems Software Engineer, Google Inc.
> "DISCLAIMER: This message is proprietary to Aricent and is intended solely
> for the use of the individual to whom it is addressed. It may contain
> privileged or confidential information and should not be circulated or used
> for any purpose other than for what it is intended. If you have received
> this message in error, please notify the originator immediately. If you are
> not the intended recipient, you are notified that you are strictly
> prohibited from using, copying, altering, or disclosing the contents of
> this message. Aricent accepts no responsibility for loss or damage arising
> from the use of the information transmitted by this email including damage
> from virus."
>



-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] SMBIOS table enablement in coreboot

[David Hendricks via coreboot]

Hi Mayuri,
Do you have GENERATE_SMBIOS_TABLES enabled in your config?

On Fri, Jan 13, 2017 at 12:56 AM, Mayuri Tendulkar <
mayuri.tendul...@aricent.com> wrote:

> Hi
>
> We are using coreboot for our board based on Intel Baytrail 3845.
>
>
>
> When we use *dmidecode –t *to get DDR details, we get empty. It means
> data is missing in SMBIOS.
>
>
>
> Are there any settings in coreboot to enable this?
>
>
>
> Regards
>
> Mayuri
> "DISCLAIMER: This message is proprietary to Aricent and is intended solely
> for the use of the individual to whom it is addressed. It may contain
> privileged or confidential information and should not be circulated or used
> for any purpose other than for what it is intended. If you have received
> this message in error, please notify the originator immediately. If you are
> not the intended recipient, you are notified that you are strictly
> prohibited from using, copying, altering, or disclosing the contents of
> this message. Aricent accepts no responsibility for loss or damage arising
> from the use of the information transmitted by this email including damage
> from virus."
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>



-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] new problem with KGPE-d16

[David Hendricks via coreboot]

Iru had a similar problem very recently:
https://www.coreboot.org/pipermail/coreboot/2017-January/082806.html

Iru - Were you able to resolve the issue you saw?

On Mon, Jan 9, 2017 at 2:13 PM, ron minnich  wrote:
> what's weird is coreboot is unchanged, just the payload.
>
> I am wondering if anyone recognizes this
>
> IMD small region:
>   IMD ROOT0. bfffec00 0400
>   ROMSTAGE1. bfffebe0 0004
>   GDT 2. bfffe9e0 0200
> Writing AMD DCT configuration to Flash
> CBFS: 'Master Header Locator' located CBFS at [100:c0)
> CBFS: Locating 's3nv'
> CBFS: Found @ offset 2fec0 size 1
> Manufacturer: ef
> SF: Detected W25Q128 with sector size 0x1000, total 0x100
> FCH SPI: Too much to write. Does your SPI chip driver use spi_crop_chunk()?
> SF: Failed to send command 06: 1
> FCH SPI: Too much to write. Does your SPI chip driver use spi_crop_chunk()?
> SF: Failed to send command 06: 1
>
> Also ... "Too much to write" ... I'll submit a CL but, folks, "Too much to
> write"? How about some numbers on this kind of message :-)
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot



-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.

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

Re: [coreboot] Trusting coreboot versus trusting the FSP

[David Hendricks via coreboot]

On Mon, Jan 9, 2017 at 11:30 AM, Nico Huber  wrote:
> Without pro-
> per, public documentation and the promise by the vendor that this docu-
> mentation is correct _and_ comprehensive, we can't tell anything about
> the state of the hardware...
>
> beside the RAM contents and the program we are executing. And this is
> where coreboot does a much better job, IMO. Given that most host firm-
> ware stays active during runtime of the OS, I don't see any point in
> running open-source software for security reasons if there's proprie-
> tary software running on the same CPU in a higher privilege level.

And at the very least we can verify that the blobs are what we
think they are ("good enough" if we can trust the blob's origin) and
maintain some semblance of control in privileged mode.

Obviously full documentation and source are best. But in our imperfect
world with blobs I think the more relevant question to ask is what can
be done before and after the blobs are run. Being able to build a full
image with coreboot gives us some options, and having a relatively
simple codebase with a decent eyeball-to-code ratio helps. As Nico
said it's pointless to run OSS for security if the best you can do is
run in less privileged mode with proprietary software in full control.

-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.

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

Re: [coreboot] Flag value update

[David Hendricks via coreboot]

On Wed, Dec 28, 2016 at 10:35 AM, Samuthira Pandian T <
samuthir...@aricent.com> wrote:

> Hi Team,
>
>I need to pass some debug parameter value from coreboot
> (romstage.c) file to grub configuration. Actually i need to set some flag
> in coreboot and need to read it from grub.cfg file. Is there any way to
> pass some parameters from coreboot to grub. If so, kindly let me know for
> the procedure.
>

It appears grub has some support for cbmem (the cbmemc command).

You can also add a cbmem entry for your debug parameter and pass it up the
stack. Here  is a
recent example of how to do that.

-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] spd binaries

[David Hendricks via coreboot]

On Fri, Dec 16, 2016 at 11:01 AM, Pok Gu  wrote:

> Thaiphoon Burne is the most popular and probably the only tool for
> modifying the spd.bin. It has many built-in templates and you only need to
> select the speed, clocking, and voltage you like (e.g., DDR3-1688/DDR3-1333
> and CL10/CL11 and 1.35V/1.5V) and it will do all the rest calculations and
> generate the spd.bin for you. Then, the only thing you need to do is to
> flash the spd.bin to the spd chip on the ram, and reboot, and your ram
> stick is overclocked.
>
> Unfortunately, it is only available on Windows. So I have one harddisk
> loaded with Windows 7 and Thaiphoon Burne specialized for this work.
>
> I haven't found any linux software can do this unless you calculate and
> modify the spd.bin by hand. (If anyone found one let me know)
>

Cool - I never knew about that tool. Seems like a good investment if the
goal is to generate an spd.bin from scratch.

Sebastien - What are you trying to do, exactly? If you only need to change
one or two parameters, then a hex editor and a calculator should be
sufficient. The relevant specification for SPDs is JEDEC Standard No. 21-C
Annex K for DDR3 and Annex L for DDR4. (you'll need to register with
jedec.org to download the specs)

-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Anyone have a experence the u-boot on coreboot?(Rangeley platform)

[David Hendricks via coreboot]

Yep, probably more relevant to the U-Boot mailing list but nice to see it
here as well!

On Thu, Dec 1, 2016 at 11:43 PM, Yaroslav K.  wrote:

> Hello!
>
> I'm successfully using U-boot with Coreboot on the Rangeley platform
> with the attached dts file. I'm not sure if everything in it is needed
> and/or correct, but it works fine.
> serial1.dtsi was needed so that the second UART is used as stdout.
>
> Although, this question looks like more relevant to the U-boot mailing
> list than the Coreboot one.
>
> --
> Yaroslav
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>



-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFC] Explicitly use C89 (was: Setting C99 by default)

[David Hendricks via coreboot]

On Tue, Nov 29, 2016 at 1:40 PM, Stefan Tauner <
stefan.tau...@alumni.tuwien.ac.at> wrote:

> On Tue, 29 Nov 2016 09:09:48 +0100
> Gerd Hoffmann  wrote:
>
> > On Di, 2016-11-29 at 00:41 +0100, Stefan Tauner wrote:
> > > Paul can you please - without looking it up - name two new features of
> > > C99 compared to C89?
> >
> > Named initializers.
> > That alone is reason enough to prefer c99 over c89 IMHO.
>
> You are not Paul. I was asking him specifically because I don't think
> that he could name them but still tries to argue about such things
> although he is not proficient enough to evaluate the implications of
> such decisions (and I can't stand that at all). Even with good
> intentions this is a dangerous approach on improving code quality and
> needs to be countered.
>

I prefer Julius's approach of giving a detailed explanation that people
reading the list can actually learn from.

-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Rettungsboot

[David Hendricks via coreboot]

On Mon, Nov 28, 2016 at 12:40 PM, Peter Stuge <pe...@stuge.se> wrote:

> David Hendricks via coreboot wrote:
> > On Sun, Nov 27, 2016 at 8:28 PM, ron minnich <rminn...@gmail.com> wrote:
> > > I like the idea of JSON file
> >
> > Now we're talkin' - A standardized data format that is human
> > readable/writeable that can be easily parsed and generated using
> > small libraries.
>
> I agree with the concept as described by David, but strongly disagree
> with choosing JSON. I think we can and should do better than that.
>

That was my initial reaction as well. But if you check out some examples it
really doesn't seem bad especially if we restrict ourselves to a subset of
JSON. Here's a simple example using key:value pairs (from
http://www.w3schools.com/js/js_json_intro.asp):
{"employees":[
{"firstName":"John", "lastName":"Doe"},
{"firstName":"Anna", "lastName":"Smith"},
{"firstName":"Peter", "lastName":"Jones"}
]}

The page for jsmn notes that it explicitly does not support "advanced"
functionality that does not map well to C. I'm not sure exactly what this
implies (presumably the above example is OK), but it seems worth
investigating if it suits our needs and enables us to use existing
standards and libraries.

Ron - If you get a chance, can you post a sample JSON file from u-root?

> given that CMOS might not exist on a particular platform
> > (especially in the non-x86 world)
>
> Maybe no NVRAM, but surely there will be persistent storage on board?
>

Implementation-defined. I'm sure it exists on some designs, but in general
non-x86 board vendors don't add additional nonvolatile storage unless they
really have a specific purpose for it. Even if they add a serial EEPROM or
some such, it's not necessarily trivial to access like CMOS on x86
platforms. IMO the only persistent storage we can depend upon is the
persistent storage that coreboot resides on. Everything else is nice to
have but should not be a hard requirement.

I suppose this could be another parameter exposed in the config file in
CBFS. For example, if a key "nonvolatile-storage" has value "cmos" then the
tools know we need to look at cmos.layout and write boot device priority
using CMOS-methods. We currently do something similar to this on ChromeOS
devices to tell where verified boot data is stored (CMOS, embedded
controller, SPI ROM, etc).

-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Rettungsboot

[David Hendricks via coreboot]

On Sun, Nov 27, 2016 at 8:28 PM, ron minnich  wrote:

> yeah, david and nico both make very good points. I like the idea of  JSON
> file, and further we're working on a Go program
> on the u-root project that would parse said file (trivial in Go to parse
> JSON, it's one statement and blam! your Go struct is all
> filled in) and then decide what to configure/what to download/how to
> validate (we have a gpgv command written in Go by
> Eric Grosse) and then how to kexec it.
>
> I think what we're doing might be useful?
>

Now we're talkin' - A standardized data format that is human
readable/writeable that can be easily parsed and generated using small
libraries. It looks like Go can already handle it easily, for C we could
maybe use JSMN (http://zserge.com/jsmn.html) or something similar. I think
that addresses Nico's first point.

For the other points, I imagine we'd have two varieties of the JSON file.
One would be generated along with the payload and included as a CBFS file
to specify things like capabilities and bootable device priority*. The
other would be on the bootable media and specify things like the kernel
path and parameters. A tool which is used to generate the latter would
verify the capabilities and warn the user if their coreboot payload lacks
support for something.

*Stuff like boot device priority might need some more thought since CMOS
may be a preferable way of controlling something like that. However given
that CMOS might not exist on a particular platform (especially in the
non-x86 world) replacing the config file in CBFS file might not be a bad
way to go.

-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Microcode.bin question ?

[David Hendricks via coreboot]

On Tue, Oct 25, 2016 at 4:29 PM, Riko Ho  wrote:

> Hi Martin,
>
> Do you mean the value of CONFIG_USE_BLOBS inside .config file ?
>

Yes.

What's the option name one 'make menuconfig' ?
>

Search for it using '/' (like in vi).

-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFC] Deciding on style for multi-line comments

[David Hendricks via coreboot]

So it looks like we're pretty much all in agreement with 1-line and >=3
line comments. My only real concern is if "--ignore BLOCK_COMMENT_STYLE" in
the patch removes the check for the long comments, though I confess to
being ignorant of how checkpatch works.

To chip in my own $0.02 on the 2-line comment discussion: IMO they should
use the same form as 1-line comments so that we have exactly one form for
short comments one form for long comments.


On Fri, Aug 26, 2016 at 2:40 PM, Nico Huber  wrote:

> On 26.08.2016 17:56, Vadim Bendebury wrote:
> > I actually tend to agree with Julius that it does not make sense to
> waste 4
> > lines for a two line comment.  So, ideally the tool should be enforcing
> the
> > verbose style for comments longer than say 2 lines.
>
> Well, I too prefer the concise style for shorter comments. But I
> wouldn't enforce a number of lines. Maybe just say it's allowed for
> single-paragraph comments?
>
> And thanks, Julius, for bringing up the readability. This is what we
> should focus on. Actually I think a verbose-style comment shouldn't be
> allowed between code lines. That's something for longer explanations
> like a function description.
>
> But I'm really with Linus when it comes to the leading, single asterisk.
> It looks totally weird, IMHO
>
>   /* A small, concise comment
>  that doesn't fit a single line */
>
> is easier for the eye than
>
>   /* A small, concise comment
>* that doesn't fit a single line */
>
> where your eyes somehow stick on the asterisk first and then have to
> search for the real start of the line.
>
> I wouldn't go as far as changing current code, but enforcing a style
> (we can agree on) for new code might prevent future discussions.
>
> Nico
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>



-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] How to build coreboot with alternate toolchain?

[David Hendricks via coreboot]

Hi Paul,
Do you have multiple versions of GCC installed? You might need to use
"update-alternatives" to manage them. I haven't done so with Debian, but
this page seems to have a pretty good explanation:
http://lektiondestages.blogspot.com/2013/05/installing-and-switching-gccg-versions.html

-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Does ChromeOS-EC have to boot ChromeOS?

[David Hendricks via coreboot]

On Tue, Apr 26, 2016 at 12:20 AM, Zheng Bao  wrote:

> 
> 
> https://chromium.googlesource.com/chromiumos/platform/ec
>
> Hi, Stafan & All,
> I am trying to build a platform which uses AMD APU + EC.
>
> My goal is let EC
> 1. give the power sequencing logic to APU
> 2. play as a generic EC which has features like keyboard, UART.
>
> Currently, I don't have plan to boot chrome OS yet.
>
> So I need you guys give me some advice.
> Does chromeOS-EC meet my requirement?
>

Yes, it should. However there is only support for a limited number of ECs.

Is it OK if I don't boot chromeOS?
>

Yes. Most of the verified boot logic is in the host firmware
(coreboot/depthcharge).

Is chromeOS-EC hard to master?
>

I'd say it's moderately difficult, but not bad. The mess of config #defines
can be frustrating (ctags and grep are infinitely useful) but the design
makes sense for something that is optimized for minimal code size and
reusability among different ECs.

I don't know how easy/difficult it is compared to other EC firmwares. I
suggest using ctags to walk thru the initialization code in common/main.c
to see how initialization is done, and also choose a specific board (with
your preferred EC) to study how GPIOs, interrupts, tasks, hooks, etc. are
used.

Try posting to chromium-os-...@chromium.org. There are several EC
developers who read that list and can answer questions.

-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Coreboot on BeagleBone Black

[David Hendricks via coreboot]

We started on that a few years ago, but ran out of time and abandoned the
effort. There are still patches from Sept/Oct 2013 on Gerrit if you are
interested. Look for "beaglebone" and "am335x" patches by Gabe Black.

The Cubieboard is another dev board you might want to look into. The
patches are merged, and I believe the author had it booting Linux.

On Fri, Mar 25, 2016 at 4:05 PM, daoud yessine 
wrote:

> hi
>
> Does coreboot work on beaglebone Black ?
> How tried It ?
>
> ᐧ
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>



-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [GSoC 2016] Proposal review

[David Hendricks via coreboot]

On Thu, Mar 17, 2016 at 1:39 PM, Yurii Shevtsov  wrote:

> Hello. Three days passed, but unfortunately I haven't got any feedback on
> my draft yet.
>

If you make the doc public then you might get more responses.

Martin and Ron are both very busy people and might simply have been too
busy with work this week.

GSOC is all about open source coding and community engagement. Keeping your
doc private is not a good way to start...


> Although, I can see Martin Roth is watching my proposal. Also I'm still
> not assigned to any task. Spare me some time, please :-)
> Thanks in advance
>
> 2016-03-14 23:11 GMT+02:00 Yurii Shevtsov :
>
>> I know we haven't discussed project properly yet, and I understand my
>> vision of project may vary from yours. So feel free to point me on a right
>> way :-)
>> Here is the link:
>>
>> https://docs.google.com/document/d/1OWOYfKMUSZTi4tTHmGIIY27KAbM5MJVV0DdirjpB2As/edit?usp=sharing
>>
>> I made my proposal draft private. As for now I shared it with Ron Minnich
>> and Martin Roth. If you part of a GSoC commission, I'll add you too (head
>> to the doc link).
>>
>> Unfortunately, I haven't submitted any patch yet. Please, assign me to a
>> task.
>>
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>



-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] questions about veyron boards and the rk3288

[David Hendricks via coreboot]

On Tue, Nov 17, 2015 at 3:51 PM, Anthony Martin  wrote:

> 1. Is veyron_mickey the ASUS Chromebit CS10?
>

Yes.


> 2. Are any of the veyron_(danger|rialto|emile) products released yet?
>

No, but there are many Chromebooks which use the RK3288 and are available
in retail stores now.

-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] SPD CRC failed

[David Hendricks via coreboot]

On Wed, May 20, 2015 at 1:13 PM, Michael Gerlach n...@terminal21.de wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 I forgot to mention that somehow the ram frequency is not detected
 correctly...

  PLL busy...done
 PLL didn't lock. Retrying at lower frequency
  PLL busy...done
 PLL didn't lock. Retrying at lower frequency
  PLL busy...done
 PLL didn't lock. Retrying at lower frequency
  PLL busy...done
 PLL didn't lock. Retrying at lower frequency
 No lock frequency found


The SPD data should be read via SMBus long before PLL locking for the DRAM
itself takes place.

If you're unable to successfully read the SPDs, then it makes sense that
later init would fail.

-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] coreboot fails to build in master tree

[David Hendricks via coreboot]

Hi Timothy,
We were unable to replicate the failure you're seeing, however it did
appear that there may be an issue with the builder's environment. There
were also some patches that appeared to be committed in the wrong order,
thus causing a missing header error, but there were no merge conflicts and
after all the patches were merged things were fine. Sol uploaded a dummy
patch and the coreboot-gerrit builder had no trouble with it.

Do you have more details about the environment in which you're seeing this
failure?


On Fri, May 8, 2015 at 3:58 PM, Timothy Pearson 
tpear...@raptorengineeringinc.com wrote:

 All,

 Earlier today the master coreboot tree broke; it now fails to build:

 fmd_scanner.l: In function ‘parse_integer’:
 fmd_scanner.l:47:25: error: declaration of ‘input’ shadows a global
 declaration [-Werror=shadow]
 stdout:1192:16: error: shadowed declaration is here [-Werror=shadow]
 fmd_scanner.l: In function ‘copy_string’:
 fmd_scanner.l:74:29: error: declaration of ‘input’ shadows a global
 declaration [-Werror=shadow]
 stdout:1192:16: error: shadowed declaration is here [-Werror=shadow]
 cc1: all warnings being treated as errors
 make: *** [build/util/cbfstool/fmd_scanner.o] Error 1

 I propose the faulty patches be reverted until they can be repaired, as
 the failure in master is currently blocking any upstreaming efforts.

 Thanks!

 --
 Timothy Pearson
 Raptor Engineering
 +1 (415) 727-8645
 http://www.raptorengineeringinc.com

 --
 coreboot mailing list: coreboot@coreboot.org
 http://www.coreboot.org/mailman/listinfo/coreboot




-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Will coreboot work on my machine?

[David Hendricks via coreboot]

Seems like it might work, if you are willing to put in the time and effort
to attempt a port. The VX800 and Nano are already supported in coreboot.
The EC will be the tricky part, since I don't think any other Coreboot
supported laptop uses it.

On Fri, Apr 10, 2015 at 9:26 PM, camrodger...@gmail.com wrote:

 Lenovo IdeaPad S12
 VIA Nano processor U2250 (1.6GHz Capable)
 http://www.via.com.tw/en/products/chipsets/v-series/vx800/

 lspci -tvnn:

 -[:00]-+-00.0  VIA Technologies, Inc. VX800 Host Bridge [1106:0353]
+-00.1  VIA Technologies, Inc. VX800/VX820 Error Reporting
 [1106:1353]
+-00.2  VIA Technologies, Inc. VX800/VX820 Host Bus Control
 [1106:2353]
+-00.3  VIA Technologies, Inc. VX800 PCI to PCI Bridge
 [1106:3353]
+-00.4  VIA Technologies, Inc. VX800/VX820 Power Management
 Control [1106:4353]
+-00.5  VIA Technologies, Inc. VX800/VX820 APIC and Central
 Traffic Control [1106:5353]
+-00.6  VIA Technologies, Inc. VX800/VX820 Scratch Registers
 [1106:6353]
+-00.7  VIA Technologies, Inc. VX800/VX820 North-South Module
 Interface Control [1106:7353]
+-01.0  VIA Technologies, Inc. VX800/VX820 Chrome 9 HC3
 Integrated Graphics [1106:1122]
+-02.0-[01]00.0  Broadcom Corporation NetLink BCM5906M Fast
 Ethernet PCI Express [14e4:1713]
+-03.0-[02]00.0  Intel Corporation PRO/Wireless 5100 AGN
 [Shiloh] Network Connection [8086:4237]
+-03.1-[03-05]--
+-0d.0  VIA Technologies, Inc. Secure Digital Memory Card
 Controller [1106:9530]
+-0f.0  VIA Technologies, Inc. VX800 Serial ATA and EIDE
 Controller [1106:5324]
+-10.0  VIA Technologies, Inc. VT82x UHCI USB 1.1
 Controller [1106:3038]
+-10.1  VIA Technologies, Inc. VT82x UHCI USB 1.1
 Controller [1106:3038]
+-10.2  VIA Technologies, Inc. VT82x UHCI USB 1.1
 Controller [1106:3038]
+-10.4  VIA Technologies, Inc. USB 2.0 [1106:3104]
+-11.0  VIA Technologies, Inc. VX800/VX820 Bus Control and
 Power Management [1106:8353]
+-11.7  VIA Technologies, Inc. VX8xx South-North Module
 Interface Control [1106:a353]
+-13.0-[06]--
\-14.0  VIA Technologies, Inc. VT8237A/VT8251 HDA Controller
 [1106:3288]

 superiotool -dV:

 superiotool r
 Probing for ALi Super I/O at 0x3f0...
   Failed. Returned data: id=0x, rev=0xff
 Probing for ALi Super I/O at 0x370...
   Failed. Returned data: id=0x, rev=0xff
 Probing for Fintek Super I/O at 0x2e...
   Failed. Returned data: vid=0x, id=0x
 Probing for Fintek Super I/O at 0x4e...
   Failed. Returned data: vid=0x, id=0x11fc
 Probing for Fintek Super I/O at 0x2e...
   Failed. Returned data: vid=0x, id=0x
 Probing for Fintek Super I/O at 0x4e...
   Failed. Returned data: vid=0x, id=0x11fc
 Probing for ITE Super I/O (init=standard) at 0x20e...
   Failed. Returned data: id=0x, rev=0xf
 Probing for ITE Super I/O (init=it8502e) at 0x20e...
   Failed. Returned data: id=0x, rev=0xf
 Probing for ITE Super I/O (init=it8761e) at 0x20e...
   Failed. Returned data: id=0x, rev=0xf
 Probing for ITE Super I/O (init=it8228e) at 0x20e...
   Failed. Returned data: id=0x, rev=0xf
 Probing for ITE Super I/O (init=0x87,0x87) at 0x20e...
   Failed. Returned data: id=0x, rev=0xf
 Probing for ITE Super I/O (init=standard) at 0x25e...
   Failed. Returned data: id=0x, rev=0xf
 Probing for ITE Super I/O (init=it8502e) at 0x25e...
   Failed. Returned data: id=0x, rev=0xf
 Probing for ITE Super I/O (init=it8761e) at 0x25e...
   Failed. Returned data: id=0x, rev=0xf
 Probing for ITE Super I/O (init=it8228e) at 0x25e...
   Failed. Returned data: id=0x, rev=0xf
 Probing for ITE Super I/O (init=0x87,0x87) at 0x25e...
   Failed. Returned data: id=0x, rev=0xf
 Probing for ITE Super I/O (init=standard) at 0x2e...
   Failed. Returned data: id=0x, rev=0xf
 Probing for ITE Super I/O (init=it8502e) at 0x2e...
   Failed. Returned data: id=0x, rev=0xf
 Probing for ITE Super I/O (init=it8761e) at 0x2e...
   Failed. Returned data: id=0x, rev=0xf
 Probing for ITE Super I/O (init=it8228e) at 0x2e...
   Failed. Returned data: id=0x, rev=0xf
 Probing for ITE Super I/O (init=0x87,0x87) at 0x2e...
   Failed. Returned data: id=0x, rev=0xf
 Probing for ITE Super I/O (init=standard) at 0x4e...
   Failed. Returned data: id=0xfc11, rev=0x0
 Probing for ITE Super I/O (init=it8502e) at 0x4e...
   Failed. Returned data: id=0xfc11, rev=0x0
 Probing for ITE Super I/O (init=it8761e) at 0x4e...
   Failed. Returned data: id=0xfc11, rev=0x0
 Probing for ITE Super I/O (init=it8228e) at 0x4e...
   Failed. Returned data: id=0xfc11, rev=0x0
 Probing for ITE Super I/O (init=0x87,0x87) at 0x4e...
   Failed. Returned data: id=0xfc11, rev=0x0
 Probing for ITE Super I/O (init=legacy/it8661f) at 0x370...
   Failed. Returned data: id=0x, rev=0xf
 

Re: [coreboot] Booting Windows 8 failed

[David Hendricks via coreboot]

[+seabios, coreboot -- bcc]

On Mon, Mar 23, 2015 at 7:27 PM, Bao, Zheng zheng@amd.com wrote:

 I am porting the coreboot to a platform with a new AMD APU, which is close
 to Kabini and Mullins.
 Now the board can boot Ubuntu and Windows 7. But it failed to boot Windows
 8.
 It crashes at a very early stage, which seems to be Windows bootloader.
 The debug message of SeaBIOS is attached.

 The interrupt routine installed by SeaBIOS still work. We can see
 handle_13, handle_08, handle_1a are called once in a while.
 There is no BSOD. There is only a windows logo on the monitor, without
 progress ring of Windows 8.
 Even the debug version of windows 8 doesn't help, because it crashes
 before the image is loaded.

 Is there any more way to debug windows 8 bootloader?

 Zheng


 serial output
 -
 ...
 ...
 handle_08
 enter handle_15:
a=e820  b=0006  c=0018  d=534d4150 ds= es=3004 ss=9000
   si= di= bp= sp=ffd6 cs=2000 ip=0a25  f=0256
 enter handle_13:
a=4200  b=  c=  d=0080 ds=3024 es= ss=9000
   si= di= bp= sp=ffd6 cs=2000 ip=0a1d  f=0256
 disk_op d=0x000f98e0 lba=0 buf=0x0003 count=1 cmd=2
 AHCI/0: send cmd ...
 handle_08
 AHCI/0: ... intbits 0x1, status 0x50 ...
 AHCI/0: ... finished, status 0x50, OK
 ahci disk read, lba  0, count   1, buf 0x0003, rc 0
 enter handle_13:
a=4200  b=  c=  d=0080 ds=3204 es= ss=9000
   si= di= bp= sp=ffd6 cs=2000 ip=0a1d  f=0256
 disk_op d=0x000f98e0 lba=2048 buf=0x0003 count=16 cmd=2
 AHCI/0: send cmd ...
 AHCI/0: ... intbits 0x1, status 0x50 ...
 AHCI/0: ... finished, status 0x50, OK
 ahci disk read, lba800, count  10, buf 0x0003, rc 0
 enter handle_1a:
a=  b=  c=  d= ds= es= ss=9000
   si= di= bp= sp=ffd6 cs=2000 ip=0a39  f=0256
 handle_08
 enter handle_1a:
a=  b=  c=  d= ds= es= ss=9000
   si= di= bp= sp=ffd6 cs=2000 ip=0a39  f=0256
 enter handle_13:
a=4200  b=  c=  d=0080 ds=3804 es= ss=9000
   si= di= bp= sp=ffd6 cs=2000 ip=0a1d  f=0256
 disk_op d=0x000f98e0 lba=7166912 buf=0x0003 count=64 cmd=2
 AHCI/0: send cmd ...
 handle_08
 AHCI/0: ... intbits 0x1, status 0x50 ...
 AHCI/0: ... finished, status 0x50, OK
 ahci disk read, lba 6d5bc0, count  40, buf 0x0003, rc 0 enter
 handle_1a:
a=  b=  c=  d= ds= es= ss=9000
   si= di= bp= sp=ffd6 cs=2000 ip=0a39  f=0256
 enter handle_13:
a=4200  b=  c=  d=0080 ds=3204 es= ss=9000
   si= di= bp= sp=ffd6 cs=2000 ip=0a1d  f=0256
 disk_op d=0x000f98e0 lba=31249832 buf=0x0003 count=16 cmd=2
 AHCI/0: send cmd ...
 handle_08
 AHCI/0: ... intbits 0x1, status 0x50 ...
 AHCI/0: ... finished, status 0x50, OK
 ahci disk read, lba 1dcd5a8, count  10, buf 0x0003, rc 0 enter
 handle_1a:
a=  b=  c=  d= ds= es= ss=9000
   si= di= bp= sp=ffd6 cs=2000 ip=0a39  f=0256
 enter handle_1a:
a=  b=  c=  d= ds= es= ss=9000
   si= di= bp= sp=ffd6 cs=2000 ip=0a39  f=0256
 enter handle_1a:
a=  b=  c=  d= ds= es= ss=9000
   si= di= bp= sp=ffd6 cs=2000 ip=0a39  f=0256
 handle_08
 enter handle_1a:
a=  b=  c=  d= ds= es= ss=9000
   si= di= bp= sp=ffd6 cs=2000 ip=0a39  f=0256
 enter handle_1a:
a=0200  b=  c=  d= ds= es= ss=9000
   si= di= bp= sp=ffd6 cs=2000 ip=0a39  f=0256
 enter handle_1a:
a=0400  b=  c=  d= ds= es= ss=9000
   si= di= bp= sp=ffd6 cs=2000 ip=0a39  f=0256
 enter handle_1a:
a=  b=  c=  d= ds= es= ss=9000
   si= di= bp= sp=ffd6 cs=2000 ip=0a39  f=0256
 handle_08
 agesawrapper_amdinitmmio() entry
 agesawrapper_amdinitmmio() returned AGESA_SUCCESS


 coreboot-4.0-6798-gdd6d81f-dirty Thu Mar 19 20:02:01 CST 2015 starting...
 BSP Family_Model:
 cpu_init_detectedx = 
 agesawrapper_amdinitreset() entry
 AmdCreateStruct, 188, InterfaceParams-StdHeader.HeapBasePtr=40
 Fch OEM config in INIT RESET Done
 agesawrapper_amdinitreset() returned AGESA_SUCCESS Got past
 agesawrapper_amdinitreset
 agesawrapper_amdinitearly() entry
 AmdCreateStruct, 188, InterfaceParams-StdHeader.HeapBasePtr=40
 AmdInitEarly, 239, EarlyParams-StdHeader=400290 AmdInitEarly, 247,
 EarlyParams-StdHeader=0 AmdInitEarly, 273, 

Re: [coreboot] Unifying IO accessor macros

[David Hendricks via coreboot]

On Wed, Feb 18, 2015 at 8:49 AM, Alexandru Gagniuc mr.nuke...@gmail.com
wrote:

 On Wednesday, February 18, 2015 09:16:07 AM Aaron Durbin wrote:
  As I have noted on http://review.coreboot.org/#/c/7924/ it's very
  short sighted to go this route. In assembling a coreboot stack (which
  includes libpayload and the payload itself) the code usually comes
  from different software systems. Those include libpayload, linux
  kernel, u-boot, etc. They all have the write(val, addr) semantics. I
  see no good reason to artificially erect an ever present barrier for
  integrating code into a coreboot system.
 
 As Patrick already said, compared to the total effort to integrate external
 sources, the issue of argument order is insignificant. In the time you
 spent
 writing this email, you could have found out how to do it with coccinelle,
 and
 could have applied it to any number of sources.

  Alex, you've clearly stated your opinion you've not justified a reason
  for keeping the barrier.

 If you think that something as simple as this is a barrier, then you're
 likely
 just copypasting code. In that case, I do want a barrier to protect you
 from
 yourself, and from putting up code that was no reviewed in its entirety.
 Really, it's not a barrier.


I don't think this argument makes sense for code that is being actively
developed in other code bases and imported into coreboot. Of course, if
you're importing stable code and don't expect much churn, tidying things up
is a fine idea. But increasing deltas while a project is still under active
development only serves to make integration and maintenance efforts more
troublesome and prone to error. It's not a productive use of anyone's time
when there are real bugs to solve.

Vendors often have code which they have already qualified and are
understandably reluctant to make any changes to it, even trivial aesthetic
ones. I'd like to make it easier for them to contribute directly to
coreboot, and throwing up artificial barriers does not help them gain
traction.

-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Unifying IO accessor macros

[David Hendricks via coreboot]

On Wed, Feb 18, 2015 at 10:52 AM, Julius Werner jwer...@chromium.org
wrote:

  As Patrick already said, compared to the total effort to integrate
 external
  sources, the issue of argument order is insignificant. In the time you
 spent
  writing this email, you could have found out how to do it with
 coccinelle, and
  could have applied it to any number of sources.
 
  http://review.coreboot.org/8483

 Remember that those other code bases use writel(v, a), not write32(v,
 a). Just going half the way by changing the order but not the name
 wouldn't be very useful I think.


Yes, fixing the order is far more important.

I wouldn't even care if we still end up with both write32(a, v) or
writel(a, v) in the codebase (or u32 vs. uint32_t), so long the usage is
consistent and wrappers are trivial.

-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Unifying IO accessor macros

[David Hendricks via coreboot]

On Wed, Feb 18, 2015 at 2:47 PM, Julius Werner jwer...@chromium.org wrote:

  I think nobody disagrees that type checking is a bad idea here.

 I ain't not unsure that you failed to not make no mistake with the
 missing lack of double negatives there... ;)

  I don't think this argument makes sense for code that is being actively
  developed in other code bases and imported into coreboot. Of course, if
  you're importing stable code and don't expect much churn, tidying things
 up
  is a fine idea. But increasing deltas while a project is still under
 active
  development only serves to make integration and maintenance efforts more
  troublesome and prone to error. It's not a productive use of anyone's
 time
  when there are real bugs to solve.
 
  Vendors often have code which they have already qualified and are
  understandably reluctant to make any changes to it, even trivial
 aesthetic
  ones. I'd like to make it easier for them to contribute directly to
  coreboot, and throwing up artificial barriers does not help them gain
  traction.

 Do we really want to facilitate more of these wholesale imports of
 untouched, existing code dumps from other sources into coreboot?


I don't think that's necessarily a bad thing during heavy development.
Obviously we'd want to tidy things up after the fact and use wrappers until
then, but insofar as this whole write32/writel and arg ordering discussion
goes there hasn't been much to aspire to in terms of tidying things.

So basically what I'm advocating is to define a proper approach that we
apply to coreboot in general, while being flexible about importing code.
Once we define the proper approach, then applying an spatch to bring the
style into conformance and remove the scaffolding should be relatively
painless.

It
 seems to me that those always end up bad for us... code is hard to
 read and follow because of switched conventions,


Yep. And for the person porting the code, switching conventions on-the-fly
might be even more confusing. I generally like to see code working before
making such changes.


 it could have
 depended on different requirements for the environment than what
 coreboot provides, it often includes a lot of hacky and
 overcomplicated code that the original use case might have needed but
 we don't, people will end up making changes after the import that
 desync it with the source, etc.


True, and I think it's more productive to prioritize fixing those issues
over aesthetic ones.

I'm all for re-factoring code. I just don't think forcing huge deltas from
the get-go during heavy development is a great way to do it.


 I think for small stuff like
 individual drivers we're better off just rewriting them with a sound
 design from the ground up tailored to our use case (at least that
 guarantees that someone really understood and thought through how it
 all works within the coreboot context).


Agreed - For small stuff I'm totally on-board.

That might not be the case, however, for more complicated stuff.  For
example, if a vendor updates DRAM init code in u-boot multiple times over a
period of weeks/months and we need to apply the same updates to coreboot,
having hundreds of cosmetic changes show up in the diff just makes the
porting process more difficult and more prone to error.


 For really large scale
 external imports (like AMD Agesa), we can stow it away in vendorcode/
 with translator headers to allow it to keep its own conventions
 completely unchanged, without risk of it leaking out into the rest of
 coreboot.


Yep.

-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Access to bug reports in Chromium bug tracker

[David Hendricks via coreboot]

On Sat, Jan 17, 2015 at 11:01 AM, Paul Menzel 
paulepan...@users.sourceforge.net wrote:

 Am Donnerstag, den 15.01.2015, 16:08 -0800 schrieb David Hendricks:
  On Thu, Jan 15, 2015 at 3:34 PM, Paul Menzel wrote:
 
Issues which are closed now will almost certainly remain that way.
  
   Should those be referenced in the source code then?
 
  Probably not, but at some point it just doesn't matter.
 
   Or should they at least be marked, for example with `(restricted)`?
 
  Not at the expense of time/effort that can be better spent putting
 coreboot
  on more products. Besides, that would just increase deltas between trees
  with little or no gain.

 I disagree and your first argument can be used every time something
 requires effort to make it suitable for upstream inclusion. In my
 opinion it is something in the development process that needs to be
 addressed and improved.

 The person reading the source expects the URL to be accessible
 especially when almost all of these “crosbug” URLs can be accessed.

 But in the end, it looks like I am the only one having a problem with
 this, so I’ll have to accept that. Sorry for the noise.


No, my argument cannot be used every time something requires effort to
make suitable for upstreaming. This is evident by Sage's porting - Marc
has been putting a lot of time and effort into updating our patches so that
they are usable and actually worth something to the community. That
produces real value. Notice how many more vendors are posting to the list
these days. A few cosmetic blemishes is a small price to pay for growing
the ecosystem.

You do have a point, though. We've all been frustrated with blobs of code
that are poorly documented. Some companies resolve this (and their other
paranoid issues) by simply scrubbing all comments and documentation out of
the code prior to release. I prefer we not do that. At least with the
current way you can ask about what a particular issue may have been that
justifies mentioning it in the code.

-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Access to bug reports in Chromium bug tracker

[David Hendricks via coreboot]

On Thu, Jan 15, 2015 at 3:34 PM, Paul Menzel 
paulepan...@users.sourceforge.net wrote:

  Issues which are closed now will almost certainly remain that way.

 Should those be referenced in the source code then?


Probably not, but at some point it just doesn't matter.


 Or should they at
 least be marked, for example with `(restricted)`?


Not at the expense of time/effort that can be better spent putting coreboot
on more products. Besides, that would just increase deltas between trees
with little or no gain.

-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Access to bug reports in Chromium bug tracker

[David Hendricks via coreboot]

On Wed, Jan 14, 2015 at 2:11 PM, Paul Menzel 
paulepan...@users.sourceforge.net wrote:

 Dear coreboot folks,


 looking at change set #8214 [1], it adds a comment with a reference to
 the Chromium bug tracker at code.google.com.

 http://crosbug.com/p/29117

 Unfortunately access to view that is denied to me.


We use two issue trackers, one which is public (which crosbug.com redirects
to) and one which is private. The public tracker is used by default for
most cases, unless it's known that the subject matter will involve
confidential details. The particular issue you cited was likely public to
begin with, but later moved or restricted. Restrictions to issues filed on
the public tracker are sometimes added if resolving a bug involves
discussing confidential details about a chip or product (often in the form
of logs / debug output).



 Looking at some of the items already in the upstream tree, most of them
 seem to be accessible though.

 $ git grep crosbug
 payloads/libpayload/drivers/serial/ipq806x.c:* See
 http://crosbug.com/p/29313
 payloads/libpayload/drivers/timer/ipq806x.c: *
 http://crosbug.com/p/28880 for details.
 src/ec/google/chromeec/acpi/battery.asl:// a bug in the
 Linux kernel: http://crosbug.com/28747
 src/ec/google/chromeec/ec_commands.h: *
 TODO(crosbug.com/p/11223): This is effectively useless; protocol
 is
 src/ec/google/chromeec/ec_commands.h: *
 TODO(crosbug.com/p/23570): These commands are deprecated, and
 will be
 src/ec/google/chromeec/ec_commands.h: *
 TODO(crosbug.com/p/23747): This is a confusing name, since it
 doesn't
 src/mainboard/samsung/lumpy/acpi_tables.c:   * Provide
 option to enable for http://crosbug.com/p/7925
 src/soc/intel/broadwell/acpi/gpio.asl:  // Disabled due
 to IRQ storm: http://crosbug.com/p/29548
 src/vendorcode/google/chromeos/vboot.c: * crosbug.com/17017 */

 So my question is, is access granted to all these bugs eventually?


Issues which are closed now will almost certainly remain that way.



 Thanks,

 Paul


 [1]
 http://review.coreboot.org/#/c/8214/1/src/mainboard/google/samus/romstage.c

 --
 coreboot mailing list: coreboot@coreboot.org
 http://www.coreboot.org/mailman/listinfo/coreboot




-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot