On Saturday, February 14, 2015 12:05:28 AM Marc Jones wrote:
> Hi Everyone,
>
Hi,
> Please update the wiki page with project ideas.
> http://www.coreboot.org/Project_Ideas
>
That's the first unlocked page in the coreboot wiki I have seen for quite some
time.
Alex
On Wed, Feb 18, 2015 at 10:52 AM, Julius Werner <jwerner(a)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.
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.
Alex
* Julius Werner <jwerner(a)chromium.org> [150218 00:12]:
> I'd like to propose an API change/cleanup for a long-standing problem
> with architecture-independent code that people have hit and privately
> discussed/cursed multiple times already, but no one really had time to
> make the big change/fix yet. (Some earlier discussion among Chromium
> people about this is available at http://crbug.com/451388 )
[..]
I think nobody disagrees that type checking is a bad idea here.
It was a mistake to let type checking free versions of these accessors
slip into the tree into the first place.
The second part is a little bit more prone to personal preferences.
- Using 8 / 16 / 32 / 64 for data size is more explicit that b / w / l / q
- (addr, val) is more aligned with other APIs in coreboot
- Using the Linux API as a standard will make it easier for people to
switch between code bases, and thus is a lot less error prone
- Using the Linux API makes it easier to share code with other projects.
such as u-boot, Linux, libpayload based projects
Since there is no clear winner, I would like to ask you to participate
in a poll to measure what people would prefer:
http://doodle.com/3dwbudycrypg9xyf
Stefan
The 1.8.0 version of SeaBIOS has now been released. For more
information on the release, please see:
http://seabios.org/Releases
New in this release:
* Several USB timing fixes for USB controllers on real hardware
* Initial support for USB3 hubs
* Initial support for SD cards (on QEMU only)
* Initial support for transitioning to 32bit mode using SMIs (on QEMU
TCG only)
* SeaVGABIOS improvements
* Added cursor emulation to coreboot native init vgabios (cbvga)
* Added support for read character calls when in graphics mode
* Developer documentation added to "docs/" directory in the code
repository and several documentation updates
* Several bug fixes and code cleanups
For information on obtaining SeaBIOS, please see:
http://seabios.org/Download
>> 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.
FWIW I sightly prefer write32(a, v) for purely aesthetic reasons (it's
also more in line with our current setbits_le32(a, v)), but I really
don't care much as long as we make a decision at all. There's
currently ~3500 write32()s in upstream coreboot and ~2800 writel()s in
Chromium coreboot (which has more ARM code), so now the impact for
going either direction should be roughly the same.
2015-02-18 18:35 GMT+01:00 Aaron Durbin via coreboot <coreboot(a)coreboot.org>:
> coreboot is different than:
> 1. linux
> 2. uboot
And similar to Solaris, Windows and the BSDs.
As for libpayload, I'd rather import code from BSD than Linux for
licensing reasons.
> 3. libpayload
> 4. Anything using libpayload
Which could be fixed (since some changes are necessary in any case)
Patrick
--
Google Germany GmbH
ABC-Str. 19
20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
On Wednesday, February 18, 2015 11:50:04 AM Aaron Durbin wrote:
> On Wed, Feb 18, 2015 at 11:41 AM, Alexandru Gagniuc
> > And you still haven't responded to my proposal of using EFI style.
>
> I thought that was a non-sensical proposal.
My point exactly.
Alex
On Wednesday, February 18, 2015 11:35:13 AM Aaron Durbin wrote:
> You still haven't made any counter-argument to the practicalness of being
> compatible with the software systems where coreboot gets contribution.
>
And you still haven't responded to my proposal of using EFI style.
Alex
