Hi all,
during the review of some commits that are in the process of being
upstreamed from Chrome OS, people noticed that chipset drivers like to
define their own TRUE/FALSE defines (sometimes prefixed to), and I
have seen a bunch of #define BIT{0-31} ..., too, because that seems to
be the house
On 04.02.2016 22:25, Patrick Georgi via coreboot wrote:
> 2016-02-04 22:22 GMT+01:00 Martin Roth :
>> I don't think we need redefinitions of TRUE/FALSE
> We have no canonical definitions for TRUE/FALSE right now.
> Contributions that use them (for whatever reason) tend to bring
Nico, I agree with you completely: non-zero is true, zero false. It's C.
But I am starting now to feel like a dinosaur, b/c
"Oh, and I'm trying to hang with the cool kids and use bool :)" -- Rusty
It makes me want to start an emo coreboot programmer feed like this one:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/04/2016 04:22 PM, ron minnich wrote:
> Nico, I agree with you completely: non-zero is true, zero false. It's C.
> But I am starting now to feel like a dinosaur, b/c
> "Oh, and I'm trying to hang with the cool kids and use bool :)" -- Rusty
>
>
I don't think we need redefinitions of TRUE/FALSE
Ron's argument against using BIT(16) makes sense to me.
I don't have a problem with BIT16, 0x1, or (1 << 16) but
#define VENDOR_BIT_16 0x1 seems like overkill.
I'd really generally prefer some good definitions though
instead of
On Thu, Feb 4, 2016 at 2:00 PM, Nico Huber wrote:
> On 04.02.2016 22:25, Patrick Georgi via coreboot wrote:
>> 2016-02-04 22:22 GMT+01:00 Martin Roth :
>>> I don't think we need redefinitions of TRUE/FALSE
>> We have no canonical definitions for TRUE/FALSE right
2016-02-04 22:22 GMT+01:00 Martin Roth :
> I don't think we need redefinitions of TRUE/FALSE
We have no canonical definitions for TRUE/FALSE right now.
Contributions that use them (for whatever reason) tend to bring local
copies, and that's what I'd like to avoid.
> How would
Vendors frequently ask us to use magic numbers, and have even requested at
times that we remove explanatory text.
We'll never get rid of magic numbers in this world :-(
ron
On Thu, Feb 4, 2016 at 1:25 PM Patrick Georgi wrote:
> 2016-02-04 22:22 GMT+01:00 Martin Roth
On 04.02.2016 10:35, Patrick Georgi via coreboot wrote:
> I think we should seek uniformity here: decide on some style,
> recommend it, clean up the tree to match, and help people stay
> consistent through lint tests.
That's a good idea.
> 2. BIT16 vs BIT(16) vs (1 << 16) vs 0x1
> I don't
On 02/01/2016 11:36 AM, Martin Roth wrote:
> What I don't read in that blog post is anything about the
> coreboot project being a democracy.
I'd normally find such a statement very disappointing, but I'm pretty
certain you're off on that one. I'm not sure how involved you've been in
coreboot
Hi there,
This seems pretty simple.
On 02/04/2016 01:35 AM, Patrick Georgi via coreboot wrote:
> Hi all,
>
> during the review of some commits that are in the process of being
> upstreamed from Chrome OS, people noticed that chipset drivers like to
> define their own TRUE/FALSE defines
On Thu, Feb 4, 2016 at 2:29 AM Patrick Georgi via coreboot <
coreboot@coreboot.org> wrote:
>
>
> 1. TRUE/FALSE
> Do we want such defines? If so, TRUE/FALSE, or true/false, or
> True/False, or ...?
>
should we start using bool ...?
>
> 2. BIT16 vs BIT(16) vs (1 << 16) vs 0x1
> I don't think
If your platform still does not boot up, I would suggest you check the SoC
revision on your platform with the microcode revision of your coreboot,
these two revisions should be matched, if not, system will halt in a every
early stage.
Another possibility you should consider is that if the UART
*RANGELEY_POSTGOLD4_FSP_004_20150924.fd is the FSP binary, you can rename
it to FvFsp.bin and placed it to the path defined in coreboot, ie, *
`../intel/fsp/rangeley/Fv*, to generate coreboot image.*
On Thu, Feb 4, 2016 at 5:19 AM, 김유석 wrote:
> Dear Martin.
>
> Thank's your
On 02/04/2016 11:38 AM, Raptor Engineering Automated Coreboot Test Stand
wrote:
> The ASUS KGPE-D16 fails verification as of commit
> 4af905ac95685500e71fb32cf5cec430d1a75447
>
> The following tests failed:
> BOOT_FAILURE
Taking the KGPE-D16 offline until we can get this sorted; too many
The ASUS KGPE-D16 fails verification as of commit
4af905ac95685500e71fb32cf5cec430d1a75447
The following tests failed:
BOOT_FAILURE
Commits since last successful test:
4af905a skylake boards: disable ACPI PM Timer
6c1bf27 intel/skylake: disable ACPI PM Timer to enable XTAL OSC shutdown
50c3ba2
16 matches
Mail list logo