[coreboot] [PATCH] [FILO] Artec loader with NULLFS
load_linux_kernel() checks using_devsize, so we need to clear it if we are using Artec loader without a file system. Signed-off-by: Nathan Williams Index: i386/artecboot.c === --- i386/artecboot.c(revision 140) +++ i386/artecboot.c(working copy) @@ -126,6 +126,7 @@ part_start = bootHdr.kernelStart >> DEV_SECTOR_BITS; part_length = ((bootHdr.kernelSize-1) >> DEV_SECTOR_BITS) + 1; filemax = bootHdr.kernelSize; + using_devsize = 0; linux_load(file, bootHdr.cmdLine); } -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] [FILO] Artec loader with initrd
When using Artec loader and no file system, use dev_name for initrd
instead of "flashb".
Signed-off-by: Nathan Williams
Index: fs/filesys.h
===
--- fs/filesys.h(revision 140)
+++ fs/filesys.h(working copy)
@@ -86,6 +86,7 @@
/* Ditto */
#define current_slice 0
+extern char dev_name[256];
extern unsigned long part_start;
extern unsigned long part_length;
extern int filepos;
Index: fs/blockdev.c
===
--- fs/blockdev.c (revision 140)
+++ fs/blockdev.c (working copy)
@@ -31,8 +31,7 @@
static unsigned char buf_cache[NUM_CACHE][DEV_SECTOR_SIZE];
static unsigned long cache_sect[NUM_CACHE];
-static char dev_name[256];
-
+char dev_name[256];
int dev_type = -1;
int dev_drive = -1;
unsigned long part_start;
Index: i386/artecboot.c
===
--- i386/artecboot.c(revision 140)
+++ i386/artecboot.c(working copy)
@@ -107,8 +107,8 @@
else
{
// we are using a 'fake' filesystem, so use the
image offset
- sprintf(initrdParam, "
initrd=flashb@0x%x,0x%x",
- bootHdr.initrdStart,
bootHdr.initrdSize);
+ sprintf(initrdParam, " initrd=%s@0x%x,0x%x",
+ dev_name, bootHdr.initrdStart,
bootHdr.initrdSize);
}
debug("adding initrd parameter: %s\n", initrdParam);
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot for AMD Fusion family 14h: ASRock E350M1
Stefan Reinauer wrote:
]Any chance to move the SSDTs to the northbridge/southbridge/cpu
]directory instead of having them live under mainboard?
It looks like SSDT2,3,4,5 are never used and can be removed from
this project.
Thanks,
Scott {
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot for AMD Fusion family 14h: ASRock E350M1
Stefan Reinauer wrote: ]> +#define SERIAL_DEV PNP_DEV(0x2e, W83627HF_SP1) ]if CONFIG_SIO_PORT is defined in Kconfig (why?) we could as well use it ]in romstage.c. Is there a chance to remove it from Kconfig instead? Certainly the two occurrences of 2e is not ideal. This change works: -#define SERIAL_DEV PNP_DEV(0x2e, W83627HF_SP1) +#define SERIAL_DEV PNP_DEV(CONFIG_SIO_PORT, W83627HF_SP1) I believe most SIOs have a strap option for 4e, so presumably this address needs to be project selectable by some method. Phoenix legacy BIOS actually figures it out at runtime. That method seems dangerous to me and makes stepping through the code tedious. If we remove it from kconfig, would it just be local to romstage.c? I suppose this would be a separate patch, given the number of projects affected. Thanks, Scott -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH 3/3] Move coreboot specific rules and setup to toplevel Makefile.inc
* Georgi, Patrick [110222 15:35]: > Am Donnerstag, den 17.02.2011, 20:05 +0100 schrieb Stefan Reinauer: > > I agree we want this, though. Can you please put Makefile.inc in src/? > We currently have subdirs-y = ... util/cbfstool in there. That would be > ++ugly with src/Makefile.inc. hm... as ugly as /Makefile and /Makefile.inc? What's needed other than a subdirs-y += ../util/cbfstool ? > However we could move the src/* related things and the coreboot rules > into a new file src/Makefile.inc, so toplevel Makefile.inc only contains > the KERNELVERSION (I fixed that one, thanks for reporting it), and > subdirs-y = src util/cbfstool util/romcc I'd prefer not to add more Makefiles than needed. Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] 870 attempt
* Scott Duplichan [110224 18:07]: > -Original Message- > From: coreboot-boun...@coreboot.org [mailto:coreboot-boun...@coreboot.org] On > Behalf Of Marc Jones > Sent: Thursday, February 24, 2011 10:45 AM > To: Jonathan A. Kollasch > Cc: coreboot@coreboot.org > Subject: Re: [coreboot] 870 attempt > > On Thu, Feb 24, 2011 at 7:23 AM, Jonathan A. Kollasch > wrote: > > On Thu, Feb 24, 2011 at 02:14:07AM +, Jonathan A. Kollasch wrote: > >> 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, the rs780 HT init code thinks the link should > >> run at 200MHz, maybe that's related. > > > > Attached is the diff, and console output there from. > > (Mainboard directory is a svn cp of bimini_fam10.) > > > > >rs780_htinit cpu_ht_freq=0. > >rs780_htinit: HT1 mode > > ]It looks it had problems getting the HT frequency from the CPU. Both > ]sides have to agree on what is capable. You may need to look at the > ]CPU HT code for a hint on why it reports what it does to the SB. > ] > ]Marc > > Also remember that the family 10h swap list problem still exists. > There are some old patches and discussion that might be useful. > Here is an example: > > http://www.mail-archive.com/coreboot@coreboot.org/msg27356.html Acked-by: Stefan Reinauer -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot for AMD Fusion family 14h: ASRock E350M1
Any chance to move the SSDTs to the northbridge/southbridge/cpu
directory instead of having them live under mainboard?
* Scott Duplichan [110224 07:05]:
> Index: src/mainboard/asrock/e350m1/acpi/ssdt2.asl
> ===
> --- src/mainboard/asrock/e350m1/acpi/ssdt2.asl(revision 6375)
> +++ src/mainboard/asrock/e350m1/acpi/ssdt2.asl(working copy)
> @@ -17,7 +17,7 @@
> * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
> */
>
> -DefinitionBlock ("SSDT2.aml", "SSDT", 1, "AMD-FAM10", "AMDACPI", 100925440)
> +DefinitionBlock ("SSDT2.aml", "SSDT", 1, "AMD-FAM14", "AMDACPI", 100925440)
> {
> Scope (_SB)
> {
> Index: src/mainboard/asrock/e350m1/acpi/ssdt3.asl
> ===
> --- src/mainboard/asrock/e350m1/acpi/ssdt3.asl(revision 6375)
> +++ src/mainboard/asrock/e350m1/acpi/ssdt3.asl(working copy)
> @@ -17,7 +17,7 @@
> * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
> */
>
> -DefinitionBlock ("SSDT3.aml", "SSDT", 1, "AMD-FAM10", "AMDACPI", 100925440)
> +DefinitionBlock ("SSDT3.aml", "SSDT", 1, "AMD-FAM14", "AMDACPI", 100925440)
> {
> Scope (_SB)
> {
> Index: src/mainboard/asrock/e350m1/acpi/ssdt4.asl
> ===
> --- src/mainboard/asrock/e350m1/acpi/ssdt4.asl(revision 6375)
> +++ src/mainboard/asrock/e350m1/acpi/ssdt4.asl(working copy)
> @@ -17,7 +17,7 @@
> * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
> */
>
> -DefinitionBlock ("SSDT4.aml", "SSDT", 1, "AMD-FAM10", "AMDACPI", 100925440)
> +DefinitionBlock ("SSDT4.aml", "SSDT", 1, "AMD-FAM14", "AMDACPI", 100925440)
> {
> Scope (_SB)
> {
> Index: src/mainboard/asrock/e350m1/acpi/ssdt5.asl
> ===
> --- src/mainboard/asrock/e350m1/acpi/ssdt5.asl(revision 6375)
> +++ src/mainboard/asrock/e350m1/acpi/ssdt5.asl(working copy)
> @@ -18,7 +18,7 @@
> */
>
>
> -DefinitionBlock ("SSDT5.aml", "SSDT", 1, "AMD-FAM10", "AMDACPI", 100925440)
> +DefinitionBlock ("SSDT5.aml", "SSDT", 1, "AMD-FAM14", "AMDACPI", 100925440)
> {
> Scope (_SB)
> {
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot for AMD Fusion family 14h: ASRock E350M1
* Scott Duplichan [110224 05:03]: > 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 patch it can boot DOS from a SATA drive. > It can also boot WinPE from a USB flash drive. I was unable to get > Windows setup to run. > > The board has a socketed SPI flash BIOS chip and a serial port > header. The SIO is Nuvoton NCT5572D. Using coreboot's existing > Winbond w83627hf is a good enough match to at least get the serial > port and keyboard going. > > Here are pictures of the board: > http://notabs.org/pictures/ASRock-E350M1/ > +#define SERIAL_DEV PNP_DEV(0x2e, W83627HF_SP1) > > > if CONFIG_SIO_PORT is defined in Kconfig (why?) we could as well use it in romstage.c. Is there a chance to remove it from Kconfig instead? -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Fam10 FIDVID in SVI 01/25
On Thu, Feb 24, 2011 at 02:31:29PM +0100, Georgi, Patrick wrote: > Am Donnerstag, den 17.02.2011, 07:35 +0100 schrieb xdrudis: > > see patch > Any opinion on these patches? Patch 1-8 seem to be refactorings only, > and splitting functions into smaller logical units looks good to me, but > I'd like to hear from someone deeper in the AMD code. > Yes, if these 8 are not refactorings, then it's a bug. I know it's a little work to review it all, but it does not have to be one person. You can review just one patch, maybe. Testing is maybe better to do with all of them, or all without negative reviews, or something. I've tested them one by one and it is a little a waste of time. And I haven't found a single one that fixes it for me. Must be a combination, possibly not all but not sure which ones. They're secuential although not each and every one needs all previous ones. By the way testing for both SVI and PVI is welcome (for AMD FAM 10). I don't intend to break PVI, but I can't test it. Some of the later ones may be a little paranoid or a matter of taste but I tried to split them in small pieces so they can be rejected or modified. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] RFC AMD powernow generation for pre fam 0fh
* Rudolf Marek [110224 21:04]: > Hi all > > Attaching update patch. Not much changed, only comments added. > > It adds support for automatic PSS object generation for AMD pre fam > Fh CPU. Those CPUs require a hardcoded table, which I managed to > rewrite during one particularly boring flight. Too pity it is only > for Opteron CPUs. Someone needs to finish the second PDF for All > others Athlons and Semprons. > > Also it enables the FID/VID changes in SB. Jakllsch had some > troubles with that too but on am2 CPU. Those bits are only > documented in SB600. They arent in RRG RPR and BDG. > > Signed-off-by:Rudolf Marek Acked-by: Stefan Reinauer > > Thanks, > Rudolf Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [commit] r6380 - in trunk/src: cpu/amd/model_fxx northbridge/amd/amdk8
* repository service [110224 15:35]:
> Modified: trunk/src/cpu/amd/model_fxx/model_fxx_init.c
> ==
> --- trunk/src/cpu/amd/model_fxx/model_fxx_init.c Thu Feb 24 14:54:10
> 2011(r6379)
> +++ trunk/src/cpu/amd/model_fxx/model_fxx_init.c Thu Feb 24 15:35:42
> 2011(r6380)
> @@ -264,7 +264,10 @@
>
> /* See if we scrubbing should be enabled */
> enable_scrubbing = 1;
> - get_option(&enable_scrubbing, "hw_scrubber");
> + if( get_option(&enable_scrubbing, "hw_scrubber") < 0 )
> + {
> + enable_scrubbing = CONFIG_HW_SCRUBBER;
> + }
small style note: if() wants the curly brackets on the same line, new
functions don't.
Also, does it make sense to initialize enable_scrubbing like this if
it's overwritten anyways?
Stefan
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [commit] r6378 - trunk/src/mainboard/tyan/s2735
* repository service [110224 08:43]: > 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: Patrick Georgi Why was this exposed by the Makefile restructuring but never occurred before? -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] disabling microcode update
Hi Xavi, On Wed, Feb 23, 2011 at 02:51:46PM +0100, Xavi Drudis Ferran wrote: > If you mean visible in the source code: > > Option A: > the patch I sent changes only one .c file and one Kconfig file. The function > update_microcode() > would still exist and it would do the update or do nothing depending on > CONFIG_UPDATE_CPU_MICROCODE. > No other files would need touching. > This is what my software engineer intuition recommends, centralise changes in > one place, change > the behaviour of a procedure depending on configuration options, don't change > every single place > that procedure is called. > > But people have considered this to be too little visible, or too little > invasive for its heretic nature, > or I don't quite understand what, and they've asked > > Option B: > > change src/cpu/amd/model_10xxx/Makefile.inc > so that update_microcode.c does not get compiled in. when > CONFIG_UPDATE_CPU_MICROCODE is false > since in that case the function update_microcode(...) would be undefined, we > would have to also > change all files with a call to it, by placing an #if around the call. Those > files are > src/cpu/amd/model_10xxx/init-cpus.c > src/mainboard/*/*/romstage.c > (and by */* I mean all or some of the fam 10 boards, not all boards). This is the option that Stepan and Peter prefer, so this seems like the best way forward? I'd test and ack this patch. Thanks! Ward. -- Ward Vandewege Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] RFC AMD powernow generation for pre fam 0fh
Hi all
Attaching update patch. Not much changed, only comments added.
It adds support for automatic PSS object generation for AMD pre fam Fh CPU.
Those CPUs require a hardcoded table, which I managed to rewrite during one
particularly boring flight. Too pity it is only for Opteron CPUs. Someone needs
to finish the second PDF for All others Athlons and Semprons.
Also it enables the FID/VID changes in SB. Jakllsch had some troubles with that
too but on am2 CPU. Those bits are only documented in SB600. They arent in RRG
RPR and BDG.
Signed-off-by:Rudolf Marek
Thanks,
Rudolf
Index: src/cpu/amd/model_fxx/powernow_acpi.c
===
--- src/cpu/amd/model_fxx/powernow_acpi.c.orig 2011-01-16 00:32:02.0 +0100
+++ src/cpu/amd/model_fxx/powernow_acpi.c 2011-02-21 08:19:27.690249890 +0100
@@ -30,10 +30,9 @@
#include
#include
-#if CONFIG_K8_REV_F_SUPPORT
static int write_pstates_for_core(u8 pstate_num, u16 *pstate_feq, u8 *pstate_vid,
u8 *pstate_fid, u32 *pstate_power, int coreID,
-u32 pcontrol_blk, u8 plen, u8 onlyBSP)
+u32 pcontrol_blk, u8 plen, u8 onlyBSP, u32 control)
{
int lenp, lenpr, i;
@@ -50,16 +49,8 @@
lenp = acpigen_write_package(pstate_num);
for (i = 0;i < pstate_num;i++) {
- u32 control, status;
-
- control =
- (0x3 << 30) | /* IRT */
- (0x2 << 28) | /* RVO */
- (0x1 << 27) | /* ExtType */
- (0x2 << 20) | /* PLL_LOCK_TIME */
- (0x0 << 18) | /* MVS */
- (0x5 << 11) | /* VST */
- (pstate_vid[i] << 6) |
+ u32 status, c2;
+ c2 = control | (pstate_vid[i] << 6) |
pstate_fid[i];
status =
(pstate_vid[i] << 6) |
@@ -69,7 +60,7 @@
pstate_power[i],
0x64,
0x7,
- control,
+ c2,
status);
}
/* update the package size */
@@ -81,6 +72,8 @@
acpigen_patch_len(lenpr - 2);
return lenpr;
}
+
+#if CONFIG_K8_REV_F_SUPPORT
/*
* Details about this algorithm , refert to BDKG 10.5.1
* Two parts are included, the another is the DSDT reconstruction process
@@ -90,7 +83,7 @@
{
int len;
u8 processor_brand[49];
- u32 *v;
+ u32 *v, control;
struct cpuid_result cpuid1;
struct power_limit_encoding {
@@ -367,15 +360,288 @@
len = 0;
+ control = (0x3 << 30) | /* IRT */
+ (0x2 << 28) | /* RVO */
+ (0x1 << 27) | /* ExtType */
+ (0x2 << 20) | /* PLL_LOCK_TIME */
+ (0x0 << 18) | /* MVS */
+ (0x5 << 11); /* VST */
+
+ for (index = 0; index < (cmp_cap + 1); index++) {
+ len += write_pstates_for_core(Pstate_num, Pstate_feq, Pstate_vid,
+Pstate_fid, Pstate_power, index,
+pcontrol_blk, plen, onlyBSP, control);
+ }
+
+ return len;
+}
+
+#else
+
+
+static uint8_t vid_to_reg(uint32_t vid)
+{
+ return (1550 - vid) / 25;
+}
+
+static uint32_t vid_from_reg(uint8_t val)
+{
+ return (val == 0x1f ? 0 : 1550 - val * 25);
+}
+
+static uint8_t freq_to_fid(uint32_t freq)
+{
+ return (freq - 800) / 100;
+}
+/* Return a frequency in MHz, given an input fid */
+static uint32_t fid_to_freq(uint32_t fid)
+{
+ return 800 + (fid * 100);
+}
+
+#define MAXP 7
+
+struct pstate {
+ uint16_t freqMhz; /* in MHz */
+ uint16_t voltage; /* in mV */
+ uint16_t tdp; /* in W * 10 */
+};
+
+struct cpuentry {
+ uint16_t modelnr; /* numeric model value, unused in code */
+ uint8_t brandID; /* CPUID 8000_0001h EBX [11:6] (BrandID) */
+ uint32_t cpuid; /* CPUID 8000_0001h EAX [31:0] (CPUID) */
+ uint8_t maxFID; /* FID/VID Status MaxFID Field */
+ uint8_t startFID; /* FID/VID Status StartFID Field */
+ uint16_t pwr:12; /* Thermal Design Power of Max P-State *10 (fixed point) */
+ /* Other MAX P state are read from CPU, other P states in following table */
+ struct pstate pstates[MAXP];
+};
+
+struct cpuentry entr[] = {
+ /* rev E single core, check OSA152FAA5BK */
+ {152, 0xc, 0x20f51, 0x12, 0x12, 926,
+ {{2400, 1350, 900}, {2200, 1300, 766},
+ {2000, 1250, 651}, {1800, 1200, 522},
+ {1000, 1100, 320}}},
+ {252, 0x10, 0x20f51, 0x12, 0x12, 926,
+ {{2400, 1350, 900}, {2200, 1300, 766},
+ {2000, 1250, 651}, {1800, 1200, 522},
+ {1000, 1100, 320}}},
+ {852, 0x14, 0x20f51, 0x12, 0x12, 926,
+ {{2400, 1350, 900}, {2200, 1300, 766},
+ {2000, 1250, 651}, {1800, 1200, 522},
+ {1000, 1100, 320}}},
+ {254, 0x10, 0x20f51, 0x14, 0x14, 926,
+ {{2600, 1350, 902}, {2400, 1300, 770},
+ {2200, 1250, 657}, {2000, 1200, 559},
+ {1800, 1150, 476}, {1000, 1100, 361}}},
+ {854, 0x14, 0x20f51, 0x14, 0x14, 926,
+ {{2600, 1350, 902}, {2400, 1300, 770},
+ {2200, 1250, 657}, {2000, 1200, 559},
+ {1800, 1150, 476}, {1000, 1100, 361}}},
+ {242, 0x10, 0x20f51, 0x8, 0x8, 853,
+ {}},
+ {842, 0x10, 0x20f51, 0x8, 0x8, 853,
+ {}},
+ {244, 0x10, 0x20f51, 0xa, 0xa, 853,
+ {{1000, 1100, 378}}},
+ {844, 0x14, 0x20f51, 0xa, 0xa, 853,
+ {{1000, 1100, 378}}},
+ {246, 0x10, 0x20f51, 0xc, 0xc, 853,
+ {{1800, 1350, 853},
+ {1000, 1100, 378}}},
+ {846, 0x14, 0x20f51, 0xc, 0xc, 853,
+ {{1800, 1350, 853},
+ {1000, 1100, 378}}},
+ {242, 0x10,
Re: [coreboot] 870 attempt
Jonathan A. Kollasch wrote: ]That seems to let it detect HT3 before warm reset, and the warm ]reset succeeded, something that didn't happen when I attempted to ]force HT3. Unfortunately that didn't also fix the stall on ]config space access. ] ] Jonathan Kollasch You could try disabling device 2 and 4 in devicetree.cb as a way to see what other problems remain. I suppose you might need device 2 for a graphics card. It might be possible that some action is needed to turn on clocks or slot power. I also noticed the last line of rs780_ht.c references PCI device ID 9600 (PCI_DEVICE_ID_AMD_RS780_HT). Not sure if revising that is important. Thanks, Scott -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot for AMD Fusion family 14h: ASRock E350M1
Peter wrote:
]Scott Duplichan wrote:
]> ]> A video option rom needs to be added to support the built-in uma
]> ]> graphics.
]> ]
]> ]Does the default filename match what was extracted from factory EFI?
]>
]> I do not know of a way to recover the original filename of the
]> extracted video BIOS. After booting the factory BIOS, I saved
]> physical memory range C-C to a file with a made up name.
]Ahh! And that worked? It doesn't always. The original filename would
]be discovered by using bios_extract or another similar tool on the
]factory firmware image. That also doesn't work always, but it's worth
]a try.
I tried AMIBCP.exe. That is the only tool I have for AMI Aptio UEFI BIOS.
It displays lots of strings, but no filenames. Wonderful UEFI uses GUIDs
internally for option rom tracking.
]> > +++ src/mainboard/asrock/e350m1/dsdt.asl (working copy)
]> > @@ -23,7 +23,7 @@
]> >"DSDT", /* Signature */
]> >0x02, /* DSDT Revision, needs to be 2 for 64bit */
]> >"AMD ", /* OEMID */
]> > - "PERSIMMO", /* TABLE ID */
]> > + "E350M1 ", /* TABLE ID */
]>
]> ]Also change AMD?
]> Thanks for pointing this out, I changed it.
]> In the revised patch, I also changed it in mptable.c
]
]Nice catch!
]> +++ src/mainboard/asrock/e350m1/mainboard.c (working copy)
]..
]> @@ -110,6 +110,6 @@
]> return 0;
]> }
]> struct chip_operations mainboard_ops = {
]> -CHIP_NAME("AMD PERSIMMON Mainboard")
]> -.enable_dev = persimmon_enable,
]> +CHIP_NAME(CONFIG_MAINBOARD_VENDOR " " CONFIG_MAINBOARD_PART_NUMBER "
Mainboard")
]> +.enable_dev = e350m1_enable,
]
]Some whitespace on the CHIP_NAME line seems off. After that and if
]you find something out about the VGA BIOS filename it's
Oops, got it.
Acked-by: Peter Stuge
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] 870 attempt
On Thu, Feb 24, 2011 at 11:07:04AM -0600, Scott Duplichan wrote: > -Original Message- > From: coreboot-boun...@coreboot.org [mailto:coreboot-boun...@coreboot.org] On > Behalf Of Marc Jones > Sent: Thursday, February 24, 2011 10:45 AM > To: Jonathan A. Kollasch > Cc: coreboot@coreboot.org > Subject: Re: [coreboot] 870 attempt > > On Thu, Feb 24, 2011 at 7:23 AM, Jonathan A. Kollasch > wrote: > > On Thu, Feb 24, 2011 at 02:14:07AM +, Jonathan A. Kollasch wrote: > >> 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, the rs780 HT init code thinks the link should > >> run at 200MHz, maybe that's related. > > > > Attached is the diff, and console output there from. > > (Mainboard directory is a svn cp of bimini_fam10.) > > > > >rs780_htinit cpu_ht_freq=0. > >rs780_htinit: HT1 mode > > ]It looks it had problems getting the HT frequency from the CPU. Both > ]sides have to agree on what is capable. You may need to look at the > ]CPU HT code for a hint on why it reports what it does to the SB. > ] > ]Marc > > Also remember that the family 10h swap list problem still exists. > There are some old patches and discussion that might be useful. > Here is an example: > > http://www.mail-archive.com/coreboot@coreboot.org/msg27356.html That seems to let it detect HT3 before warm reset, and the warm reset succeeded, something that didn't happen when I attempted to force HT3. Unfortunately that didn't also fix the stall on config space access. Jonathan Kollasch -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot for AMD Fusion family 14h: ASRock E350M1
Scott Duplichan wrote:
> ]> A video option rom needs to be added to support the built-in uma
> ]> graphics.
> ]
> ]Does the default filename match what was extracted from factory EFI?
>
> I do not know of a way to recover the original filename of the
> extracted video BIOS. After booting the factory BIOS, I saved
> physical memory range C-C to a file with a made up name.
Ahh! And that worked? It doesn't always. The original filename would
be discovered by using bios_extract or another similar tool on the
factory firmware image. That also doesn't work always, but it's worth
a try.
> > +++ src/mainboard/asrock/e350m1/dsdt.asl(working copy)
> > @@ -23,7 +23,7 @@
> > "DSDT", /* Signature */
> > 0x02, /* DSDT Revision, needs to be 2 for 64bit */
> > "AMD ", /* OEMID */
> > - "PERSIMMO", /* TABLE ID */
> > + "E350M1 ", /* TABLE ID */
>
> ]Also change AMD?
> Thanks for pointing this out, I changed it.
> In the revised patch, I also changed it in mptable.c
Nice catch!
> +++ src/mainboard/asrock/e350m1/mainboard.c (working copy)
..
> @@ -110,6 +110,6 @@
> return 0;
> }
> struct chip_operations mainboard_ops = {
> - CHIP_NAME("AMD PERSIMMON Mainboard")
> - .enable_dev = persimmon_enable,
> +CHIP_NAME(CONFIG_MAINBOARD_VENDOR " " CONFIG_MAINBOARD_PART_NUMBER "
> Mainboard")
> + .enable_dev = e350m1_enable,
Some whitespace on the CHIP_NAME line seems off. After that and if
you find something out about the VGA BIOS filename it's
Acked-by: Peter Stuge
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Fam10 FIDVID in SVI 01/25
On Thu, Feb 24, 2011 at 6:31 AM, Georgi, Patrick wrote: > Am Donnerstag, den 17.02.2011, 07:35 +0100 schrieb xdrudis: >> see patch > Any opinion on these patches? Patch 1-8 seem to be refactorings only, > and splitting functions into smaller logical units looks good to me, but > I'd like to hear from someone deeper in the AMD code. > > > Patrick Yes, These patches are improvements in the SVI code, and I think we need to pull them in. I just haven't had a chance to test them or review them yet. I think that all new Fam10 systems are SVI now. If anyone else has time to try it, please do. Marc -- http://se-eng.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot for AMD Fusion family 14h: ASRock E350M1
Peter wrote:
]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-in uma
]> graphics.
]
]Does the default filename match what was extracted from factory EFI?
I do not know of a way to recover the original filename of the
extracted video BIOS. After booting the factory BIOS, I saved
physical memory range C-C to a file with a made up name.
> +++ src/mainboard/asrock/e350m1/dsdt.asl (working copy)
> @@ -23,7 +23,7 @@
> "DSDT", /* Signature */
> 0x02, /* DSDT Revision, needs to be 2 for 64bit */
> "AMD ", /* OEMID */
> - "PERSIMMO", /* TABLE ID */
> + "E350M1 ", /* TABLE ID */
]Also change AMD?
Thanks for pointing this out, I changed it.
In the revised patch, I also changed it in mptable.c
> +++ src/mainboard/asrock/e350m1/Kconfig (working copy)
..
> @@ -64,7 +64,7 @@
>
> config MAINBOARD_PART_NUMBER
> string
> -default "Persimmon"
> +default "e350m1"
]I think this should be uppercase.
Agree, I revised it.
> -#define CONFIG_VGA_BIOS_ID "1002,9804"
> +#define CONFIG_VGA_BIOS_ID "1002,9802"
]Why have this comment at all? Better just remove it.
Good point, I removed it.
> +++ src/mainboard/asrock/e350m1/mainboard.c (working copy)
..
> - printk(BIOS_INFO, "Mainboard Persimmon Enable. dev=0x%p\n", dev);
> + printk(BIOS_INFO, "Mainboard E350M1 Enable. dev=0x%p\n", dev);
]Please change to: "Mainboard " CONFIG_MAINBOARD_PART_NUMBER " Enable." ..
Good idea.
> @@ -110,6 +110,6 @@
> return 0;
> }
> struct chip_operations mainboard_ops = {
> - CHIP_NAME("AMD PERSIMMON Mainboard")
> - .enable_dev = persimmon_enable,
> + CHIP_NAME("ASRock E350M1 Mainboard")
> + .enable_dev = e350m1_enable,
]Same here.
]CHIP_NAME(CONFIG_MAINBOARD_VENDOR " " CONFIG_MAINBOARD_PART_NUMBER "
Mainboard")
Thanks.
> +++ src/mainboard/asrock/e350m1/romstage.c(working copy)
..
> @@ -52,7 +52,7 @@
> sb_poweron_init();
>
> post_code(0x31);
> -f81865f_enable_serial(SERIAL_DEV, CONFIG_TTYS0_BASE);
> + w83627hf_enable_serial(SERIAL_DEV, CONFIG_TTYS0_BASE);
]Whitespace?
Oops, I fixed it.
//Peter
Index: src/mainboard/asrock/e350m1/acpi/ssdt2.asl
===
--- src/mainboard/asrock/e350m1/acpi/ssdt2.asl (revision 6375)
+++ src/mainboard/asrock/e350m1/acpi/ssdt2.asl (working copy)
@@ -17,7 +17,7 @@
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*/
-DefinitionBlock ("SSDT2.aml", "SSDT", 1, "AMD-FAM10", "AMDACPI", 100925440)
+DefinitionBlock ("SSDT2.aml", "SSDT", 1, "AMD-FAM14", "AMDACPI", 100925440)
{
Scope (_SB)
{
Index: src/mainboard/asrock/e350m1/acpi/ssdt3.asl
===
--- src/mainboard/asrock/e350m1/acpi/ssdt3.asl (revision 6375)
+++ src/mainboard/asrock/e350m1/acpi/ssdt3.asl (working copy)
@@ -17,7 +17,7 @@
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*/
-DefinitionBlock ("SSDT3.aml", "SSDT", 1, "AMD-FAM10", "AMDACPI", 100925440)
+DefinitionBlock ("SSDT3.aml", "SSDT", 1, "AMD-FAM14", "AMDACPI", 100925440)
{
Scope (_SB)
{
Index: src/mainboard/asrock/e350m1/acpi/ssdt4.asl
===
--- src/mainboard/asrock/e350m1/acpi/ssdt4.asl (revision 6375)
+++ src/mainboard/asrock/e350m1/acpi/ssdt4.asl (working copy)
@@ -17,7 +17,7 @@
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*/
-DefinitionBlock ("SSDT4.aml", "SSDT", 1, "AMD-FAM10", "AMDACPI", 100925440)
+DefinitionBlock ("SSDT4.aml", "SSDT", 1, "AMD-FAM14", "AMDACPI", 100925440)
{
Scope (_SB)
{
Index: src/mainboard/asrock/e350m1/acpi/ssdt5.asl
===
--- src/mainboard/asrock/e350m1/acpi/ssdt5.asl (revision 6375)
+++ src/mainboard/asrock/e350m1/acpi/ssdt5.asl (working copy)
@@ -18,7 +18,7 @@
*/
-DefinitionBlock ("SSDT5.aml", "SSDT", 1, "AMD-FAM10", "AMDACPI", 100925440)
+DefinitionBlock ("SSDT5.aml", "SSDT", 1, "AMD-FAM14", "AMDACPI", 100925440)
{
Scope (_SB)
{
Index: src/mainboard/asrock/e350m1/devicetree.cb
===
--- src/mainboard/asrock/e350m1/devicetree.cb (revision 6375)
+++ src/mainboard/asrock/e350m1/devicetree.cb (working copy)
@@ -55,30 +55,46 @@
device pci 14.1 on end # IDE0x439c
device pci 14.2 on end # HDA0x4383
device pci 14.3
Re: [coreboot] 870 attempt
-Original Message- From: coreboot-boun...@coreboot.org [mailto:coreboot-boun...@coreboot.org] On Behalf Of Marc Jones Sent: Thursday, February 24, 2011 10:45 AM To: Jonathan A. Kollasch Cc: coreboot@coreboot.org Subject: Re: [coreboot] 870 attempt On Thu, Feb 24, 2011 at 7:23 AM, Jonathan A. Kollasch wrote: > On Thu, Feb 24, 2011 at 02:14:07AM +, Jonathan A. Kollasch wrote: >> 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, the rs780 HT init code thinks the link should >> run at 200MHz, maybe that's related. > > Attached is the diff, and console output there from. > (Mainboard directory is a svn cp of bimini_fam10.) > >rs780_htinit cpu_ht_freq=0. >rs780_htinit: HT1 mode ]It looks it had problems getting the HT frequency from the CPU. Both ]sides have to agree on what is capable. You may need to look at the ]CPU HT code for a hint on why it reports what it does to the SB. ] ]Marc Also remember that the family 10h swap list problem still exists. There are some old patches and discussion that might be useful. Here is an example: http://www.mail-archive.com/coreboot@coreboot.org/msg27356.html -- http://se-eng.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] 870 attempt
On Thu, Feb 24, 2011 at 7:23 AM, Jonathan A. Kollasch wrote: > On Thu, Feb 24, 2011 at 02:14:07AM +, Jonathan A. Kollasch wrote: >> 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, the rs780 HT init code thinks the link should >> run at 200MHz, maybe that's related. > > Attached is the diff, and console output there from. > (Mainboard directory is a svn cp of bimini_fam10.) > >rs780_htinit cpu_ht_freq=0. >rs780_htinit: HT1 mode It looks it had problems getting the HT frequency from the CPU. Both sides have to agree on what is capable. You may need to look at the CPU HT code for a hint on why it reports what it does to the SB. Marc -- http://se-eng.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] marketing coreboot after recent support of AMD board
Hi Paul, On Thu, Feb 24, 2011 at 6:18 AM, Paul Menzel wrote: > Dear coreboot community, > > > it is really amazing what happened in the last years and especially in > the last months. A lot of people came – for me – out of nowhere and did > great contributions. Also AMD did great with their latest contributions > [1]. > > Today, Scott sent a patch to the list to support the board ASRock E350M1 > [2, 3, 4]. If I am not mistaken there have been only a few cases, it > could be the first, where such a *recent* consumer board is supported by > coreboot. And that is the reason I am writing this message. > > This also means that most of the computer magazines (online – at least > in Europe – and print) have not yet published reviews and the board is > not yet old enough to be considered by consumers. You guys have more > experience than I on how these reviewer networks work, but is there an > easy way to get these boards tested by these people with coreboot? > > I came up with the following steps to be accomplished to reach that > goal. > > 1. Contact ASRock. Does anyone have contacts at ASRock to get > documentation or even hardware or man power? > 2. Get Windows running. Scott wrote that Windows does not boot yet. > Since the market share of Windows in the home desktop market is > still the biggest, that would of course be a requirement. > 3. Get GNU/Linux running. I think FLOSS users are more open to try > new things. So to get to them, GNU/Linux should at least be able > to boot. > 4. Wiki page and feature list. A page in our Wiki [5] should be set > up with detailed instructions on how to create an image, what > features (ACPI, power management, suspend/resume, connectors, …) > work and, when the patch is committed, what revision was tested. > 5. Comparison with the vendor BIOS. People of course would only be > interested if coreboot is superior to the vendor BIOS. And I > would imagine that normal users would be most interested in boot > time. Is coreboot faster? > 6. Flashrom support or “precompiled” images. To make it easy for > the reviewers and early adopters flashing using Flashrom should > work or precompiled images should be made available, if it is > legally possible, and even flash chips offered or send to the > reviewers which they can easily plug into the board and start > testing. Is there a foundation (e. g. FSF), organization or > cooperation (e. g. Google) which could sponsor to buy like > 200(?) spare flash chips, which then can be programmed? What > flash chips are compatible with this board? > 7. Contact everybody. When all of the above has been accomplished, > the magazines, reviewing sites, news sites, LUGs, communities > should be informed. Magazines get the chips send to and > consumers can order them from a coreboot developer. > > Do you think that is a feasible roadmap? If yes, a lot of testing and > work needs to be done and Scott, of course, cannot do that alone. So > people willing to help, should get a this board, spare flash chips, and > start mostly testing. I am not a developer, so I could not help to > improve the support, but I could test and maybe even create a live image > to flash that image from an USB storage device. > > It looks difficult though to get this board [6]. > > Another chicken and egg problem is, if this announcement should be made > public outside of the coreboot community only after support is complete > or before, i. e., are there communities (e. g. FSF) or project > developers which would help to support this effort? > > Unfortunately CeBit is going to already start next week, so we will not > be able to show the new support off there. > > > I am looking forward to your thoughts. Thanks, > > Paul > > > [1] > http://www.coreboot.org/News#2011.2F2.2F14_AMD_submits_coreboot_support_for_AMD_Embedded_G-Series_Platforms > [2] http://www.coreboot.org/pipermail/coreboot/2011-February/063737.html > [3] http://www.asrock.com/mb/overview.asp?Model=E350M1 > [4] http://notabs.org/pictures/ASRock-E350M1/ > [5] http://www.coreboot.org/Welcome_to_coreboot > [6] http://www.coreboot.org/pipermail/coreboot/2011-February/063757.html These are all great points. I am also motivated to market coreboot better. AMD and Sage are putting effort into press release and blog postings this week and around Embedded World next week. I think that your plan is well thought out and would certainly help market coreboot. You have highlighted some key areas, and I like that you have highlighted things that are not specifically development. Coreboot developers are pretty good about writing code and making systems work. We are not so good about marketing and documentation etc. It is difficult for systems developers to evaluate coreboot without investing a lot of time, in getting, building, flashing, etc. I lik
[coreboot] build service results for r6380
Dear coreboot readers! This is the automatic build system of coreboot. The developer "oxygene" checked in revision 6380 to the coreboot repository. This caused the following changes: Change Log: Add compile-time defaults to some K8 CMOS options in case they're absent in CMOS This affects the CMOS options iommu, ECC_memory, max_mem_clock, hw_scrubber, interleave_chip_selects. If they're absent in cmos.layout, a Kconfig value is used if it exists, or a hardcoded default otherwise. [Patrick: I changed the ramstage CMOS handling a bit, and dropped the reliance of hw_scrubber on ECC RAM, as it has nothing to do with it - it's the cache that's being scrubbed here.] Signed-off-by: Josef Kellermann Acked-by: Patrick Georgi Build Log: Compilation of asi:mb_5blgp has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=6380&device=mb_5blgp&vendor=asi&num=2 If something broke during this checkin please be a pain in oxygene's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] add Kconfig options in addition/in place of CMOS option
Am Freitag, den 18.02.2011, 20:24 +0100 schrieb Josef Kellermann: > Attached patch adds sane compile-time defaults via Kconfig options for > CMOS options 'iommu, ECC_memory, max_mem_clock, hw_scrubber, I changed the ramstage code a bit. The romstage code could and should also be very different (all those ifdefs...), but that requires work on the CMOS routines first, which would be beyond the scope of this patch. > Signed-off-by: Josef Kellermann Acked-by: Patrick Georgi and r6380 Patrick -- Patrick Georgi SINA-Development - High Security secunet Security Networks AG - Mergenthalerallee 77 - 65760 Eschborn, Germany Phone +49 201 54 54-3610 - Fax +49 201 54 54-1325 - www.secunet.com Sitz: Kronprinzenstraße 30, 45128 Essen / Amtsgericht Essen HRB 13615 Vorstand: Dr. Rainer Baumgart (Vors.), Thomas Koelzer, Thomas Pleines Aufsichtsratsvorsitzender: Dr. Karsten Ottenberg signature.asc Description: This is a digitally signed message part -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r6380 - in trunk/src: cpu/amd/model_fxx northbridge/amd/amdk8
Author: oxygene
Date: Thu Feb 24 15:35:42 2011
New Revision: 6380
URL: https://tracker.coreboot.org/trac/coreboot/changeset/6380
Log:
Add compile-time defaults to some K8 CMOS options in case they're absent in CMOS
This affects the CMOS options iommu, ECC_memory, max_mem_clock,
hw_scrubber, interleave_chip_selects.
If they're absent in cmos.layout, a Kconfig value is used if it exists,
or a hardcoded default otherwise.
[Patrick: I changed the ramstage CMOS handling a bit, and dropped the
reliance of hw_scrubber on ECC RAM, as it has nothing to do with it -
it's the cache that's being scrubbed here.]
Signed-off-by: Josef Kellermann
Acked-by: Patrick Georgi
Modified:
trunk/src/cpu/amd/model_fxx/Kconfig
trunk/src/cpu/amd/model_fxx/model_fxx_init.c
trunk/src/northbridge/amd/amdk8/Kconfig
trunk/src/northbridge/amd/amdk8/misc_control.c
trunk/src/northbridge/amd/amdk8/raminit_f.c
Modified: trunk/src/cpu/amd/model_fxx/Kconfig
==
--- trunk/src/cpu/amd/model_fxx/Kconfig Thu Feb 24 14:54:10 2011(r6379)
+++ trunk/src/cpu/amd/model_fxx/Kconfig Thu Feb 24 15:35:42 2011(r6380)
@@ -14,6 +14,10 @@
default n
default y if K8_REV_F_SUPPORT
+config HW_SCRUBBER
+ bool
+ default n
+
if SET_FIDVID
config SET_FIDVID_DEBUG
bool
Modified: trunk/src/cpu/amd/model_fxx/model_fxx_init.c
==
--- trunk/src/cpu/amd/model_fxx/model_fxx_init.cThu Feb 24 14:54:10
2011(r6379)
+++ trunk/src/cpu/amd/model_fxx/model_fxx_init.cThu Feb 24 15:35:42
2011(r6380)
@@ -264,7 +264,10 @@
/* See if we scrubbing should be enabled */
enable_scrubbing = 1;
- get_option(&enable_scrubbing, "hw_scrubber");
+ if( get_option(&enable_scrubbing, "hw_scrubber") < 0 )
+ {
+ enable_scrubbing = CONFIG_HW_SCRUBBER;
+ }
/* Enable cache scrubbing at the lowest possible rate */
if (enable_scrubbing) {
Modified: trunk/src/northbridge/amd/amdk8/Kconfig
==
--- trunk/src/northbridge/amd/amdk8/Kconfig Thu Feb 24 14:54:10 2011
(r6379)
+++ trunk/src/northbridge/amd/amdk8/Kconfig Thu Feb 24 15:35:42 2011
(r6380)
@@ -83,6 +83,10 @@
endif #K8_REV_F_SUPPORT
+config IOMMU
+ bool
+ default y
+
endif #NORTHBRIDGE_AMD_K8
source src/northbridge/amd/amdk8/root_complex/Kconfig
Modified: trunk/src/northbridge/amd/amdk8/misc_control.c
==
--- trunk/src/northbridge/amd/amdk8/misc_control.c Thu Feb 24 14:54:10
2011(r6379)
+++ trunk/src/northbridge/amd/amdk8/misc_control.c Thu Feb 24 15:35:42
2011(r6380)
@@ -48,7 +48,10 @@
}
iommu = 1;
- get_option(&iommu, "iommu");
+ if( get_option(&iommu, "iommu") < 0 )
+ {
+ iommu = CONFIG_IOMMU;
+ }
if (iommu) {
/* Add a GART aperture resource */
Modified: trunk/src/northbridge/amd/amdk8/raminit_f.c
==
--- trunk/src/northbridge/amd/amdk8/raminit_f.c Thu Feb 24 14:54:10 2011
(r6379)
+++ trunk/src/northbridge/amd/amdk8/raminit_f.c Thu Feb 24 15:35:42 2011
(r6380)
@@ -1107,6 +1107,15 @@
/* See if all of the memory chip selects are the same size
* and if so count them.
*/
+#if defined(CMOS_VSTART_interleave_chip_selects)
+ if (read_option(CMOS_VSTART_interleave_chip_selects,
CMOS_VLEN_interleave_chip_selects, 1) == 0)
+ return 0;
+#else
+#if !defined(CONFIG_INTERLEAVE_CHIP_SELECTS) ||
(CONFIG_INTERLEAVE_CHIP_SELECTS == 0)
+ return 0;
+#endif
+#endif
+
chip_selects = 0;
common_size = 0;
common_cs_mode = 0xff;
@@ -1279,15 +1288,10 @@
{
unsigned long tom_k, base_k;
- if (read_option(CMOS_VSTART_interleave_chip_selects,
- CMOS_VLEN_interleave_chip_selects, 1) != 0) {
- tom_k = interleave_chip_selects(ctrl, meminfo->is_Width128);
- } else {
- printk(BIOS_DEBUG, "Interleaving disabled\n");
- tom_k = 0;
- }
+ tom_k = interleave_chip_selects(ctrl, meminfo->is_Width128);
if (!tom_k) {
+ printk(BIOS_DEBUG, "Interleaving disabled\n");
tom_k = order_chip_selects(ctrl);
}
@@ -1801,7 +1805,17 @@
value = pci_read_config32(ctrl->f3, NORTHBRIDGE_CAP);
min_cycle_time = min_cycle_times[(value >> NBCAP_MEMCLK_SHIFT) &
NBCAP_MEMCLK_MASK];
bios_cycle_time = min_cycle_times[
- read_option(CMOS_VSTART_max_mem_clock, CMOS_VLEN_max_mem_clock,
0)];
+#ifdef CMOS_VSTART_max_mem_clock
+ read_option(CMO
Re: [coreboot] 870 attempt
On Thu, Feb 24, 2011 at 02:14:07AM +, Jonathan A. Kollasch wrote:
> 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, the rs780 HT init code thinks the link should
> run at 200MHz, maybe that's related.
Attached is the diff, and console output there from.
(Mainboard directory is a svn cp of bimini_fam10.)
Jonathan Kollasch
Index: src/southbridge/amd/rs780/rs780.c
===
--- src/southbridge/amd/rs780/rs780.c (revision 6378)
+++ src/southbridge/amd/rs780/rs780.c (working copy)
@@ -109,7 +109,11 @@
static u32 get_vid_did(device_t dev)
{
- return pci_read_config32(dev, 0);
+ u32 vdid;
+ printk(BIOS_INFO, "gvd");
+ vdid = pci_read_config32(dev, 0);
+ printk(BIOS_INFO, "%08x\n", vdid);
+ return vdid;
}
static void rs780_nb_pci_table(device_t nb_dev)
Index: src/mainboard/asus/Kconfig
===
--- src/mainboard/asus/Kconfig (revision 6378)
+++ src/mainboard/asus/Kconfig (working copy)
@@ -37,6 +37,8 @@
bool "M4A785-M"
config BOARD_ASUS_M4A78_EM
bool "M4A78-EM"
+config BOARD_ASUS_M4A87TD_USB3
+ bool "M4A87TD/USB3"
config BOARD_ASUS_MEW_AM
bool "MEW-AM"
config BOARD_ASUS_MEW_VM
@@ -64,6 +66,7 @@
source "src/mainboard/asus/m2v-mx_se/Kconfig"
source "src/mainboard/asus/m4a785-m/Kconfig"
source "src/mainboard/asus/m4a78-em/Kconfig"
+source "src/mainboard/asus/m4a87td-usb3/Kconfig"
source "src/mainboard/asus/mew-am/Kconfig"
source "src/mainboard/asus/mew-vm/Kconfig"
source "src/mainboard/asus/p2b/Kconfig"
Index: src/mainboard/asus/m4a87td-usb3/Kconfig
===
--- src/mainboard/asus/m4a87td-usb3/Kconfig (revision 6375)
+++ src/mainboard/asus/m4a87td-usb3/Kconfig (working copy)
@@ -1,9 +1,9 @@
-if BOARD_AMD_BIMINI_FAM10
+if BOARD_ASUS_M4A87TD_USB3
config BOARD_SPECIFIC_OPTIONS # dummy
def_bool y
select ARCH_X86
- select CPU_AMD_SOCKET_ASB2
+ select CPU_AMD_SOCKET_AM3
select DIMM_DDR3
select DIMM_REGISTERED
# TODO: Enable QRANK_DIMM_SUPPORT? Was commented in the Kconfig file,
@@ -24,16 +24,16 @@
select SERIAL_CPU_INIT
select AMDMCT
select GENERATE_ACPI_TABLES
- select BOARD_ROMSIZE_KB_2048
+ select BOARD_ROMSIZE_KB_1024
select RAMINIT_SYSINFO
select ENABLE_APIC_EXT_ID
- select GFXUMA
+ #select GFXUMA
select HAVE_DEBUG_CAR
select SET_FIDVID
config MAINBOARD_DIR
string
- default amd/bimini_fam10
+ default asus/m4a87td-usb3
config APIC_ID_OFFSET
hex
@@ -41,7 +41,7 @@
config MAINBOARD_PART_NUMBER
string
- default "Bimini (Fam10)"
+ default "M4A87TD/USB3"
config HW_MEM_HOLE_SIZEK
hex
@@ -93,14 +93,10 @@
config MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID
hex
- default 0x3060
+ default 0x8432
-config MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID
- hex
- default 0x1022
-
config RAMBASE
hex
default 0x20
-endif #BOARD_AMD_BIMINI_FAM10
+endif #BOARD_ASUS_M4A87TD_USB3
Index: src/mainboard/asus/m4a87td-usb3/devicetree.cb
===
--- src/mainboard/asus/m4a87td-usb3/devicetree.cb (revision 6375)
+++ src/mainboard/asus/m4a87td-usb3/devicetree.cb (working copy)
@@ -1,7 +1,7 @@
# sample config for amd/bimini_fam10
chip northbridge/amd/amdfam10/root_complex
device lapic_cluster 0 on
- chip cpu/amd/socket_ASB2 #L1 and DDR3
+ chip cpu/amd/socket_AM3 #L1 and DDR3
device lapic 0 on end
end
end
@@ -10,17 +10,17 @@
device pci 18.0 on # northbridge
chip southbridge/amd/rs780
device pci 0.0 on end # HT 0x9600
- device pci 1.0 on end # Internal
Graphics P2P bridge 0x9602
- device pci 2.0 off end # PCIE P2P
bridge (external graphics) 0x9603
+ #device pci 1.0 on end # Internal
Graphics P2P bridge 0x9602
+ device pci 2.0 on end # PCIE P2P bridge
(external graphics) 0x9603
device pci 3.0 off end # PCIE P2P
bridge0x960b
device pci 4.0 on end # PCIE P2P bridge
0x9604
- device pci 5.0 on end # PCIE P2P bridge
0x9605
-
Re: [coreboot] [PATCH] [and discussion] Add target for ASUS K8V-X SE motherboard
Ping! Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] New CMOS option sata_mode
Hi Josef. Thank you for the contribution. Am Freitag, den 18.02.2011, 20:12 +0100 schrieb Josef Kellermann: > Attached patch implements a new CMOS option 'sata_mode'. > A new Kconfig option 'SATA_MODE' with default 'ide' is added to > amd/sb600/Kconfig. I changed the Kconfig handling a bit to not use a magic string, and to handle the default value in Kconfig instead of doing it in code. > Signed-off-by: Josef Kellermann Acked-by: Patrick Georgi r6379 Patrick -- Patrick Georgi SINA-Development - High Security secunet Security Networks AG - Mergenthalerallee 77 - 65760 Eschborn, Germany Phone +49 201 54 54-3610 - Fax +49 201 54 54-1325 - www.secunet.com Sitz: Kronprinzenstraße 30, 45128 Essen / Amtsgericht Essen HRB 13615 Vorstand: Dr. Rainer Baumgart (Vors.), Thomas Koelzer, Thomas Pleines Aufsichtsratsvorsitzender: Dr. Karsten Ottenberg signature.asc Description: This is a digitally signed message part -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r6379 - trunk/src/southbridge/amd/sb600
Author: oxygene
Date: Thu Feb 24 14:54:10 2011
New Revision: 6379
URL: https://tracker.coreboot.org/trac/coreboot/changeset/6379
Log:
Add new option 'sata_mode' to CMOS and 'SATA_MODE' to Kconfig for AMD SB600
coreboot used to set the chipset to IDE mode unconditionally.
Now, the user has a couple of ways to choose the configuration:
- If a CMOS variable sata_mode exist, it is used to decide if IDE or
AHCI is to be used as interface.
- If not, a Kconfig option is used.
- If unchanged, the Kconfig option is set to IDE.
So unless the cmos.layout is extended or Kconfig is modified, this won't
change behaviour.
[Patrick: Compared to Josef's version, I changed the Kconfig option to
be boolean, instead of a magic string. Also, the "IDE" default is
handled in Kconfig, instead of an additional line of code.]
Signed-off-by: Josef Kellermann
Acked-by: Patrick Georgi
Modified:
trunk/src/southbridge/amd/sb600/Kconfig
trunk/src/southbridge/amd/sb600/sata.c
Modified: trunk/src/southbridge/amd/sb600/Kconfig
==
--- trunk/src/southbridge/amd/sb600/Kconfig Thu Feb 24 08:43:37 2011
(r6378)
+++ trunk/src/southbridge/amd/sb600/Kconfig Thu Feb 24 14:54:10 2011
(r6379)
@@ -23,16 +23,36 @@
select HAVE_USBDEBUG
select TINY_BOOTBLOCK
+if SOUTHBRIDGE_AMD_SB600
config BOOTBLOCK_SOUTHBRIDGE_INIT
string
default "southbridge/amd/sb600/bootblock.c"
- depends on SOUTHBRIDGE_AMD_SB600
config EHCI_BAR
hex
- default 0xfef0 if SOUTHBRIDGE_AMD_SB600
+ default 0xfef0
config EHCI_DEBUG_OFFSET
hex
- default 0xe0 if SOUTHBRIDGE_AMD_SB600
+ default 0xe0
+choice
+ prompt "SATA Mode"
+ default SATA_MODE_IDE
+ help
+ Select the mode in which SATA should be driven. IDE or AHCI.
+ The default is IDE.
+
+ config SATA_MODE_IDE
+ bool "IDE"
+
+ config SATA_MODE_AHCI
+ bool "AHCI"
+endchoice
+
+config SATA_MODE
+ int
+ default 1 if SATA_MODE_IDE
+ default 0 if SATA_MODE_AHCI
+
+endif
Modified: trunk/src/southbridge/amd/sb600/sata.c
==
--- trunk/src/southbridge/amd/sb600/sata.c Thu Feb 24 08:43:37 2011
(r6378)
+++ trunk/src/southbridge/amd/sb600/sata.c Thu Feb 24 14:54:10 2011
(r6379)
@@ -26,6 +26,10 @@
#include
#include
#include "sb600.h"
+#include
+
+#define SATA_MODE_IDE 1
+#define SATA_MODE_AHCI 0
static int sata_drive_detect(int portnum, u16 iobar)
{
@@ -98,10 +102,6 @@
printk(BIOS_SPEW, "sata_bar4=%x\n", sata_bar4); /* 3000 */
printk(BIOS_SPEW, "sata_bar5=%x\n", sata_bar5); /* e0309000 */
- /* Program the 2C to 0x43801002 */
- dword = 0x43801002;
- pci_write_config32(dev, 0x2c, dword);
-
/* SERR-Enable */
word = pci_read_config16(dev, 0x04);
word |= (1 << 8);
@@ -112,13 +112,25 @@
byte |= (1 << 2);
pci_write_config8(dev, 0x40, byte);
- /* Set SATA Operation Mode, Set to IDE mode */
+ /* Set SATA Operation Mode */
byte = pci_read_config8(dev, 0x40);
byte |= (1 << 0);
byte |= (1 << 4);
pci_write_config8(dev, 0x40, byte);
- dword = 0x01018f00;
+ // 1 means IDE, 0 means AHCI
+ if( get_option(&i, "sata_mode") < 0 ) {
+ // no cmos option
+ i = CONFIG_SATA_MODE;
+ }
+ printk(BIOS_INFO, "%s: setting sata mode = %s\n", __func__, (i ==
SATA_MODE_IDE)?"ide":"ahci" );
+
+ dword = pci_read_config32(dev, 0x8);
+ dword &= 0xffff;
+ if (i == SATA_MODE_IDE)
+ dword |= 0x00018f00; // IDE mode
+ else
+ dword |= 0x00060100; // AHCI mode
pci_write_config32(dev, 0x8, dword);
byte = pci_read_config8(dev, 0x40);
@@ -245,7 +257,7 @@
}
static struct pci_operations lops_pci = {
- /* .set_subsystem = pci_dev_set_subsystem, */
+ .set_subsystem = pci_dev_set_subsystem,
};
static struct device_operations sata_ops = {
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Fam10 FIDVID in SVI 01/25
Am Donnerstag, den 17.02.2011, 07:35 +0100 schrieb xdrudis: > see patch Any opinion on these patches? Patch 1-8 seem to be refactorings only, and splitting functions into smaller logical units looks good to me, but I'd like to hear from someone deeper in the AMD code. Patrick -- Patrick Georgi SINA-Development - High Security secunet Security Networks AG - Mergenthalerallee 77 - 65760 Eschborn, Germany Phone +49 201 54 54-3610 - Fax +49 201 54 54-1325 - www.secunet.com Sitz: Kronprinzenstraße 30, 45128 Essen / Amtsgericht Essen HRB 13615 Vorstand: Dr. Rainer Baumgart (Vors.), Thomas Koelzer, Thomas Pleines Aufsichtsratsvorsitzender: Dr. Karsten Ottenberg signature.asc Description: This is a digitally signed message part -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [RFC] marketing coreboot after recent support of AMD board
Dear coreboot community, it is really amazing what happened in the last years and especially in the last months. A lot of people came – for me – out of nowhere and did great contributions. Also AMD did great with their latest contributions [1]. Today, Scott sent a patch to the list to support the board ASRock E350M1 [2, 3, 4]. If I am not mistaken there have been only a few cases, it could be the first, where such a *recent* consumer board is supported by coreboot. And that is the reason I am writing this message. This also means that most of the computer magazines (online – at least in Europe – and print) have not yet published reviews and the board is not yet old enough to be considered by consumers. You guys have more experience than I on how these reviewer networks work, but is there an easy way to get these boards tested by these people with coreboot? I came up with the following steps to be accomplished to reach that goal. 1. Contact ASRock. Does anyone have contacts at ASRock to get documentation or even hardware or man power? 2. Get Windows running. Scott wrote that Windows does not boot yet. Since the market share of Windows in the home desktop market is still the biggest, that would of course be a requirement. 3. Get GNU/Linux running. I think FLOSS users are more open to try new things. So to get to them, GNU/Linux should at least be able to boot. 4. Wiki page and feature list. A page in our Wiki [5] should be set up with detailed instructions on how to create an image, what features (ACPI, power management, suspend/resume, connectors, …) work and, when the patch is committed, what revision was tested. 5. Comparison with the vendor BIOS. People of course would only be interested if coreboot is superior to the vendor BIOS. And I would imagine that normal users would be most interested in boot time. Is coreboot faster? 6. Flashrom support or “precompiled” images. To make it easy for the reviewers and early adopters flashing using Flashrom should work or precompiled images should be made available, if it is legally possible, and even flash chips offered or send to the reviewers which they can easily plug into the board and start testing. Is there a foundation (e. g. FSF), organization or cooperation (e. g. Google) which could sponsor to buy like 200(?) spare flash chips, which then can be programmed? What flash chips are compatible with this board? 7. Contact everybody. When all of the above has been accomplished, the magazines, reviewing sites, news sites, LUGs, communities should be informed. Magazines get the chips send to and consumers can order them from a coreboot developer. Do you think that is a feasible roadmap? If yes, a lot of testing and work needs to be done and Scott, of course, cannot do that alone. So people willing to help, should get a this board, spare flash chips, and start mostly testing. I am not a developer, so I could not help to improve the support, but I could test and maybe even create a live image to flash that image from an USB storage device. It looks difficult though to get this board [6]. Another chicken and egg problem is, if this announcement should be made public outside of the coreboot community only after support is complete or before, i. e., are there communities (e. g. FSF) or project developers which would help to support this effort? Unfortunately CeBit is going to already start next week, so we will not be able to show the new support off there. I am looking forward to your thoughts. Thanks, Paul [1] http://www.coreboot.org/News#2011.2F2.2F14_AMD_submits_coreboot_support_for_AMD_Embedded_G-Series_Platforms [2] http://www.coreboot.org/pipermail/coreboot/2011-February/063737.html [3] http://www.asrock.com/mb/overview.asp?Model=E350M1 [4] http://notabs.org/pictures/ASRock-E350M1/ [5] http://www.coreboot.org/Welcome_to_coreboot [6] http://www.coreboot.org/pipermail/coreboot/2011-February/063757.html signature.asc Description: This is a digitally signed message part -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] searching volunteer to install coreboot on SB850 with fam10h
Hello everybody, I bought a new ASUSTeK M4A87TD/USB3 motherboard and discussed it on irc #coreboot, there is a developer with the same motherboard. I know got these motherboards that need features provided by coreboot: 1x ASUSTeK M4A87TD/USB3 [1] (AMD 870/SB850) 1x Gigabyte GA-890GPA-UD3H [2] (AMD 890GX/SB850) 2x ASUSTeK M4A78 [3] (AMD 780G/SB700) (EOL) [1] http://www.asus.com/product.aspx?P_ID=nlWYrI9wlNIYHAaa [2] http://www.gigabyte.com/products/product-page.aspx?pid=3516 [3] http://www.asus.com/product.aspx?P_ID=EbXqq06yxpJwlABf I would very much like to see a working SB850 with fam10h coreboot support (not fam14h because it does not support AMD X4 (615e) or X6 (1075T) multi-core processors for AMD-V) I don’t need any video support serial redirection output is sufficient I don't have the resources to do any coreboot development, I can do testing or set small bounty or donate a motherboard. Would somebody be willing to get the M4A87TD/USB3 or GA-890GPA-UD3H working before it gets old or goes EOL. Thanks in advance Don’t need coreboot on the bellow motherboards they already have serial console redirection but if somebody want to do testing let me know. 4x Intel S5520HC 2x SuperMicro MBD-H8DIi+ 1x SuperMicro X7SPA-HF 4x PC Engines alix2d13 4x PC Engines alix6e2 With kind regards, Jelle de Jong -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot for AMD Fusion family 14h: ASRock E350M1
Am Donnerstag, den 24.02.2011, 05:34 +0100 schrieb Peter Stuge: > Scott Duplichan wrote: These are really great news. […] > This looks like a nice board for a media center system. Indeed. There are some reviews available of this board [1][2]. Unfortunately in Germany all the online shops seem to be out of stock [3]. The board would cost around 90 €. Thanks, Paul [1] http://www.fudzilla.com/reviews/item/21897-asrock-e350m1-brazos-review/21897-asrock-e350m1-brazos-review?start=4 [2] http://www.tomshardware.com/reviews/asrock-e350m1-amd-brazos-zacate-apu,2840-14.html [3] http://www.preistrend.de/Preisvergleich_ASRock_E350M1__x7249770B0404.html 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] 870 attempt
Dear Jonathan, Am Donnerstag, den 24.02.2011, 02:14 + schrieb Jonathan A. Kollasch: > I've attempted to use the rs780 and sb800 code on a AM3 870 + SB850 > board. what is the model number? […] Good luck with the port! 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] [PATCH] disabling microcode update
On 02/24/2011 12:26 PM, Peter Stuge wrote: > Alex G. wrote: >> Is the 'adding a line in Kconfig' option hassle free enough for you? >> I just don't see a way to make it obscure enough it menuconfig, but I >> won't object if you do find one. > > Don't we have an experts option that will enable further options? > If it's hidden under expert options, I can work with that :) . Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] disabling microcode update
Alex G. wrote: > Is the 'adding a line in Kconfig' option hassle free enough for you? > I just don't see a way to make it obscure enough it menuconfig, but I > won't object if you do find one. Don't we have an experts option that will enable further options? //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] disabling microcode update
On 02/23/2011 03:51 PM, Xavi Drudis Ferran wrote: > > Pompous ? > Yes. This is an option for experienced users, and people too smart for they own sake (pozitive connotation), that value their freedom more than practicality. They will go to an extra effort to ensure that. Therefore, considering the above, an option in menuconfig (gtkconfig, xconfig, etch) is pompous. > > If that is too visible for you I don't know how to build an option that > different users > may enable or disable. > Well, how about I simply need to add a select DISABLE_MICROCODE_UPDATE in my board's Kconfig file? > If you mean visible in the source code: > It will have to appear in the source code for it to work. I'd have to be unreasonable to say "make it invisible in the source code". > > About newcomers complaining because they've disabled microcode update, > it's not somethign that would happen without user action, and we already > have newcomers (Ivaylo and I) complaining because the microcode update > it giving us trouble. We can add a note in Kconfig help like : > When I decide to dedicate my time to helping someone on IRC who has problems getting coreboot to run, I don't want them to keep me on hold, and then say "I also tried with this 'disable microcode update' option, and it still didn't work". It has happened before with other options, completely irrelevant to their issue. > "If you unselect this option and have some problem you want to ask > about in the coreboot mailing list (or elsewhere) please report clearly > you disable microcode update, since some developers strongly advise against > this." > > >> If I _really_ wanted to disable microcode updates, I would simply >> comment out a line of code. >> > > That's what I did ! But I found out there were more people than just myself > wanting this option, so I tried to code a patch that would change nothing > for those who wanted the old behaviour but would allow to disable microcode > update and keep testing new svn revisions, sending patches, etc. without > the hurdle of a local modification, for those of us that need it. > That's what I would do _myself_. That isn't to say I don't agree with other options. And yet, I doubt adding a Kconfig line will be much of a hassle. > If I had know how polemic it all would become I've probably hadn't sent > the "pompous" patch at all. > Please take no offense in seeing your patch as "pompous". It is not. It is the option in menuconfig that is pompous. The "polemic" is good. If we take the time to digest it now, we will have a precedent to refer to next time it comes up. > But I won't follow along this route, because we simply don't agree in enough > categories to agree in this. > If you had asked me about disabling microcode updates a week ago, I would probably have laughed and not even have thought of it. I respect your point of view, and that is why I am _thinking_ about this, and of a way to incorporate it without much noise to both of us (though you could argue that noise has already been generated). >> I'm not voting no on this, just so as long as it is completely invisible >> to me. >> > > Please specify which of Option A, B, or C do you prefer, or propose something > else, if you don't vote no. I can't code a completely invisible patch to a > free software > project that evolves in the open like coreboot. > Whatever I do you will see it if you look at it. > Yes, I will see it if I look for it explicitly. There's nothing I can do about that, and to reject it for this reason would be nothing but malice from my side. Is the 'adding a line in Kconfig' option hassle free enough for you? I just don't see a way to make it obscure enough it menuconfig, but I won't object if you do find one. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] build service results for r6378
Dear coreboot readers! This is the automatic build system of coreboot. The developer "oxygene" checked in revision 6378 to the coreboot repository. This caused the following changes: Change 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: Patrick Georgi Build Log: Compilation of tyan:s2735 has been fixed If something broke during this checkin please be a pain in oxygene's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] 870 attempt
On 02/24/2011 04:14 AM, Jonathan A. Kollasch wrote: > 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, the rs780 HT init code thinks the link should > run at 200MHz, maybe that's related. > > I'm aware that this code wasn't exactly intended for the 870, > but maybe someone has some hints of what to try next. > Output output output output from the serial port. Please. :) Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
