Dear coreboot readers!
This is the automatic build system of coreboot.
The developer "oxygene" checked in revision 6377 to
the coreboot repository. This caused the following
changes:
Change Log:
libpayload: Move stdin/stdout/stderr away from headers
Otherwise they exist in several object files
Author: oxygene
Date: Thu Feb 24 08:43:37 2011
New Revision: 6378
URL: https://tracker.coreboot.org/trac/coreboot/changeset/6378
Log:
Tyan/s2735 doesn't need to define its own hard_reset function anymore.
The southbridge already provides hard_reset.
Signed-off-by: Patrick Georgi
Acked-by: Patri
Scott Duplichan wrote:
> I accidentally did the 'svn cp' step interactively instead of by
> patch. The attached patch completes the work of converting AMD
> Persimmon into ASRock E350M1.
Good stuff. Some simple comments, then I'll ack.
> A video option rom needs to be added to support the built-
Author: oxygene
Date: Thu Feb 24 08:18:11 2011
New Revision: 6377
URL: https://tracker.coreboot.org/trac/coreboot/changeset/6377
Log:
libpayload: Move stdin/stdout/stderr away from headers
Otherwise they exist in several object files, confusing the linker
Signed-off-by: Patrick Georgi
Acked-by:
Georgi, Patrick wrote:
> From 07607cbb537033da33ec4d33178a99c32b19a699 Mon Sep 17 00:00:00 2001
> From: Patrick Georgi
> Date: Tue, 15 Feb 2011 15:46:48 +0100
> Subject: [PATCH] libpayload: Move stdin/stdout/stderr away from headers
>
> Otherwise they exist in several object files, confusing the
Am Dienstag, den 22.02.2011, 11:23 -0700 schrieb Marc Jones:
> This change breaks the default config build of libpayload. The problem
> is stdio.h and curses.h having FILE definitions. stdio.h include is
> commented out of curses.h, but adding it causes multiple definition
> issues. Do you have th
Peter wrote:
]Great! Use svn cp to create the directory, then put your changes in
]there, and then svn diff should create the corresponding small patch
]that you sent already. I'm happy to ack. This looks like a nice board
]for a media center system.
]
]//Peter
Thanks Peter. I accidentally did th
Dear coreboot readers!
This is the automatic build system of coreboot.
The developer "sduplichan" checked in revision 6376 to
the coreboot repository. This caused the following
changes:
Change Log:
Build Log:
Compilation of tyan:s2735 is still broken
See the error log at
http://qa.coreboot.o
-Original Message-
From: coreboot-boun...@coreboot.org [mailto:coreboot-boun...@coreboot.org] On
Behalf Of repository service
Sent: Wednesday, February 23, 2011 11:01 PM
To: coreboot@coreboot.org
Subject: [coreboot] [commit] r6376 - trunk/src/mainboard/asrock/e350m1
Author: sduplichan
Da
Author: sduplichan
Date: Thu Feb 24 06:00:33 2011
New Revision: 6376
URL: https://tracker.coreboot.org/trac/coreboot/changeset/6376
Log:
Added:
trunk/src/mainboard/asrock/e350m1/ (props changed)
- copied from r6352, trunk/src/mainboard/amd/persimmon/
--
coreboot mailing list: corebo
Scott Duplichan wrote:
> > The patch modifies the persimmon project and is for development
> > use, not for commit.
>
> ]What would you like to add functionally before commiting?
>
> I guess the main thing to do before a commit is to branch persimmon
> and make an asrock e350m1 project. I suspect
-Original Message-
From: coreboot-boun...@coreboot.org [mailto:coreboot-boun...@coreboot.org] On
Behalf Of Peter Stuge
Sent: Wednesday, February 23, 2011 10:15 PM
To: coreboot@coreboot.org
Subject: Re: [coreboot] Coreboot for AMD Fusion family 14h: ASRock E350M1
Scott Duplichan wrote:
> T
Scott Duplichan wrote:
> The attached patch gets coreboot going on the ASRock E350M1 board.
> This is an AMD family 14h Fusion board I bought for US $120, including
> processor. The video option rom is from the supplied UEFI BIOS.
>
> The patch modifies the persimmon project and is for development
The attached patch gets coreboot going on the ASRock E350M1 board.
This is an AMD family 14h Fusion board I bought for US $120, including
processor. The video option rom is from the supplied UEFI BIOS.
The patch modifies the persimmon project and is for development use,
not for commit. With this p
Hi,
I've attempted to use the rs780 and sb800 code on a AM3 870 + SB850
board. Raminit seems to go okay, as does the first bits of ramstage.
However, ramstage fails after the first two passes through
rs780_enable(). It stalls in get_vid_did() reading PCI config space
of device 2 (or 4). Also, t
* Bao, Zheng [110223 03:31]:
> The ldscript_fallback_cbfs.lb is only for the romstage. It does
> nothing to change the building of ramstage. And it doesn't have area
> like .data, which can be read and wrote.
>
> From the attached build output, we can see that only crt0.romstage.o
> changes .roda
Am 23.02.2011 09:45, schrieb Bao, Zheng:
> The code between 465 and 467 is confusing. Why doesn't it align to
> alignment? What if we delete these 3 lines?
The kind of alignment that cbfstool seeks is, for alignment "ALIGN",
look for an address so that the file data is inside a block sized ALIGN,
a
On Tue 22/02/11 23:58 , "Alex G." wrote:
> On 02/22/2011 02:47 AM, Peter Stuge wrote:
> > Xavi Drudis Ferran wrote:
> >> Does everyone prefer to have it not include update_microcode.c and
> >> change romstage.c in those boards that call update_microcode(...) ?
> >
> > At least I like this bette
In src/arch/x86/Makefile.bootblock.inc:
###
75 # Build the romstage
76 $(obj)/coreboot.romstage: $(obj)/coreboot.pre1 $$(romstage-objs)
$(obj)/romstage/ldscript.ld
77 @printf "LINK $(subst $(obj)/,,$(@))\n"
78
19 matches
Mail list logo
