Re: [coreboot] A case for branching AGESA

[Vladimir]

I strongly disagree with this branching "solution". Why?
Because - if building all the targets is slow - then just don't build all
the targets at once! If you need a fast build and you are not concerned
about AMD boards - just because you don't have any - it is always possible
to skip AGESA build without moving it to a branch and separating from the
rest of the coreboot code . So this is seen as a really bad excuse

Best regards,
Vladimir Shipovalov




On 3 November 2015 at 01:14, Peter Stuge  wrote:

> Alex G. wrote:
> > >> users of AGESA can continue to contribute and work on the codebase.
> > > ... and diverge...
> >
> > And that's expected. Convergence is a dream.
>
> I disagree. I think it's a goal rather than a dream.
>
> > AGESA boards use BuildOpts for configuration, and not much
> > Kconfig/devicetree.cb
>
> I've done a bit of work on moving BuildOpts config for IDS into Kconfig,
> but it's not quite ready yet. I wrote the change dry and the only
> test data I have available reports coreboot not working after
> applying it. :) Sometime..
>
>
> > SPD parsing routines. I can go on and on.
> > non-divergence is a moot point.
>
> I disagree - I think we need to work towards less divergence rather
> than move in a direction which is likely to create more divergence.
>
> That's the only way to keep the codebase maintainable - which we all
> want. It was clear to me already when we saw the very first code from
> AMD that integration into our own codebase would take a while.
>
> I don't want to remove contributed code until we've given that a real shot.
>
>
> //Peter
>
> --
> coreboot mailing list: coreboot@coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] setting up a bug tracker

[Idwer Vollering]

2015-11-03 19:17 GMT+01:00 Patrick Georgi :
> Hey coreboot folks,
>
> people were nagging me to set up a bug tracker for the project.
>
> Last time we dicussed that, we mostly quibbled over the UI and data
> model (whether the tracker should feature free form vs. structured
> data bug entry), and that's a discussion I don't want to participate
> in, so I'm staying out of the decision which bug tracker it should be.
>
> My offer is: Figure out (collectively) what issue tracker is suitable
> for coreboot, promise you'll help keeping it clean (so it doesn't
> become a graveyard like our trac instance), and I'll set it up.
>
> Only four constraints as far as I'm concerned:
> 1. It must be somewhat CPU efficient. Funnily that rules out trac.
> 2. It must be maintained. I have no interest in watching out for XSS
> issues myself.
> 3. It must be OSI friendly licensed. Jira and similar "special license
> for open source projects we like" stuff doesn't count.
> 4. It must run on Linux (since that's what the server uses)
>
> It also shouldn't be too esoteric. I reserve the right to simply give
> up if installing the tracker involves having to figure out how to set
> up an S/360 emulator, then build the open source issue tracker using a
> K compiler that can only be found on Abandonware websites that are
> written in scripts (as in character sets) that I can't read.

http://www.flyspray.org/ (yes, from edgewall)

Quoting http://trac.edgewall.org/wiki/FlySpray "Flyspray's development
stalled in 2013, but restarted in 2015 with the promise to deliver
version 1.0 in April-June 2015." It's now at 1.0b2

>
>
> Patrick
> --
> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: 
> Hamburg
> Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
>
> --
> coreboot mailing list: coreboot@coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot

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

[coreboot] setting up a bug tracker

[Patrick Georgi]

Hey coreboot folks,

people were nagging me to set up a bug tracker for the project.

Last time we dicussed that, we mostly quibbled over the UI and data
model (whether the tracker should feature free form vs. structured
data bug entry), and that's a discussion I don't want to participate
in, so I'm staying out of the decision which bug tracker it should be.

My offer is: Figure out (collectively) what issue tracker is suitable
for coreboot, promise you'll help keeping it clean (so it doesn't
become a graveyard like our trac instance), and I'll set it up.

Only four constraints as far as I'm concerned:
1. It must be somewhat CPU efficient. Funnily that rules out trac.
2. It must be maintained. I have no interest in watching out for XSS
issues myself.
3. It must be OSI friendly licensed. Jira and similar "special license
for open source projects we like" stuff doesn't count.
4. It must run on Linux (since that's what the server uses)

It also shouldn't be too esoteric. I reserve the right to simply give
up if installing the tracker involves having to figure out how to set
up an S/360 emulator, then build the open source issue tracker using a
K compiler that can only be found on Abandonware websites that are
written in scripts (as in character sets) that I can't read.


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

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

Re: [coreboot] Dell Dimension 8300 reboots when grub2 cbfs module is loaded

[Aaron Durbin]

On Tue, Nov 3, 2015 at 10:28 AM, Vladimir 'phcoder' Serbinenko
 wrote:
> The code itself looks good but I'd like more details. Reading 0x
> shouldn't cause reboot. Why does it?

It's probably implementation defined reading a multi-byte object from
4GiB-1. Does it wrap? Blow up the machine? Machine check? Transaction
never gets terminated?

>
> Le 1 nov. 2015 3:53 PM, "Andrei Borzenkov"  a écrit :
>>
>> I was debugging problem reported by user on Dell Dimension 8300 - it
>> rebooted when doing "ls -l". It turned out, the problem was triggered by
>> loading cbfs which probed for header. System has 2GB memory, and attempt to
>> read from address 0x caused instant reboot. 0x was returned
>> by read from non-existing address 0xfffc.
>>
>> The proof of concept patch below avoids it, but I wonder what the proper
>> fix is.
>>
>> diff --git a/grub-core/fs/cbfs.c b/grub-core/fs/cbfs.c
>> index a34eb88..a5a2fde 100644
>> --- a/grub-core/fs/cbfs.c
>> +++ b/grub-core/fs/cbfs.c
>> @@ -344,8 +344,9 @@ init_cbfsdisk (void)
>>
>>ptr = *(grub_uint32_t *) 0xfffc;
>>head = (struct cbfs_header *) (grub_addr_t) ptr;
>> +  grub_dprintf ("cbfs", "head=%p\n", head);
>>
>> -  if (!validate_head (head))
>> +  if (0x - ptr < sizeof (*head) || !validate_head (head))
>>  return;
>>
>>cbfsdisk_size = ALIGN_UP (grub_be_to_cpu32 (head->romsize),
>>
>>
>> ___
>> Grub-devel mailing list
>> grub-de...@gnu.org
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot

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

Re: [coreboot] Dell Dimension 8300 reboots when grub2 cbfs module is loaded

[Vladimir 'phcoder' Serbinenko]

Le 3 nov. 2015 6:46 PM, "Aaron Durbin"  a écrit :
>
> On Tue, Nov 3, 2015 at 10:28 AM, Vladimir 'phcoder' Serbinenko
>  wrote:
> > The code itself looks good but I'd like more details. Reading 0x
> > shouldn't cause reboot. Why does it?
>
> It's probably implementation defined reading a multi-byte object from
> 4GiB-1. Does it wrap? Blow up the machine? Machine check? Transaction
> never gets terminated?
>
It would be interesting to find out. Since it's P4, it may be related to
PAE but paging is disabled when GRUB is active However it shouldn't hold
this patch. Andrei: go ahead, just please add reference to machine and cpu
in the comment and the fact that we have little idea what's going on.
> >
> > Le 1 nov. 2015 3:53 PM, "Andrei Borzenkov"  a
écrit :
> >>
> >> I was debugging problem reported by user on Dell Dimension 8300 - it
> >> rebooted when doing "ls -l". It turned out, the problem was triggered
by
> >> loading cbfs which probed for header. System has 2GB memory, and
attempt to
> >> read from address 0x caused instant reboot. 0x was
returned
> >> by read from non-existing address 0xfffc.
> >>
> >> The proof of concept patch below avoids it, but I wonder what the
proper
> >> fix is.
> >>
> >> diff --git a/grub-core/fs/cbfs.c b/grub-core/fs/cbfs.c
> >> index a34eb88..a5a2fde 100644
> >> --- a/grub-core/fs/cbfs.c
> >> +++ b/grub-core/fs/cbfs.c
> >> @@ -344,8 +344,9 @@ init_cbfsdisk (void)
> >>
> >>ptr = *(grub_uint32_t *) 0xfffc;
> >>head = (struct cbfs_header *) (grub_addr_t) ptr;
> >> +  grub_dprintf ("cbfs", "head=%p\n", head);
> >>
> >> -  if (!validate_head (head))
> >> +  if (0x - ptr < sizeof (*head) || !validate_head (head))
> >>  return;
> >>
> >>cbfsdisk_size = ALIGN_UP (grub_be_to_cpu32 (head->romsize),
> >>
> >>
> >> ___
> >> Grub-devel mailing list
> >> grub-de...@gnu.org
> >> https://lists.gnu.org/mailman/listinfo/grub-devel
> >
> >
> > --
> > coreboot mailing list: coreboot@coreboot.org
> > http://www.coreboot.org/mailman/listinfo/coreboot
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFC] Time until patches should be submitted

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/03/2015 03:36 PM, Paul Menzel wrote:
> Dear coreboot folks,
> 
> 
> Am Donnerstag, den 29.10.2015, 12:55 -0600 schrieb Martin Roth:
>> As the community has grown, so has the need to formalize some of the
>> guidelines that the community lives by. When the community was small,
>> it was easy to communicate these things just from one person to
>> another.
> 
> first of, big thanks go to Martin for writing up the draft!
> 
> […]
> 
>> Expectations contributors should have:
>> --
>> * Don't expect that people will review your patch unless you ask them
>> to. Adding other people as reviewers is the easiest way. Asking for
>> reviews for individual patches in the IRC channel, or by sending a
>> direct request to an individual through your favorite messenger is
>> usually the best way to get a patch reviewed quickly.
>> * Don't expect that your patch will be submitted immediately after
>> getting a +2. As stated previously, non-trivial patches should wait 
>> at least 24 hours before being submitted.
> 
> to get some context, at the coreboot conference in Bonn some people
> asked for longer review time to not wake up the next morning seeing
> something changed.
> 
> Even then, especially for non-payed developers, I think it’s hard to
> stay up to date, so the question is, if the time is long enough. On IRC
> somebody even mentioned, that patches should stay up for review for *a
> week* before getting merged, so there is enough time people can notice
> this.
> 
> To not complicate rules, it probably would be easiest to just ask
> around if people are alright with 24 hours. Especially, when people
> working on the code get added as reviewers, this should be alright.
> 
> On the other hand, more complicated rules could be drafted. The
> following rules just deal with the time issue. I am assuming, that +2
> has been given before and the appropriate announcements are made.
> 
> 1. Commits just touching a board can be submitted after 24 hours.
> 2. Commits touch more boards, should stay up for review for a week.
> They can be submitted earlier if an announcement to the list about the
> urgency has been sent and at least two people have given +2.
> 
> […]
> 
> 
> Thanks,
> 
> Paul

The only thing I'd like to mention in here is that by increasing latency
too far, you will increase the tendency for large patch trains to be
dumped on Gerrit and possibly abandoned.  There are conflicting goals at
the moment; one is to reduce patch trains by merging incrementally, but
almost no one aside from a hobby hacker is going to be OK with waiting
at each development stage for over a week for the review process to
finally get around to merging things.

A single data point is a patch I created to fix a kernel panic in the
Linux kernel.  Anyone who's familiar with the Linux development process
knows that certain areas have an extreme latency due to poor
maintainership; apparently I hit one of those areas.  The latency for
communication was several weeks (!) and as a result the patch was not
taken up and the kernel will still panic under the original conditions
that prompted the patch, even though there was no direct objection to
the contents of the patch.

Now if the kernel panics, a reboot can fix it.  If coreboot goes down,
machines can be bricked.

Just something to consider -- like all things in life, it's a balance.

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
http://www.raptorengineeringinc.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJWOSqVAAoJEK+E3vEXDOFbW/4H/RAkgFdo6AwMi3KuMApGR9qU
y1lu6bClRUcvwx0Qs9wBolWuB+YiMzG1bcpgopbPXAozx3NMmkj3w73Mp14U2NDt
ZqCHZvClvQXUk4psDFTbRmFv4n3B6CX0EIVmy0Kcfrqd34YCNI8GHeYuXy4EOTrt
oWAIZgpvh8maOPx2UWv0EmJsYwnycrUiZ1S9RqV3OM0OEjLvZ7r6RJamzTjcBqrs
dq0rw6ihTM8M0vcfWqPokkL35Aw4WxalRilauW/SJc06Wgov22XksiWYulg7/4DN
WexwvbEuELHXLxLSxwcGcI9k/DV8dyiuBuogQy33Cpa8gjJPWIqI9QYJiL8A+e8=
=XGjb
-END PGP SIGNATURE-

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

Re: [coreboot] Dell Dimension 8300 reboots when grub2 cbfs module is loaded

[Nico Huber]

Hi Andrei,

your patch looks good generally, but the check is off by one. It's
obvious, we want to have sane checking there. Reading from a random
address can cause trouble and 0x is not the only offending
address.

On x86, the cbfs is mapped right below the 4GiB line. Current machines
don't have more than 16MiB space for cbfs, FWIW. So maybe it's best to
check if the ptr points somewhere between 0xff00 and (0x1 -
sizeof(*head)).

Nico

On 01.11.2015 15:53, Andrei Borzenkov wrote:
> I was debugging problem reported by user on Dell Dimension 8300 - it
> rebooted when doing "ls -l". It turned out, the problem was triggered by
> loading cbfs which probed for header. System has 2GB memory, and attempt
> to read from address 0x caused instant reboot. 0x was
> returned by read from non-existing address 0xfffc.
> 
> The proof of concept patch below avoids it, but I wonder what the proper
> fix is.
> 
> diff --git a/grub-core/fs/cbfs.c b/grub-core/fs/cbfs.c
> index a34eb88..a5a2fde 100644
> --- a/grub-core/fs/cbfs.c
> +++ b/grub-core/fs/cbfs.c
> @@ -344,8 +344,9 @@ init_cbfsdisk (void)
> 
>ptr = *(grub_uint32_t *) 0xfffc;
>head = (struct cbfs_header *) (grub_addr_t) ptr;
> +  grub_dprintf ("cbfs", "head=%p\n", head);
> 
> -  if (!validate_head (head))
> +  if (0x - ptr < sizeof (*head) || !validate_head (head))
>  return;
> 
>cbfsdisk_size = ALIGN_UP (grub_be_to_cpu32 (head->romsize),
> 
> 

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

[coreboot] [RFC] Time until patches should be submitted (was: Document for review: coreboot Gerrit Etiquette and Guidelines)

[Paul Menzel]

Dear coreboot folks,


Am Donnerstag, den 29.10.2015, 12:55 -0600 schrieb Martin Roth:
> As the community has grown, so has the need to formalize some of the
> guidelines that the community lives by. When the community was small,
> it was easy to communicate these things just from one person to
> another.

first of, big thanks go to Martin for writing up the draft!

[…]

> Expectations contributors should have:
> --
> * Don't expect that people will review your patch unless you ask them
> to. Adding other people as reviewers is the easiest way. Asking for
> reviews for individual patches in the IRC channel, or by sending a
> direct request to an individual through your favorite messenger is
> usually the best way to get a patch reviewed quickly.
> * Don't expect that your patch will be submitted immediately after
> getting a +2. As stated previously, non-trivial patches should wait 
> at least 24 hours before being submitted.

to get some context, at the coreboot conference in Bonn some people
asked for longer review time to not wake up the next morning seeing
something changed.

Even then, especially for non-payed developers, I think it’s hard to
stay up to date, so the question is, if the time is long enough. On IRC
somebody even mentioned, that patches should stay up for review for *a
week* before getting merged, so there is enough time people can notice
this.

To not complicate rules, it probably would be easiest to just ask
around if people are alright with 24 hours. Especially, when people
working on the code get added as reviewers, this should be alright.

On the other hand, more complicated rules could be drafted. The
following rules just deal with the time issue. I am assuming, that +2
has been given before and the appropriate announcements are made.

1. Commits just touching a board can be submitted after 24 hours.
2. Commits touch more boards, should stay up for review for a week.
They can be submitted earlier if an announcement to the list about the
urgency has been sent and at least two people have given +2.

[…]


Thanks,

Paul
> 

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] setting up a bug tracker

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/03/2015 12:17 PM, Patrick Georgi wrote:
> Hey coreboot folks,
> 
> people were nagging me to set up a bug tracker for the project.
> 
> Last time we dicussed that, we mostly quibbled over the UI and data
> model (whether the tracker should feature free form vs. structured
> data bug entry), and that's a discussion I don't want to participate
> in, so I'm staying out of the decision which bug tracker it should be.
> 
> My offer is: Figure out (collectively) what issue tracker is suitable
> for coreboot, promise you'll help keeping it clean (so it doesn't
> become a graveyard like our trac instance), and I'll set it up.
> 
> Only four constraints as far as I'm concerned:
> 1. It must be somewhat CPU efficient. Funnily that rules out trac.
> 2. It must be maintained. I have no interest in watching out for XSS
> issues myself.
> 3. It must be OSI friendly licensed. Jira and similar "special license
> for open source projects we like" stuff doesn't count.
> 4. It must run on Linux (since that's what the server uses)
> 
> It also shouldn't be too esoteric. I reserve the right to simply give
> up if installing the tracker involves having to figure out how to set
> up an S/360 emulator, then build the open source issue tracker using a
> K compiler that can only be found on Abandonware websites that are
> written in scripts (as in character sets) that I can't read.
> 
> 
> Patrick

Is Bugzilla out of the question?

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
http://www.raptorengineeringinc.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJWORE8AAoJEK+E3vEXDOFb/YQH/jXGbKa5kWiWCBSv0Z/3YZEz
IUcmWtZw7MAUakdVtnyJoh1p7iU3ehwMXXA4qUb+j5KIcuTLE2NXLF90iur9dKVf
nzxcB2EB6TnB+kmiHY2Nc07GE+P0z6MkvkxUzF33C1CwpZKznXeMmVIqwvTvuo6Z
BQr5iCSSjriACGv8JBfdanIiis8/vJfV4T8RYZA26N6ql9JJhqtz/2qI+K1xRqwD
kxuyFP2gcD5W5t2+r3Cm2DdobeOYP4LedaEgddVw7y9cjEVN7rbdi5ehAwQgC6MH
iH+c/m65dKeAGfwYLbO3Po+aPaLlIBURhxlAEp+p8JLRYhP4JzNOli6ScFbNK1k=
=s5Yg
-END PGP SIGNATURE-

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

Re: [coreboot] A case for branching AGESA

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/03/2015 03:41 AM, Vladimir wrote:
> I strongly disagree with this branching "solution". Why?
> Because - if building all the targets is slow - then just don't build
> all the targets at once! If you need a fast build and you are not
> concerned about AMD boards - just because you don't have any - it is
> always possible to skip AGESA build without moving it to a branch and
> separating from the rest of the coreboot code . So this is seen as a
> really bad excuse
> 
> Best regards,
> Vladimir Shipovalov

I do agree technically with this, however there's no policy in place for
what happens when an AGESA build finally does fire and it's found the
related source broke some time ago.  I think that's the main reason for
wanting to stuff AGESA in a branch; separation of maintainaince.

One one hand, having recently been the victim of having some of my
native init patches fail Jenkins builds due to AGESA breakage, I'd
almost like to see this happen.  On the other hand, I know exactly how
painful sync across branches can be, so I can't recommend it.

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
http://www.raptorengineeringinc.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJWORHbAAoJEK+E3vEXDOFbfbgH/i5wk3vQrqtlAuCY0Jhdx2ML
ez0ugczbnHaRiQZAuf62oQn1A2oPWg25LFssokztv9MyaJ1p1JbYkt1sLLJL5Eoi
hHwm3Lr61oM4NWkHYIy8s1TiK2nIAWnw2gepulNePe9vlul0CiMFlqMon8FMoYCC
6cONRC/09ElLElPRazp5JkoOJnqWTxWotKJqYUJwoxQ7ed2f0L6WB45KWFZSpz3W
PsO/WEX5TmsxiXLoV8q2W9NYizfNoDV/TIs89aKskcylxSCdj3DYWKYMudLAvglK
wpsfJWuy7WRw01Lp+Av6aPeF0rzU+pP/z9JhzewZWTBryjl9KJ2mQEI1MbjJwtE=
=3wXn
-END PGP SIGNATURE-

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

[coreboot] [ANN] Sun Ultra 40 M2 board port pushed for review

[Paul Menzel]

Dear coreboot folks,


Jonathan Kollasch pushed the port of Sun Ultra 40 M2 for review. Help
reviewing that AMD board is much appreciated.

The “base“ change set is #12304 [1].


Thanks,

Paul


[1] http://review.coreboot.org/12304

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Is it possible to flash coreboot with proprietary vendor tools?

[Iru Cai]

Hi,

Can I use proprietary vendor tools like winflash or a vendor BIOS
update disk to flash coreboot? I don't think it possible but I can't
find a reason to explain, or it may be possible if I modify the ROM
format to fit those tools.

Iru Cai


signature.asc
Description: PGP signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Is it possible to flash coreboot with proprietary vendor tools?

[David Hendricks]

coreboot does not depend on the tool used to flash it. Proprietary vendor
tools should work, but they might perform some additional step beyond
flashing that will not work with coreboot, for example, checking validity
of a proprietary signature.

On Tue, Nov 3, 2015 at 6:49 PM, Iru Cai  wrote:

> Hi,
>
> Can I use proprietary vendor tools like winflash or a vendor BIOS
> update disk to flash coreboot? I don't think it possible but I can't
> find a reason to explain, or it may be possible if I modify the ROM
> format to fit those tools.
>
> Iru Cai
>
> --
> 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] [RFC] Time until patches should be submitted (was: Document for review: coreboot Gerrit Etiquette and Guidelines)

[David Hendricks]

On Tue, Nov 3, 2015 at 1:36 PM, Paul Menzel <
paulepan...@users.sourceforge.net> wrote:

> Dear coreboot folks,
>
>
> Am Donnerstag, den 29.10.2015, 12:55 -0600 schrieb Martin Roth:
> > As the community has grown, so has the need to formalize some of the
> > guidelines that the community lives by. When the community was small,
> > it was easy to communicate these things just from one person to
> > another.
>
> first of, big thanks go to Martin for writing up the draft!
>
> […]
>
> > Expectations contributors should have:
> > --
> > * Don't expect that people will review your patch unless you ask them
> > to. Adding other people as reviewers is the easiest way. Asking for
> > reviews for individual patches in the IRC channel, or by sending a
> > direct request to an individual through your favorite messenger is
> > usually the best way to get a patch reviewed quickly.
> > * Don't expect that your patch will be submitted immediately after
> > getting a +2. As stated previously, non-trivial patches should wait
> > at least 24 hours before being submitted.
>
> to get some context, at the coreboot conference in Bonn some people
> asked for longer review time to not wake up the next morning seeing
> something changed.
>
> Even then, especially for non-payed developers, I think it’s hard to
> stay up to date, so the question is, if the time is long enough. On IRC
> somebody even mentioned, that patches should stay up for review for *a
> week* before getting merged, so there is enough time people can notice
> this.
>
> To not complicate rules, it probably would be easiest to just ask
> around if people are alright with 24 hours. Especially, when people
> working on the code get added as reviewers, this should be alright.
>
> On the other hand, more complicated rules could be drafted. The
> following rules just deal with the time issue. I am assuming, that +2
> has been given before and the appropriate announcements are made.
>
> 1. Commits just touching a board can be submitted after 24 hours.
> 2. Commits touch more boards, should stay up for review for a week.
> They can be submitted earlier if an announcement to the list about the
> urgency has been sent and at least two people have given +2.
>

There's a catch-22 here: The kinds of patches that could benefit from >24
hours in limbo also tend to be the disruptive kinds that may require
additional rebasing or changes should they remain in code review for too
long. A lot can happen in a week and disruptive patches bitrot faster than
normal ones.

24 hours should be considered a minimum, but I'd say "preferably a few days
if possible." A >24hr grace period can be agreed upon by reviewers and the
author depending on the complexity to mitigate bitrot.

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

Re: [coreboot] Dell Dimension 8300 reboots when grub2 cbfs module is loaded

[Martin Roth]

Thanks Andrei,

Vladimir, what do you think?

Martin

On Sun, Nov 1, 2015 at 7:53 AM, Andrei Borzenkov  wrote:
> I was debugging problem reported by user on Dell Dimension 8300 - it
> rebooted when doing "ls -l". It turned out, the problem was triggered by
> loading cbfs which probed for header. System has 2GB memory, and attempt to
> read from address 0x caused instant reboot. 0x was returned
> by read from non-existing address 0xfffc.
>
> The proof of concept patch below avoids it, but I wonder what the proper fix
> is.
>
> diff --git a/grub-core/fs/cbfs.c b/grub-core/fs/cbfs.c
> index a34eb88..a5a2fde 100644
> --- a/grub-core/fs/cbfs.c
> +++ b/grub-core/fs/cbfs.c
> @@ -344,8 +344,9 @@ init_cbfsdisk (void)
>
>ptr = *(grub_uint32_t *) 0xfffc;
>head = (struct cbfs_header *) (grub_addr_t) ptr;
> +  grub_dprintf ("cbfs", "head=%p\n", head);
>
> -  if (!validate_head (head))
> +  if (0x - ptr < sizeof (*head) || !validate_head (head))
>  return;
>
>cbfsdisk_size = ALIGN_UP (grub_be_to_cpu32 (head->romsize),
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot

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

Re: [coreboot] Dell Dimension 8300 reboots when grub2 cbfs module is loaded

[Vladimir 'phcoder' Serbinenko]

The code itself looks good but I'd like more details. Reading 0x
shouldn't cause reboot. Why does it?
Le 1 nov. 2015 3:53 PM, "Andrei Borzenkov"  a écrit :

> I was debugging problem reported by user on Dell Dimension 8300 - it
> rebooted when doing "ls -l". It turned out, the problem was triggered by
> loading cbfs which probed for header. System has 2GB memory, and attempt to
> read from address 0x caused instant reboot. 0x was returned
> by read from non-existing address 0xfffc.
>
> The proof of concept patch below avoids it, but I wonder what the proper
> fix is.
>
> diff --git a/grub-core/fs/cbfs.c b/grub-core/fs/cbfs.c
> index a34eb88..a5a2fde 100644
> --- a/grub-core/fs/cbfs.c
> +++ b/grub-core/fs/cbfs.c
> @@ -344,8 +344,9 @@ init_cbfsdisk (void)
>
>ptr = *(grub_uint32_t *) 0xfffc;
>head = (struct cbfs_header *) (grub_addr_t) ptr;
> +  grub_dprintf ("cbfs", "head=%p\n", head);
>
> -  if (!validate_head (head))
> +  if (0x - ptr < sizeof (*head) || !validate_head (head))
>  return;
>
>cbfsdisk_size = ALIGN_UP (grub_be_to_cpu32 (head->romsize),
>
>
> ___
> Grub-devel mailing list
> grub-de...@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot