Dear coreboot readers!
This is the automatic build system of coreboot.
The developer "stuge" checked in revision 5670 to
the coreboot repository. This caused the following
changes:
Change Log:
Add src/cpu/amd/model_gx2/cache_as_ram.inc missing from r5669
Part of converting GX2 to use CAR.
Sig
For some reason I can't update the ticket, it keeps giving me a
reCAPTCHA error but I don't see a recaptcha box. Anyways, here's a
link to the board I'm working on:
http://www.zotacusa.com/zotac-nm10-b-e-atom-d510-1-66-ghz-dual-core-mini-itx-wifi-intel-motherboard-283.html
The package I bought (f
baiyin cai wrote:
> hi all,
>since the xcompile file is generated for different compiler, i think it
> should be included under the PHONY distclean, am i right?
I think that makes good sense, but I hope to hear also from more
people.
> Signed-off-by Cai Bai Yin
Acked-by: Peter Stuge
If t
repository service wrote:
> Compilation of amd:rumba has been broken
> Compilation of lippert:frontrunner has been broken
> Compilation of olpc:btest has been broken
> Compilation of olpc:rev_a has been broken
> Compilation of wyse:s50 has been broken
It seems that src/cpu/amd/model_gx2/cache_as_r
Author: stuge
Date: Tue Jul 27 02:30:42 2010
New Revision: 5670
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5670
Log:
Add src/cpu/amd/model_gx2/cache_as_ram.inc missing from r5669
Part of converting GX2 to use CAR.
Signed-off-by: Nils Jacobs
Acked-by: Joseph Smith
Acked-by: Peter
hi all,
since the xcompile file is generated for different compiler, i think it
should be included under the PHONY distclean, am i right?
Signed-off-by Cai Bai Yin
Index: Makefile
===
--- Makefile (revision 5668)
+++ Makefile (wor
Dear coreboot readers!
This is the automatic build system of coreboot.
The developer "linux_junkie" checked in revision 5669 to
the coreboot repository. This caused the following
changes:
Change Log:
This patch converts the Geode GX2 boards to CAR.
Signed-off-by: Nils Jacobs
Acked-by: Joseph S
On 07/21/2010 05:20 PM, Nils wrote:
This patch converts the Geode GX2 boards to CAR.
It reduces the boot time with ~35 seconds in "Stage: loading
fallback/coreboot_ram".
After the conversion GCC gave a lot of build warnings in the old ROMCC code
(especially in the southbridge CS5535 code used by
Author: linux_junkie
Date: Tue Jul 27 01:46:25 2010
New Revision: 5669
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5669
Log:
This patch converts the Geode GX2 boards to CAR.
Signed-off-by: Nils Jacobs
Acked-by: Joseph Smith
Modified:
trunk/src/cpu/amd/model_gx2/Kconfig
trunk
>>include_path.diff: fix the ones that are broken for me.
>>include_path2.diff: fix the ones that look identical but work anyway.
>>include_path3.diff: fix <../path/file.h> to be "../../../path/file.h"
>>to make it obvious that they're not in src/include
>>
>>Abuild tested.
>>
>>Signed-off-by: Myle
Author: myles
Date: Mon Jul 26 23:45:11 2010
New Revision: 5668
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5668
Log:
Make include paths more consistent. Fixes compilation errors for me.
Signed-off-by: Myles Watson
Acked-by: Nils Jacobs
Modified:
trunk/src/mainboard/amd/dbm69
Myles wrote:
>Linux does it that way. It keeps all of the architecture-specific
>code and includes under arch/
>
>include_path.diff: fix the ones that are broken for me.
>include_path2.diff: fix the ones that look identical but work anyway.
>include_path3.diff: fix <../path/file.h> to be "../../..
On 7/26/10 9:28 PM, Myles Watson wrote:
> I was thinking of some of the ACPI code, that is not
> mainboard-dependent but chipset-dependent. That's been slowly moving
> to the chipset directories.
>
If we can get rid of exceptions by cleaning more code up in this way we
should certainly do it.
St
On Mon, Jul 26, 2010 at 1:22 PM, Peter Stuge wrote:
> Patrick Georgi wrote:
>> > .h files outside include/
>> > They should probably be moved to include/
>>
>> Mainboards need to include chipset specific information, and I'd
>> like to avoid moving all that into include/ if possible.
>
> Why not d
Patrick Georgi wrote:
> > .h files outside include/
> > They should probably be moved to include/
>
> Mainboards need to include chipset specific information, and I'd
> like to avoid moving all that into include/ if possible.
Why not do it?
Myles Watson wrote:
> I think that's a reasonable exce
On Mon, Jul 26, 2010 at 12:01 PM, Peter Stuge wrote:
> Myles Watson wrote:
>> >> 3. Just use the path
>> >
>> > I think this is *by far* the cleanest approach!
>>
>> I agree that it looks the best. I'm worried that it introduces
>> ambiguity.
>>
>> #include
>>
>> Could look in src/path/file.h or
On Mon, Jul 26, 2010 at 12:57 PM, Patrick Georgi wrote:
> Am 26.07.2010 20:01, schrieb Peter Stuge:
>> I'm not sure that I feel good about .h files outside include/ being
>> referenced from other parts of the code. They should probably be
>> moved to include/ if they are needed in more than one pl
Am 26.07.2010 20:01, schrieb Peter Stuge:
> I'm not sure that I feel good about .h files outside include/ being
> referenced from other parts of the code. They should probably be
> moved to include/ if they are needed in more than one place..
Mainboards need to include chipset specific information,
Myles Watson wrote:
> >> 3. Just use the path
> >
> > I think this is *by far* the cleanest approach!
>
> I agree that it looks the best. I'm worried that it introduces
> ambiguity.
>
> #include
>
> Could look in src/path/file.h or src/include/path/file.h and others
>
> Is that what we want?
On Mon, Jul 26, 2010 at 11:09 AM, Peter Stuge wrote:
> Myles Watson wrote:
>> There are many ways to fix it, but I'm not sure which one is the
>> correct (most future-proof) way.
> ..
>> 3. Just use the path
>
> I think this is *by far* the cleanest approach!
I agree that it looks the best. I'm
Myles Watson wrote:
> There are many ways to fix it, but I'm not sure which one is the
> correct (most future-proof) way.
..
> 3. Just use the path
I think this is *by far* the cleanest approach!
//Peter
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/c
There are a couple of boards that don't compile for me with crossgcc.
Here's a representative error:
src/mainboard/asus/a8v-e_se/mptable.c:23:54: error:
src/include/../../../southbridge/via/vt8237r/vt8237r.h: Permission
denied
The problem is that the compiler is looking for the file
../../../sout
Ticket
Owner
Status
Description
#167 ste...@coresystems.de new Support for new ION2 (Intel NM10 chipset)
#164 ste...@coresystems.de new Building Coreboot v4 r/5554 fails mysteriously on Debian lenny and etch (x86)
#163
Hi,
As requested on IRC, here's some additional info.
Unfortunately I was unable to find any specs or a datasheet for
IT8707F. What I did find was this (old) note from the lm-sensors
project wiki:
"ITE IT8707F: (2003-08-23) ITE won't release a datasheet, but says the
sensor part is identical to I
Am 26.07.2010 12:09, schrieb ali hagigat:
> Thank you very much for the reply. What is the name of the RPM of
> scanbuild or clang for Fedora, Linux? clang is the name of the
> package?
Your previous question was good, it was about something specific to
coreboot, even though you could try to decide
Thank you very much for the reply. What is the name of the RPM of
scanbuild or clang for Fedora, Linux? clang is the name of the
package?
On 7/26/10, Patrick Georgi wrote:
> Am 26.07.2010 11:58, schrieb ali hagigat:
>> I wonder if any body can say what is the major effect of
>> INNER_SCANBUILD sy
Am 26.07.2010 11:58, schrieb ali hagigat:
> I wonder if any body can say what is the major effect of
> INNER_SCANBUILD symbol in making the project?
It's used when building coreboot under scanbuild (part of clang), which
does static analysis of the code.
Unless you want to tweak that particular pi
I wonder if any body can say what is the major effect of
INNER_SCANBUILD symbol in making the project?
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
28 matches
Mail list logo
