Re: [coreboot] Spi flash
Hi, Please check what SPI chip is on your board. Check if it is defined in the list flashchips[] in flashrom/flashchips.c. Joe From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dupont Yves Sent: Thursday, November 13, 2008 4:11 PM To: coreboot@coreboot.org Subject: [coreboot] Spi flash Hello, I tried to dump my BIOS with flashrom on a SONY VAIO VGN-TX3XP. Verbose mode was enabled : - The southbridge is an ICH7 - it seems to be a SPI flash but the RDID command always returns 0xff. How can I identify my flash? thanks, -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] r3787 build service
Hi, all, The dbm690t_acpi.patch we sent has a created directory "acpi" in src/mainboard/amd/dbm690t. It is lost in the most updated revision. That is why the error comes up. Do we need send a new patch based on current revision? Joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of coreboot information Sent: Tuesday, December 02, 2008 6:01 AM To: coreboot mailinglist Subject: [coreboot] r3787 build service Dear coreboot readers! This is the automated build check service of coreboot. The developer "mjones" checked in revision 3787 to the coreboot source repository and caused the following changes: Change Log: Add AMD dbm690t ACPI support. The following ACPI features are supported. 1. S1, S5 sleep and wake up (by power button or PS/2 keyboard/mouse). 2. AMD powernow-k8 driver. 3. Thermal configuration based on ADT7461. 4. IDE timing settings. 5. HPET timer. 6. Interrupt routing based on ACPI table. Signed-off-by: Joe Bao <[EMAIL PROTECTED]> Reviewed-by:Maggie Li <[EMAIL PROTECTED]> Acked-by: Ronald G. Minnich <[EMAIL PROTECTED]> Acked-by: Marc Jones <[EMAIL PROTECTED]> Build Log: Compilation of amd:dbm690t has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3787&device=dbm690t&ven dor=amd If something broke during this checkin please be a pain in mjones'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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Patches for ACPI support on dbm690t (reset TALERT of ADT7461)
The TALERT of ADT7461 should be pull back high if the temperature is within the limit. It is done by reading the register whose device address is 0xC. It is not trivial as it looks. Signed-off-by: Maggie Li <[EMAIL PROTECTED]> Reviewed-by:Joe Bao <[EMAIL PROTECTED]> dbm690t_reset_alert.patch Description: dbm690t_reset_alert.patch -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] BarCamp Beijing
http://us.apachecon.com/c/accn2008/about I am going to do a brief presentation on BarCamp Beijing. Hopefully more people in China will know this project. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] BarCamp Beijing
The presentation is what I want. Do you have a presentation for new people, focusing on the advantage of coreboot. Joe -Original Message- From: Carl-Daniel Hailfinger [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 5:02 PM To: Bao, Zheng Cc: coreboot mailinglist Subject: Re: [coreboot] BarCamp Beijing On 04.12.2008 09:48, Bao, Zheng wrote: > http://us.apachecon.com/c/accn2008/about > > I am going to do a brief presentation on BarCamp Beijing. Hopefully more > people in China will know this project. > Great, thank you! If you need any help or pointers to other coreboot presentations, please tell us. (And I think it is cool that this coreboot presentation happens at the Intel China Research Center.) Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] HT reset hang on 690G/SB600 board Asus M2A-VM
Hi,
I doubt if the fid/vid code causes this problem. You can try to remove
the
Fid/vid code and see if the problem still exists.
--- cache_as_ram_auto.c (revision 3789)
+++ cache_as_ram_auto.c (working copy)
@@ -197,17 +197,7 @@
rs690_early_setup();
sb600_early_setup();
- msr=rdmsr(0xc0010042);
- printk_debug("begin msr fid, vid: hi=0x%x, lo=0x%x\n", msr.hi,
msr.lo);
-
- enable_fid_change();
- enable_fid_change_on_sb(sysinfo->sbbusn, sysinfo->sbdn);
- init_fidvid_bsp(bsp_apicid);
- /* show final fid and vid */
- msr=rdmsr(0xc0010042);
- printk_debug("end msr fid, vid: hi=0x%x, lo=0x%x\n", msr.hi,
msr.lo);
needs_reset = optimize_link_coherent_ht();
needs_reset |= optimize_link_incoherent_ht(sysinfo);
printk_debug("needs_reset=0x%x\n", needs_reset);
Joe
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Carl-Daniel
Hailfinger
Sent: Thursday, December 11, 2008 10:04 AM
To: Coreboot
Subject: [coreboot] HT reset hang on 690G/SB600 board Asus M2A-VM
Hi!
I'm trying to get coreboot v2 running on my Asus M2A-VM. It is very
similar to the AMD DBM690T. It has a 690G/SB600 chipset and an IT8716F
SuperIO.
My codebase is a slightly modified amd/dbm690t target. I only changed
the CPU socket to AM2.
coreboot-2.0.0.0-failover Do 11. Dez 01:16:13 CET 2008 starting...
bsp_apicid=0x0
core0 started:
SBLink=00
NC node|link=00
rs690_early_setup()
get_cpu_rev EAX=0x50ff2.
CPU Rev is K8_G0.
NB Revision is A12.
rs690_ht_init k8_ht_freq=0.
k8_optimization()
rs690_por_init
sb600_early_setup()
sb600_devices_por_init()
sb600_devices_por_init(): SMBus Device, BDF:0-20-0
SMBus controller enabled, sb revision is 0x13
sb600_devices_por_init(): IDE Device, BDF:0-20-1
sb600_devices_por_init(): LPC Device, BDF:0-20-3
sb600_devices_por_init(): P2P Bridge, BDF:0-20-4
sb600_devices_por_init(): SATA Device, BDF:0-18-0
sb600_pmio_por_init()
begin msr fid, vid: hi=0x310a1212, lo=0xa0a0202
Current fid_cur: 0x2, fid_max: 0xa
Requested fid_new: 0xa
FidVid table step fidvid: 0xa
end msr fid, vid: hi=0x310a120a, lo=0xa0a020a
needs_reset=0x1
ht reset -
It hangs after that soft reset. No POST code, nothing else.
Any insights are appreciated.
Processor info follows:
hilbert:~ # cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 95
model name : AMD Athlon(tm) 64 Processor 3000+
stepping: 2
cpu MHz : 1800.000
cache size : 512 KB
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt
rdtscp lm 3dnowext 3dnow rep_good pni cx16 lahf_lm svm extapic
cr8_legacy
bogomips: 3602.72
TLB size: 1024 4K pages
clflush size: 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RS690 HT init
It is great to remind me that.
I knew this issue when I did the 690 code. The board I worked with
seemed to support just 800Mhz HT link, which doesn't need any more
setting when HT is set up. Then I ignore this. Then I had to move on.
As a matter of fact, both 600Mhz and 1Ghz have their own specific
setting. I thought rs690_htinit should be removed from
rs690_early_setup() and called after optimize_link_incoherent_ht().
Zheng (Joe)
-Original Message-
From: coreboot-boun...@coreboot.org
[mailto:coreboot-boun...@coreboot.org] On Behalf Of Carl-Daniel
Hailfinger
Sent: Friday, December 12, 2008 12:25 PM
To: Coreboot
Subject: [coreboot] RS690 HT init
Hi,
it seems that rs690_htinit() does nothing (it only prints some data). Is
that intentional?
The RS690 chipset has a problem where it will not work with 1 GHz HT
speed unless NB_CFG_Q_F1000_800 bit 0 is set. I think we could add code
for this to rs690_htinit().
/*
* Compliant with CIM_33's ATINB_HTInit
* Init HT link speed/width for rs690 -- k8 link
*/
static void rs690_htinit()
{
/*
* About HT, it has been done in enumerate_ht_chain().
*/
device_t k8_f0;
u32 reg;
u8 k8_ht_freq;
k8_f0 = PCI_DEV(0, 0x18, 0);
/
* get k8's ht freq, in k8's function 0, offset 0x88
* bit11-8, specifics the maximum operation frequency of the
link's transmitter clock.
* The link frequency field (Frq) is cleared by cold reset. SW
can write a nonzero
* value to this reg, and that value takes effect on the next
warm reset or
* LDTSTOP_L disconnect sequence.
* b = 200Mhz
* 0010b = 400Mhz
* 0100b = 600Mhz
* 0101b = 800Mhz
* 0110b = 1Ghz
* b = 1Ghz
/
reg = pci_read_config32(k8_f0, 0x88);
k8_ht_freq = (reg & 0xf00) >> 8;
printk_info("rs690_ht_init k8_ht_freq=%x.\n", k8_ht_freq);
}
As you can see, we only read the K8 HT speed.
I have created a patch which tests if the K8 HT speed is 1 GHz
and sets NB_CFG_Q_F1000_800 bit 0 in that case.
But this can fail if the processor has more than one HT link.
My idea was to look at RS690 HT link configuration instead because
it has only one HT link.
There is another problem because rs690_htinit() is called before
optimize_link_incoherent_ht(). The new link speed is only known
after optimize_link_incoherent_ht(). Calling rs690_htinit() too
early has no effect.
I call rs690_htinit() again after optimize_link_incoherent_ht().
What do you think?
Regards,
Carl-Daniel
Signed-off-by: Carl-Daniel Hailfinger
Index:
LinuxBIOSv2-asus_m2a-vm/src/southbridge/amd/rs690/rs690_early_setup.c
===
---
LinuxBIOSv2-asus_m2a-vm/src/southbridge/amd/rs690/rs690_early_setup.c
(Revision 3811)
+++
LinuxBIOSv2-asus_m2a-vm/src/southbridge/amd/rs690/rs690_early_setup.c
(Arbeitskopie)
@@ -175,8 +175,9 @@
/*
* About HT, it has been done in enumerate_ht_chain().
*/
- device_t k8_f0;
+ device_t k8_f0, rs690_f0;
u32 reg;
+ u8 reg8;
u8 k8_ht_freq;
k8_f0 = PCI_DEV(0, 0x18, 0);
@@ -196,6 +197,16 @@
reg = pci_read_config32(k8_f0, 0x88);
k8_ht_freq = (reg & 0xf00) >> 8;
printk_info("rs690_ht_init k8_ht_freq=%x.\n", k8_ht_freq);
+ if ((k8_ht_freq == 0x6) || (k8_ht_freq == 0xf)) {
+ rs690_f0 = PCI_DEV(0, 0, 0);
+ reg8 = pci_read_config8(rs690_f0, 0x9c);
+ printk_info("rs690_ht_init NB_CFG_Q_F1000_800=%x\n",
reg8);
+ if (!(reg8 & 0x1)) {
+ printk_info("rs690_ht_init setting bit 0 in
NB_CFG_Q_F1000_800 to allow 1 GHz HT\n");
+ reg8 |= 0x1;
+ pci_write_config8(rs690_f0, 0x9c, reg8);
+ }
+ }
}
/***
Index:
LinuxBIOSv2-asus_m2a-vm/src/mainboard/amd/dbm690t/cache_as_ram_auto.c
===
---
LinuxBIOSv2-asus_m2a-vm/src/mainboard/amd/dbm690t/cache_as_ram_auto.c
(Revision 3811)
+++
LinuxBIOSv2-asus_m2a-vm/src/mainboard/amd/dbm690t/cache_as_ram_auto.c
(Arbeitskopie)
@@ -210,6 +210,7 @@
needs_reset = optimize_link_coherent_ht();
needs_reset |= optimize_link_incoherent_ht(sysinfo);
+ rs690_htinit();
printk_debug("needs_reset=0x%x\n", needs_reset);
--
http://www.hailfinger.org/
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RS690 HT init
I am not sure about if the NB_CFG_Q_F1000_800 affect the
LINK_FREQ_CAP_A. If yes, it will affect the negotiation of HT link. If
the HT reset hang is caused by 1Ghz issue, it seems that this 2 things
don't have hard relationship.
Zheng
-Original Message-
From: coreboot-boun...@coreboot.org
[mailto:coreboot-boun...@coreboot.org] On Behalf Of Carl-Daniel
Hailfinger
Sent: Friday, December 12, 2008 12:25 PM
To: Coreboot
Subject: [coreboot] RS690 HT init
Hi,
it seems that rs690_htinit() does nothing (it only prints some data). Is
that intentional?
The RS690 chipset has a problem where it will not work with 1 GHz HT
speed unless NB_CFG_Q_F1000_800 bit 0 is set. I think we could add code
for this to rs690_htinit().
/*
* Compliant with CIM_33's ATINB_HTInit
* Init HT link speed/width for rs690 -- k8 link
*/
static void rs690_htinit()
{
/*
* About HT, it has been done in enumerate_ht_chain().
*/
device_t k8_f0;
u32 reg;
u8 k8_ht_freq;
k8_f0 = PCI_DEV(0, 0x18, 0);
/
* get k8's ht freq, in k8's function 0, offset 0x88
* bit11-8, specifics the maximum operation frequency of the
link's transmitter clock.
* The link frequency field (Frq) is cleared by cold reset. SW
can write a nonzero
* value to this reg, and that value takes effect on the next
warm reset or
* LDTSTOP_L disconnect sequence.
* b = 200Mhz
* 0010b = 400Mhz
* 0100b = 600Mhz
* 0101b = 800Mhz
* 0110b = 1Ghz
* b = 1Ghz
/
reg = pci_read_config32(k8_f0, 0x88);
k8_ht_freq = (reg & 0xf00) >> 8;
printk_info("rs690_ht_init k8_ht_freq=%x.\n", k8_ht_freq);
}
As you can see, we only read the K8 HT speed.
I have created a patch which tests if the K8 HT speed is 1 GHz
and sets NB_CFG_Q_F1000_800 bit 0 in that case.
But this can fail if the processor has more than one HT link.
My idea was to look at RS690 HT link configuration instead because
it has only one HT link.
There is another problem because rs690_htinit() is called before
optimize_link_incoherent_ht(). The new link speed is only known
after optimize_link_incoherent_ht(). Calling rs690_htinit() too
early has no effect.
I call rs690_htinit() again after optimize_link_incoherent_ht().
What do you think?
Regards,
Carl-Daniel
Signed-off-by: Carl-Daniel Hailfinger
Index:
LinuxBIOSv2-asus_m2a-vm/src/southbridge/amd/rs690/rs690_early_setup.c
===
---
LinuxBIOSv2-asus_m2a-vm/src/southbridge/amd/rs690/rs690_early_setup.c
(Revision 3811)
+++
LinuxBIOSv2-asus_m2a-vm/src/southbridge/amd/rs690/rs690_early_setup.c
(Arbeitskopie)
@@ -175,8 +175,9 @@
/*
* About HT, it has been done in enumerate_ht_chain().
*/
- device_t k8_f0;
+ device_t k8_f0, rs690_f0;
u32 reg;
+ u8 reg8;
u8 k8_ht_freq;
k8_f0 = PCI_DEV(0, 0x18, 0);
@@ -196,6 +197,16 @@
reg = pci_read_config32(k8_f0, 0x88);
k8_ht_freq = (reg & 0xf00) >> 8;
printk_info("rs690_ht_init k8_ht_freq=%x.\n", k8_ht_freq);
+ if ((k8_ht_freq == 0x6) || (k8_ht_freq == 0xf)) {
+ rs690_f0 = PCI_DEV(0, 0, 0);
+ reg8 = pci_read_config8(rs690_f0, 0x9c);
+ printk_info("rs690_ht_init NB_CFG_Q_F1000_800=%x\n",
reg8);
+ if (!(reg8 & 0x1)) {
+ printk_info("rs690_ht_init setting bit 0 in
NB_CFG_Q_F1000_800 to allow 1 GHz HT\n");
+ reg8 |= 0x1;
+ pci_write_config8(rs690_f0, 0x9c, reg8);
+ }
+ }
}
/***
Index:
LinuxBIOSv2-asus_m2a-vm/src/mainboard/amd/dbm690t/cache_as_ram_auto.c
===
---
LinuxBIOSv2-asus_m2a-vm/src/mainboard/amd/dbm690t/cache_as_ram_auto.c
(Revision 3811)
+++
LinuxBIOSv2-asus_m2a-vm/src/mainboard/amd/dbm690t/cache_as_ram_auto.c
(Arbeitskopie)
@@ -210,6 +210,7 @@
needs_reset = optimize_link_coherent_ht();
needs_reset |= optimize_link_incoherent_ht(sysinfo);
+ rs690_htinit();
printk_debug("needs_reset=0x%x\n", needs_reset);
--
http://www.hailfinger.org/
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Interesting (part of) article.
We don't have 690G based board. I am sorry that I cant test you patch. Doesn't it work on your board? Zheng -Original Message- From: coreboot-boun...@coreboot.org [mailto:coreboot-boun...@coreboot.org] On Behalf Of Carl-Daniel Hailfinger Sent: Monday, December 15, 2008 9:39 AM To: coreboot@coreboot.org Subject: Re: [coreboot] Interesting (part of) article. On 15.12.2008 01:57, Peter Stuge wrote: > Tiago Marques wrote: > >> If you can make Coreboot work well on an AMD 690G, I can talk to >> them about it. >> > > By the time we do, the chipset may no longer be on the market. :\ > I hope someone can help me fix the PCI init hang I'm seeing on my 690G board. > I doubt 690 will boost coreboot, it's just a little too old.. > It's starting to get adopted in the embedded world, but desktop boards are getting scarce. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] DBM690T boot log needed
Attached please find the log. Zheng -Original Message- From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2...@gmx.net] Sent: Monday, December 15, 2008 10:17 AM To: Coreboot Cc: Bao, Zheng Subject: Re: [coreboot] DBM690T boot log needed Hi Zheng, could you please try to get such a DBM690T log? Thanks! If I can compare that log with my log, I might be able to find the bug on my 690G board. Regards, Carl-Daniel On 11.12.2008 17:12, Carl-Daniel Hailfinger wrote: > Hi, > > a boot log for the DBM690T with CONSOLE_LOGLEVEL=9 would be really > great. Can anyone please mail such a log to the list? > > Thanks! > > Regards, > Carl-Daniel > -- http://www.hailfinger.org/ dbm690t_log.log Description: dbm690t_log.log -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] DBM690T boot log needed
Hi, Carl, Base on your lspci, the device id of the 690G internal Graphics is 0x791E, while code in src/southbridge/amd/rs690/rs690_gfx.c has the id 0x791F for 690T. I changed my code to 791E and it hangs exactly where your board does. We need to figure out a way to tell which chipset we used. Zheng -Original Message- From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2...@gmx.net] Sent: Monday, December 15, 2008 10:17 AM To: Coreboot Cc: Bao, Zheng Subject: Re: [coreboot] DBM690T boot log needed Hi Zheng, could you please try to get such a DBM690T log? Thanks! If I can compare that log with my log, I might be able to find the bug on my 690G board. Regards, Carl-Daniel On 11.12.2008 17:12, Carl-Daniel Hailfinger wrote: > Hi, > > a boot log for the DBM690T with CONSOLE_LOGLEVEL=9 would be really > great. Can anyone please mail such a log to the list? > > Thanks! > > Regards, > Carl-Daniel > -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Patch for 690G and 690(MT) internal graphics
Hi,
I add an entry for both 791E and 791F.
Carl, could you please review and try it on your 690G board?
Zheng
Signed-off-by: Zheng Bao
Index: src/southbridge/amd/rs690/rs690_gfx.c
===
--- src/southbridge/amd/rs690/rs690_gfx.c (revision 223)
+++ src/southbridge/amd/rs690/rs690_gfx.c (working copy)
@@ -211,12 +211,22 @@
.ops_pci = &lops_pci,
};
-static struct pci_driver pcie_driver __pci_driver = {
+/*
+ * The dev id of 690G is 791E, while the id of 690M, 690T is 791F.
+ * We should list both of them here.
+ * */
+static struct pci_driver pcie_driver_690t __pci_driver = {
.ops = &pcie_ops,
.vendor = PCI_VENDOR_ID_ATI,
.device = PCI_DEVICE_ID_ATI_RS690MT_INT_GFX,
};
+static struct pci_driver pcie_driver_690 __pci_driver = {
+ .ops = &pcie_ops,
+ .vendor = PCI_VENDOR_ID_ATI,
+ .device = PCI_DEVICE_ID_ATI_RS690_INT_GFX,
+};
+
/* step 12 ~ step 14 from rpr */
static void single_port_configuration(device_t nb_dev, device_t dev)
{
-Original Message-
From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2...@gmx.net]
Sent: Monday, December 15, 2008 10:17 AM
To: Coreboot
Cc: Bao, Zheng
Subject: Re: [coreboot] DBM690T boot log needed
Hi Zheng,
could you please try to get such a DBM690T log? Thanks!
If I can compare that log with my log, I might be able to find the bug
on my 690G board.
Regards,
Carl-Daniel
On 11.12.2008 17:12, Carl-Daniel Hailfinger wrote:
> Hi,
>
> a boot log for the DBM690T with CONSOLE_LOGLEVEL=9 would be really
> great. Can anyone please mail such a log to the list?
>
> Thanks!
>
> Regards,
> Carl-Daniel
>
--
http://www.hailfinger.org/
rs690t_gfx.diff
Description: rs690t_gfx.diff
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Patch for 690G and 690(MT) internal graphics
It's truly great. It is greater if you send a patch with signed-off-by and I will try on my 690t board. Thanks. Zheng -Original Message- From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2...@gmx.net] Sent: Wednesday, December 17, 2008 10:17 AM To: Bao, Zheng Cc: Coreboot Subject: Re: [coreboot] Patch for 690G and 690(MT) internal graphics Hi Zheng, On 16.12.2008 04:41, Bao, Zheng wrote: > I add an entry for both 791E and 791F. > Carl, could you please review and try it on your 690G board? > This is absolutely GREAT! It works perfectly. Thank you! > Zheng > > Signed-off-by: Zheng Bao > Acked-by: Carl-Daniel Hailfinger and committed in revision 3816. I have attached my Asus M2A-VM boot log. Together with the ncHT fixup, it boots until elfboot. I'll post a cleaned up HT fixup soon. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Asus M2A-VM
Adjust rom_table_end from 0x000f34d0 to 0x0010 uma_memory_start=0x7800, uma_memory_size=0x800 Wrote coreboot table at: 0530 - 0778 checksum 5730 .. Based on your bootlog, coreboot correctly detects your memory size(uma_memory_start+ uma_memory_size). When does it report 2G memory? Zheng -Original Message- From: coreboot-boun...@coreboot.org [mailto:coreboot-boun...@coreboot.org] On Behalf Of Carl-Daniel Hailfinger Sent: Wednesday, December 17, 2008 12:14 PM To: Coreboot Subject: Re: [coreboot] Asus M2A-VM On 17.12.2008 04:39, Carl-Daniel Hailfinger wrote: > Hi all, > > my Asus M2A-VM (690G/SB600) is working and boots to memtest and FILO. > > Memtest works fine over serial (well, I only ran memtest until it > reached 15%). > FILO can load the kernel, but I didn't have time to enable serial output > for my kernel. > > Thanks to Zheng Bao for adding support for my 690G graphics. > > I'll post a patch soon. Right now, there are a few more bugs to fix. The > ncHT fixup is already known, a clean patch will come tomorrow. > > On a first boot, I get an endless loop of > > drive detection fail,trying... > > until I press the reset button. After that, it boots fine. That message > is in the SB600 code. I will enable some debugging that was disabled in > revision 3785. > > Another curiosity is that my power button has become ineffective. It > simply initiates a reboot instead of switching off the machine after 4 > seconds. That happens only with the FILO payload. > Oh, and it does not find more than 2 GB of RAM. I'll try to debug that as well. Right now, I'm happy that it gets to FILO and can load a kernel. The interrupts are probably wrong. I need to check that. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Asus M2A-VM
I traced back coreboot_table.c. I replace the add_mainboard_resources() with it used to be, that is, lb_add_memory_range(). Then the e820 is right and SATA DMA also works . I really don't know why it happens. I will keep dig it. If you guys have any idea, please let us know. Zheng -Original Message- From: coreboot-boun...@coreboot.org [mailto:coreboot-boun...@coreboot.org] On Behalf Of Carl-Daniel Hailfinger Sent: Thursday, December 18, 2008 12:02 AM To: Coreboot Subject: Re: [coreboot] Asus M2A-VM On 17.12.2008 16:11, Peter Stuge wrote: > Carl-Daniel Hailfinger wrote: > >> my Asus M2A-VM (690G/SB600) is working and boots to memtest and FILO. >> > > Nice progress! Looking forward to hearing more. > The kernel hangs on SATA detection. That's expected, though, because SATA setup is incomplete (only first port) and does not take care of quirks of early revisions. I have a patch to set up all 4 SATA ports, but the quirk fixups still need to be implemented. And I'm hitting slightly unexpected behaviour during SATA PHY setup. I'll give more info once I have access to my logs again. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Asus M2A-VM (patch for this issue)
The prototype of lb_add_memory_range is
void lb_add_memory_range(struct lb_memory *mem,
uint32_t type, uint64_t start, uint64_t size),
whose 3rd and 4th arguments are 64bits ones. When the gcc meets this
function, it has no idea about the arguments. Sometimes it assumes they
are 32bits ones. When the linker starts to play her role, there are not
enough spaces for 2 64bits arguments. Then the tables are not correct.
Then the DMA of SATA doesn't know the spaces is reserved. Then ...
some trailing white spaces are also deleted.
This patch doesn't seem to be a long term one. Each board that has its
own memory settings should add this. If you guys have a better way to
declare the prototype, please feel free to replace it.
Zheng
Signed-off-by: Zheng Bao
Index: src/mainboard/amd/pistachio/mainboard.c
===
--- src/mainboard/amd/pistachio/mainboard.c (revision 237)
+++ src/mainboard/amd/pistachio/mainboard.c (working copy)
@@ -324,15 +324,18 @@
set_thermal_config();
}
-int add_mainboard_resources(struct lb_memory *mem)
+extern void lb_add_memory_range(struct lb_memory *mem,
+ uint32_t type, uint64_t start, uint64_t size);
+
+void add_mainboard_resources(struct lb_memory *mem)
{
/* UMA is removed from system memory in the northbridge code,
but
* in some circumstances we want the memory mentioned as
reserved.
*/
-#if (CONFIG_GFXUMA == 1)
- printk_info("uma_memory_start=0x%x, uma_memory_size=0x%x \n",
+#if (CONFIG_GFXUMA == 1)
+ printk_info("uma_memory_start=0x%x, uma_memory_size=0x%x \n",
uma_memory_start, uma_memory_size);
- lb_add_memory_range(mem, LB_MEM_RESERVED,
+ lb_add_memory_range(mem, LB_MEM_RESERVED,
uma_memory_start, uma_memory_size);
#endif
}
Index: src/mainboard/amd/dbm690t/mainboard.c
===
--- src/mainboard/amd/dbm690t/mainboard.c (revision 237)
+++ src/mainboard/amd/dbm690t/mainboard.c (working copy)
@@ -243,16 +243,19 @@
get_ide_dma66();
set_thermal_config();
}
-
-int add_mainboard_resources(struct lb_memory *mem)
+
+extern void lb_add_memory_range(struct lb_memory *mem,
+ uint32_t type, uint64_t start, uint64_t size);
+
+void add_mainboard_resources(struct lb_memory *mem)
{
/* UMA is removed from system memory in the northbridge code,
but
* in some circumstances we want the memory mentioned as
reserved.
*/
-#if (CONFIG_GFXUMA == 1)
- printk_info("uma_memory_start=0x%x, uma_memory_size=0x%x \n",
+#if (CONFIG_GFXUMA == 1)
+ printk_info("uma_memory_start=0x%x, uma_memory_size=0x%x \n",
uma_memory_start, uma_memory_size);
- lb_add_memory_range(mem, LB_MEM_RESERVED,
+ lb_add_memory_range(mem, LB_MEM_RESERVED,
uma_memory_start, uma_memory_size);
#endif
}
-Original Message-
From: coreboot-boun...@coreboot.org
[mailto:coreboot-boun...@coreboot.org] On Behalf Of Bao, Zheng
Sent: Thursday, December 18, 2008 1:18 PM
To: Carl-Daniel Hailfinger; Coreboot
Subject: Re: [coreboot] Asus M2A-VM
I traced back coreboot_table.c.
I replace the add_mainboard_resources() with it used to be, that is,
lb_add_memory_range(). Then the e820 is right and SATA DMA also works .
I really don't know why it happens. I will keep dig it. If you guys have
any idea, please let us know.
Zheng
-Original Message-
From: coreboot-boun...@coreboot.org
[mailto:coreboot-boun...@coreboot.org] On Behalf Of Carl-Daniel
Hailfinger
Sent: Thursday, December 18, 2008 12:02 AM
To: Coreboot
Subject: Re: [coreboot] Asus M2A-VM
On 17.12.2008 16:11, Peter Stuge wrote:
> Carl-Daniel Hailfinger wrote:
>
>> my Asus M2A-VM (690G/SB600) is working and boots to memtest and FILO.
>>
>
> Nice progress! Looking forward to hearing more.
>
The kernel hangs on SATA detection. That's expected, though, because
SATA setup is incomplete (only first port) and does not take care of
quirks of early revisions. I have a patch to set up all 4 SATA ports,
but the quirk fixups still need to be implemented.
And I'm hitting slightly unexpected behaviour during SATA PHY setup.
I'll give more info once I have access to my logs again.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
cb_table.patch
Description: cb_table.patch
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Asus M2A-VM (patch for this issue)
If the previous patch is adopted, we also need to change the return
value of add_mainboard_resources.
Do we?
Zheng
Index: src/arch/i386/boot/coreboot_table.h
===
--- src/arch/i386/boot/coreboot_table.h (revision 237)
+++ src/arch/i386/boot/coreboot_table.h (working copy)
@@ -27,6 +27,6 @@
extern struct cmos_option_table option_table;
/* defined by mainboard.c if the mainboard requires extra resources */
-int add_mainboard_resources(struct lb_memory *mem);
+void add_mainboard_resources(struct lb_memory *mem);
#endif /* COREBOOT_TABLE_H */
-Original Message-
From: coreboot-boun...@coreboot.org
[mailto:coreboot-boun...@coreboot.org] On Behalf Of Bao, Zheng
Sent: Thursday, December 18, 2008 4:05 PM
To: Carl-Daniel Hailfinger; Coreboot
Subject: Re: [coreboot] Asus M2A-VM (patch for this issue)
The prototype of lb_add_memory_range is
void lb_add_memory_range(struct lb_memory *mem,
uint32_t type, uint64_t start, uint64_t size),
whose 3rd and 4th arguments are 64bits ones. When the gcc meets this
function, it has no idea about the arguments. Sometimes it assumes they
are 32bits ones. When the linker starts to play her role, there are not
enough spaces for 2 64bits arguments. Then the tables are not correct.
Then the DMA of SATA doesn't know the spaces is reserved. Then ...
some trailing white spaces are also deleted.
This patch doesn't seem to be a long term one. Each board that has its
own memory settings should add this. If you guys have a better way to
declare the prototype, please feel free to replace it.
Zheng
Signed-off-by: Zheng Bao
Index: src/mainboard/amd/pistachio/mainboard.c
===
--- src/mainboard/amd/pistachio/mainboard.c (revision 237)
+++ src/mainboard/amd/pistachio/mainboard.c (working copy)
@@ -324,15 +324,18 @@
set_thermal_config();
}
-int add_mainboard_resources(struct lb_memory *mem)
+extern void lb_add_memory_range(struct lb_memory *mem,
+ uint32_t type, uint64_t start, uint64_t size);
+
+void add_mainboard_resources(struct lb_memory *mem)
{
/* UMA is removed from system memory in the northbridge code,
but
* in some circumstances we want the memory mentioned as
reserved.
*/
-#if (CONFIG_GFXUMA == 1)
- printk_info("uma_memory_start=0x%x, uma_memory_size=0x%x \n",
+#if (CONFIG_GFXUMA == 1)
+ printk_info("uma_memory_start=0x%x, uma_memory_size=0x%x \n",
uma_memory_start, uma_memory_size);
- lb_add_memory_range(mem, LB_MEM_RESERVED,
+ lb_add_memory_range(mem, LB_MEM_RESERVED,
uma_memory_start, uma_memory_size);
#endif
}
Index: src/mainboard/amd/dbm690t/mainboard.c
===
--- src/mainboard/amd/dbm690t/mainboard.c (revision 237)
+++ src/mainboard/amd/dbm690t/mainboard.c (working copy)
@@ -243,16 +243,19 @@
get_ide_dma66();
set_thermal_config();
}
-
-int add_mainboard_resources(struct lb_memory *mem)
+
+extern void lb_add_memory_range(struct lb_memory *mem,
+ uint32_t type, uint64_t start, uint64_t size);
+
+void add_mainboard_resources(struct lb_memory *mem)
{
/* UMA is removed from system memory in the northbridge code,
but
* in some circumstances we want the memory mentioned as
reserved.
*/
-#if (CONFIG_GFXUMA == 1)
- printk_info("uma_memory_start=0x%x, uma_memory_size=0x%x \n",
+#if (CONFIG_GFXUMA == 1)
+ printk_info("uma_memory_start=0x%x, uma_memory_size=0x%x \n",
uma_memory_start, uma_memory_size);
- lb_add_memory_range(mem, LB_MEM_RESERVED,
+ lb_add_memory_range(mem, LB_MEM_RESERVED,
uma_memory_start, uma_memory_size);
#endif
}
-Original Message-
From: coreboot-boun...@coreboot.org
[mailto:coreboot-boun...@coreboot.org] On Behalf Of Bao, Zheng
Sent: Thursday, December 18, 2008 1:18 PM
To: Carl-Daniel Hailfinger; Coreboot
Subject: Re: [coreboot] Asus M2A-VM
I traced back coreboot_table.c.
I replace the add_mainboard_resources() with it used to be, that is,
lb_add_memory_range(). Then the e820 is right and SATA DMA also works .
I really don't know why it happens. I will keep dig it. If you guys have
any idea, please let us know.
Zheng
-Original Message-
From: coreboot-boun...@coreboot.org
[mailto:coreboot-boun...@coreboot.org] On Behalf Of Carl-Daniel
Hailfinger
Sent: Thursday, December 18, 2008 12:02 AM
To: Coreboot
Subject: Re: [coreboot] Asus M2A-VM
On 17.12.2008 16:11, Peter Stuge wrote:
> Carl-Daniel Hailfinger wrote:
>
>> my Asus M2A-VM (690G/SB600) is working and boots to memtest and FILO.
>>
>
> Nice progress! Looking forward to hearing more.
>
The kernel hangs on SATA detection. That's expected, though, because
SATA setup
Re: [coreboot] [RFC] Error out on implicit declarations
Signed-off-by: Maggie Li maggie...@amd.com Reviewed-by: Zheng bao From: coreboot-boun...@coreboot.org [mailto:coreboot-boun...@coreboot.org] On Behalf Of Li, Maggie Sent: Friday, December 19, 2008 4:56 PM To: Coreboot Subject: Re: [coreboot] [RFC] Error out on implicit declarations Hi, Here are the patches for fixing implicit declarations in amdk8, dbm690t and pistachio. Please help me check it. Thanks. Maggie li -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] FW: [RFC] Error out on implicit declarations
I have modified the patch. The changes are limited to board and southbridge code. Zheng Signed-off-by: Maggie Li maggie...@amd.com Reviewed-by: Zheng bao dbm690t_implicit_declaration_fix.patch Description: dbm690t_implicit_declaration_fix.patch pistachio_implicit_declaration_fix.patch Description: pistachio_implicit_declaration_fix.patch sb600_implicit_declaration_fix.patch Description: sb600_implicit_declaration_fix.patch -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SB600 flashrom hang (Patch)
We have tested on the LPC and SPI ROM. The timeout value is OK on our board. You'd better test it on your board. Signed-off-by: Zheng bao -Original Message- From: coreboot-boun...@coreboot.org [mailto:coreboot-boun...@coreboot.org] On Behalf Of Carl-Daniel Hailfinger Sent: Tuesday, December 09, 2008 1:16 AM To: Coreboot Subject: [coreboot] SB600 flashrom hang Hi, on my Asus M2A-VM, latest flashrom hangs while trying to access SB600 SPI. flashrom -V Calibrating delay loop... 365M loops per second, 100 myus = 83 us. OK. No coreboot table found. Found chipset "ATI(AMD) SB600", enabling flash write... SPI base address is at 0x0 OK. Probing for AMD Am29F002(N)BB, 256 KB: probe_jedec: id1 0x0, id2 0x0, id1 parity violation Probing for AMD Am29F002(N)BT, 256 KB: probe_jedec: id1 0x0, id2 0x0, id1 parity violation Probing for AMD Am29F016D, 2048 KB: probe_29f040b: id1 0xff, id2 0xff Probing for AMD Am29F040B, 512 KB: probe_29f040b: id1 0x0, id2 0x0 Probing for AMD Am29LV040B, 512 KB: probe_29f040b: id1 0x0, id2 0x0 Probing for ASD AE49F2008, 256 KB: probe_jedec: id1 0x0, id2 0x0, id1 parity violation Probing for Atmel AT25DF021, 256 KB: sb600_spi_command, cmd=9f, writecnt=0, readcnt=3 it hangs here--- The mainboard does not have a SPI chip. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot sb600_implicit_declaration_fix.patch Description: sb600_implicit_declaration_fix.patch -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] Error out on implicit declarations
Carl-Daniel, Can you acked-by these patches for implicit declaration? Zheng -Original Message- From: coreboot-boun...@coreboot.org [mailto:coreboot-boun...@coreboot.org] On Behalf Of Bao, Zheng Sent: Monday, December 22, 2008 10:15 AM To: Coreboot Cc: Li, Maggie Subject: [coreboot] FW: [RFC] Error out on implicit declarations I have modified the patch. The changes are limited to board and southbridge code. Zheng Signed-off-by: Maggie Li maggie...@amd.com Reviewed-by: Zheng bao dbm690t_implicit_declaration_fix.patch Description: dbm690t_implicit_declaration_fix.patch pistachio_implicit_declaration_fix.patch Description: pistachio_implicit_declaration_fix.patch sb600_implicit_declaration_fix.patch Description: sb600_implicit_declaration_fix.patch -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SB600 flashrom hang (Patch)
Sorry, I sent the wrong patch. This is the patch for flashrom hanging. Zheng -Original Message- From: coreboot-boun...@coreboot.org [mailto:coreboot-boun...@coreboot.org] On Behalf Of Bao, Zheng Sent: Monday, December 22, 2008 6:44 PM To: Carl-Daniel Hailfinger; Coreboot Subject: Re: [coreboot] SB600 flashrom hang (Patch) We have tested on the LPC and SPI ROM. The timeout value is OK on our board. You'd better test it on your board. Signed-off-by: Zheng bao -Original Message- From: coreboot-boun...@coreboot.org [mailto:coreboot-boun...@coreboot.org] On Behalf Of Carl-Daniel Hailfinger Sent: Tuesday, December 09, 2008 1:16 AM To: Coreboot Subject: [coreboot] SB600 flashrom hang Hi, on my Asus M2A-VM, latest flashrom hangs while trying to access SB600 SPI. flashrom -V Calibrating delay loop... 365M loops per second, 100 myus = 83 us. OK. No coreboot table found. Found chipset "ATI(AMD) SB600", enabling flash write... SPI base address is at 0x0 OK. Probing for AMD Am29F002(N)BB, 256 KB: probe_jedec: id1 0x0, id2 0x0, id1 parity violation Probing for AMD Am29F002(N)BT, 256 KB: probe_jedec: id1 0x0, id2 0x0, id1 parity violation Probing for AMD Am29F016D, 2048 KB: probe_29f040b: id1 0xff, id2 0xff Probing for AMD Am29F040B, 512 KB: probe_29f040b: id1 0x0, id2 0x0 Probing for AMD Am29LV040B, 512 KB: probe_29f040b: id1 0x0, id2 0x0 Probing for ASD AE49F2008, 256 KB: probe_jedec: id1 0x0, id2 0x0, id1 parity violation Probing for Atmel AT25DF021, 256 KB: sb600_spi_command, cmd=9f, writecnt=0, readcnt=3 it hangs here--- The mainboard does not have a SPI chip. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot flashrom_sb600_fix_hang.patch Description: flashrom_sb600_fix_hang.patch -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Fix SB600 SATA and add support for port 2-4
Testing is a rapid process. I need some time to truly review it to understand your code. Acked-by will be added later. Zheng -Original Message- From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2...@gmx.net] Sent: Tuesday, December 23, 2008 10:37 AM To: Bao, Zheng Cc: Coreboot Subject: Re: [PATCH] Fix SB600 SATA and add support for port 2-4 Hi Zheng, On 23.12.2008 03:26, Bao, Zheng wrote: > Reviewed-by: zheng bao > > It is tested well on dbm690t and pistachio. > Thank you for the fast review! Our commit process is a bit difficult because it needs an Acked-by: statement. (The subversion repository will reject a commit without Acked-by.) Everybody who understands the code is allowed to ack a patch. You understand that piece of code very well, so could you please also add an Acked-by statement? Thanks! Regards, Carl-Daniel > -Original Message- > From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2...@gmx.net] > Sent: Tuesday, December 23, 2008 10:01 AM > To: Coreboot > Cc: Bao, Zheng > Subject: [PATCH] Fix SB600 SATA and add support for port 2-4 > > The SB600 RPR documentation does not mention what to do if SATA_BAR0+6 > is no longer 0xA0 or 0xB0. It simply assumes that will never happen. > My 500 GB Seagate Barracuda ST3500820AS triggers that corner case on the > first init after poweron. > The current code hangs forever with my drive. Fix this by rerunning the > init sequence after SATA_BAR0+6 is no longer 0xA0 or 0xB0. > > Add support for SATA port 2-4 (Primary Slave, Secondary Master, > Secondary Slave). > > Activate and improve debug messages for SPEW log level. > > Fix some comments. > > New log messages look like this: > PCI: 00:12.0 init > sata_bar0=3020 > sata_bar1=3060 > sata_bar2=3030 > sata_bar3=3070 > sata_bar4=3000 > sata_bar5=fc309000 > SATA port 0 status = 23 > 0x6=a0, 0x7=80 > drive detection not yet completed, waiting... > 0x6=a0, 0x7=80 > drive detection not yet completed, waiting... > [... 281 repetitions ...] > 0x6=0, 0x7=50 > drive no longer selected after 2830 ms, retrying init > drive detection done after 10 ms > Primary Master device is ready > SATA port 1 status = 23 > drive detection done after 10 ms > Primary Slave device is ready > SATA port 2 status = 0 > No Secondary Master SATA drive on Slot2 > SATA port 3 status = 0 > No Secondary Slave SATA drive on Slot3 > > Full log is attached. > > With this patch (and my other non-SATA fixups), my Asus M2A-VM boots > into Linux without problems. > > Signed-off-by: Carl-Daniel Hailfinger > > > -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] Error out on implicit declarations
My patch about acpi_tables.c has nothing to do with implicit
declaration. But it also output warnings and should be fixed. I agree
with other improvement you made.
--- coreboot-v2-org/src/mainboard/amd/dbm690t/acpi_tables.c
2008-12-02 02:56:38.0 +0800
+++ ../coreboot-v2/src/mainboard/amd/dbm690t/acpi_tables.c
2008-12-19 15:35:29.0 +0800
@@ -133,12 +133,12 @@
u32 *v;
struct cpuid_result cpuid1;
- typedef struct power_limit_encoding {
+ typedef struct _power_limit_encoding {
u8 socket_type;
u8 cmp_cap;
u8 pwr_lmt;
u32 power_limit;
- };
+ } power_limit_encoding;
u8 Max_fid, Max_vid, Start_fid, Start_vid, Min_fid, Min_vid;
u16 Max_feq;
u8 Pstate_fid[10];
@@ -167,7 +167,7 @@
u32 new_package_length;
u8 sum, checksum;
u32 fid_multiplier;
- static struct power_limit_encoding TDP[20] = {
+ static power_limit_encoding TDP[20] = {
{0x11, 0x0, 0x8, 62},
{0x11, 0x1, 0x8, 89},
{0x11, 0x1, 0xa, 103},
-Original Message-
From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2...@gmx.net]
Sent: Tuesday, December 23, 2008 10:31 AM
To: Bao, Zheng
Cc: coreboot@coreboot.org
Subject: Re: [coreboot] [RFC] Error out on implicit declarations
Hi Zheng,
sorry for the delayed response.
On 23.12.2008 03:02, Bao, Zheng wrote:
> Carl-Daniel,
> Can you acked-by these patches for implicit declaration?
>
The SB600 patch is
Acked-by: Carl-Daniel Hailfinger
and committed in revision 3837.
I think we can make the DBM690T patch shorter. What do you think?
Fix implicit declarations in the AMD DBM690T target by using the right
header files.
Signed-off-by: Carl-Daniel Hailfinger
Index: LinuxBIOSv2-asus_m2a-vm/src/mainboard/amd/dbm690t/fadt.c
===
--- LinuxBIOSv2-asus_m2a-vm/src/mainboard/amd/dbm690t/fadt.c
(Revision 3837)
+++ LinuxBIOSv2-asus_m2a-vm/src/mainboard/amd/dbm690t/fadt.c
(Arbeitskopie)
@@ -25,6 +25,8 @@
#include
#include
#include
+#include
+#include <../southbridge/amd/sb600/sb600.h>
/*extern*/ u16 pm_base = 0x800;
/* pm_base should be set in sb acpi */
Index: LinuxBIOSv2-asus_m2a-vm/src/mainboard/amd/dbm690t/mainboard.c
===
--- LinuxBIOSv2-asus_m2a-vm/src/mainboard/amd/dbm690t/mainboard.c
(Revision 3837)
+++ LinuxBIOSv2-asus_m2a-vm/src/mainboard/amd/dbm690t/mainboard.c
(Arbeitskopie)
@@ -25,6 +25,7 @@
#include
#include
#include
+#include <../southbridge/amd/sb600/sb600.h>
#include "chip.h"
#define ADT7461_ADDRESS 0x4C
@@ -34,6 +35,8 @@
extern int do_smbus_read_byte(u32 smbus_io_base, u32 device, u32
address);
extern int do_smbus_write_byte(u32 smbus_io_base, u32 device, u32
address,
u8 val);
+extern void lb_add_memory_range(struct lb_memory *mem, uint32_t type,
+ uint64_t start, uint64_t size);
#define ADT7461_read_byte(address) \
do_smbus_read_byte(SMBUS_IO_BASE, ADT7461_ADDRESS, address)
#define ARA_read_byte(address) \
--
http://www.hailfinger.org/
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] Error out on implicit declarations
Agree.
I sent last 2 duplicated mails before I saw your mail.
Zheng
-Original Message-
From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2...@gmx.net]
Sent: Tuesday, December 23, 2008 10:50 AM
To: Bao, Zheng
Cc: coreboot@coreboot.org
Subject: Re: [coreboot] [RFC] Error out on implicit declarations
Hi Zheng,
I have found a shorter way to fix the power_limit_encoding warnings.
What do you think?
Regards,
Carl-Daniel
Remove a unneccessary typedef from acpi_tables.c in the AMD Pistachio
and DBM690T targets.
Signed-off-by: Carl-Daniel Hailfinger
--- LinuxBIOSv2-asus_m2a-vm/src/mainboard/amd/pistachio/acpi_tables.c
(Revision 3837)
+++ LinuxBIOSv2-asus_m2a-vm/src/mainboard/amd/pistachio/acpi_tables.c
(Arbeitskopie)
@@ -133,7 +133,7 @@
u32 *v;
struct cpuid_result cpuid1;
- typedef struct power_limit_encoding {
+ struct power_limit_encoding {
u8 socket_type;
u8 cmp_cap;
u8 pwr_lmt;
--- LinuxBIOSv2-asus_m2a-vm/src/mainboard/amd/dbm690t/acpi_tables.c
(Revision 3837)
+++ LinuxBIOSv2-asus_m2a-vm/src/mainboard/amd/dbm690t/acpi_tables.c
(Arbeitskopie)
@@ -133,7 +133,7 @@
u32 *v;
struct cpuid_result cpuid1;
- typedef struct power_limit_encoding {
+ struct power_limit_encoding {
u8 socket_type;
u8 cmp_cap;
u8 pwr_lmt;
--
http://www.hailfinger.org/
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SB600 flashrom hang (Patch)
Hi, If the usec_delay() is called, the programming action will be unbearably slow. I haven't got a way to solve this. Zheng -Original Message- From: coreboot-boun...@coreboot.org [mailto:coreboot-boun...@coreboot.org] On Behalf Of Peter Stuge Sent: Tuesday, December 23, 2008 10:16 AM To: Coreboot Subject: Re: [coreboot] SB600 flashrom hang (Patch) Hi, Bao, Zheng wrote: > We have tested on the LPC and SPI ROM. The timeout value is OK on > our board. You'd better test it on your board. > > Signed-off-by: Zheng bao I would like to improve the busy wait loop. Is 1 ms the desired timeout? In that case the myusec_delay(1000) call is good. Is it better if the delay is longer or shorter than 1 ms? //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Fix SB600 SATA and add support for port 2-4
In sata_drive_detect(), the loop seems to be loop forever if detection is not completed. Does the "i" have a timeout value? Some indents are actually several spaces instead of tab. Please note this. Zheng -Original Message- From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2...@gmx.net] Sent: Tuesday, December 23, 2008 10:37 AM To: Bao, Zheng Cc: Coreboot Subject: Re: [PATCH] Fix SB600 SATA and add support for port 2-4 Hi Zheng, On 23.12.2008 03:26, Bao, Zheng wrote: > Reviewed-by: zheng bao > > It is tested well on dbm690t and pistachio. > Thank you for the fast review! Our commit process is a bit difficult because it needs an Acked-by: statement. (The subversion repository will reject a commit without Acked-by.) Everybody who understands the code is allowed to ack a patch. You understand that piece of code very well, so could you please also add an Acked-by statement? Thanks! Regards, Carl-Daniel > -Original Message- > From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2...@gmx.net] > Sent: Tuesday, December 23, 2008 10:01 AM > To: Coreboot > Cc: Bao, Zheng > Subject: [PATCH] Fix SB600 SATA and add support for port 2-4 > > The SB600 RPR documentation does not mention what to do if SATA_BAR0+6 > is no longer 0xA0 or 0xB0. It simply assumes that will never happen. > My 500 GB Seagate Barracuda ST3500820AS triggers that corner case on the > first init after poweron. > The current code hangs forever with my drive. Fix this by rerunning the > init sequence after SATA_BAR0+6 is no longer 0xA0 or 0xB0. > > Add support for SATA port 2-4 (Primary Slave, Secondary Master, > Secondary Slave). > > Activate and improve debug messages for SPEW log level. > > Fix some comments. > > New log messages look like this: > PCI: 00:12.0 init > sata_bar0=3020 > sata_bar1=3060 > sata_bar2=3030 > sata_bar3=3070 > sata_bar4=3000 > sata_bar5=fc309000 > SATA port 0 status = 23 > 0x6=a0, 0x7=80 > drive detection not yet completed, waiting... > 0x6=a0, 0x7=80 > drive detection not yet completed, waiting... > [... 281 repetitions ...] > 0x6=0, 0x7=50 > drive no longer selected after 2830 ms, retrying init > drive detection done after 10 ms > Primary Master device is ready > SATA port 1 status = 23 > drive detection done after 10 ms > Primary Slave device is ready > SATA port 2 status = 0 > No Secondary Master SATA drive on Slot2 > SATA port 3 status = 0 > No Secondary Slave SATA drive on Slot3 > > Full log is attached. > > With this patch (and my other non-SATA fixups), my Asus M2A-VM boots > into Linux without problems. > > Signed-off-by: Carl-Daniel Hailfinger > > > -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RS690 HT init
It has been tested on dbm690t which HT link works on 800Mhz. Zheng -Original Message- From: coreboot-boun...@coreboot.org [mailto:coreboot-boun...@coreboot.org] On Behalf Of Peter Stuge Sent: Tuesday, December 23, 2008 11:59 AM To: Coreboot Subject: Re: [coreboot] RS690 HT init Carl-Daniel Hailfinger wrote: > Handle RS690 quirks for 1 GHz noncoherent HyperTransport. > > Tested, works on my Asus M2A-VM with an 1 GHz HT capable processor. > > Signed-off-by: Carl-Daniel Hailfinger Acked-by: Peter Stuge -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Fix SB600 SATA and add support for port 2-4
Sorry, I tested it again and tried it on 4 ports. It only works on 1st and 4th ports, while doesn't work on 2nd and 3rd ports. It loops at driver no longer selected after 10ms, retrying init driver no longer selected after 10ms, retrying init driver no longer selected after 10ms, retrying init driver no longer selected after 10ms, retrying init driver no longer selected after 10ms, retrying init My SATA drive is 250 GB Seagate Barracuda ST3250620NS. Zheng -Original Message- From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2...@gmx.net] Sent: Tuesday, December 23, 2008 12:01 PM To: Bao, Zheng Cc: Coreboot Subject: Re: [coreboot] [PATCH] Fix SB600 SATA and add support for port 2-4 On 23.12.2008 04:51, Bao, Zheng wrote: > In sata_drive_detect(), the loop seems to be loop forever if detection > is not completed. Does the "i" have a timeout value? > No, there is no timeout. "i" was there to tell me how long it takes, but I can use it to check for a timeout. I will fix this. > Some indents are actually several spaces instead of tab. Please note > this. > Thanks for telling me. I will clean up and resend. Some indents have tabs and spaces to have exact indentation at the beginning of the parentheses. Regards, Carl-Daniel > Zheng > > -Original Message- > From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2...@gmx.net] > Sent: Tuesday, December 23, 2008 10:37 AM > To: Bao, Zheng > Cc: Coreboot > Subject: Re: [PATCH] Fix SB600 SATA and add support for port 2-4 > > Hi Zheng, > > On 23.12.2008 03:26, Bao, Zheng wrote: > >> Reviewed-by: zheng bao >> >> It is tested well on dbm690t and pistachio. >> >> > > Thank you for the fast review! > > Our commit process is a bit difficult because it needs an Acked-by: > statement. (The subversion repository will reject a commit without > Acked-by.) > > Everybody who understands the code is allowed to ack a patch. You > understand that piece of code very well, so could you please also add an > Acked-by statement? Thanks! > > Regards, > Carl-Daniel > > >> -Original Message----- >> From: Carl-Daniel Hailfinger >> > [mailto:c-d.hailfinger.devel.2...@gmx.net] > >> Sent: Tuesday, December 23, 2008 10:01 AM >> To: Coreboot >> Cc: Bao, Zheng >> Subject: [PATCH] Fix SB600 SATA and add support for port 2-4 >> >> The SB600 RPR documentation does not mention what to do if SATA_BAR0+6 >> is no longer 0xA0 or 0xB0. It simply assumes that will never happen. >> My 500 GB Seagate Barracuda ST3500820AS triggers that corner case on >> > the > >> first init after poweron. >> The current code hangs forever with my drive. Fix this by rerunning >> > the > >> init sequence after SATA_BAR0+6 is no longer 0xA0 or 0xB0. >> >> Add support for SATA port 2-4 (Primary Slave, Secondary Master, >> Secondary Slave). >> >> Activate and improve debug messages for SPEW log level. >> >> Fix some comments. >> >> New log messages look like this: >> PCI: 00:12.0 init >> sata_bar0=3020 >> sata_bar1=3060 >> sata_bar2=3030 >> sata_bar3=3070 >> sata_bar4=3000 >> sata_bar5=fc309000 >> SATA port 0 status = 23 >> 0x6=a0, 0x7=80 >> drive detection not yet completed, waiting... >> 0x6=a0, 0x7=80 >> drive detection not yet completed, waiting... >> [... 281 repetitions ...] >> 0x6=0, 0x7=50 >> drive no longer selected after 2830 ms, retrying init >> drive detection done after 10 ms >> Primary Master device is ready >> SATA port 1 status = 23 >> drive detection done after 10 ms >> Primary Slave device is ready >> SATA port 2 status = 0 >> No Secondary Master SATA drive on Slot2 >> SATA port 3 status = 0 >> No Secondary Slave SATA drive on Slot3 >> >> Full log is attached. >> >> With this patch (and my other non-SATA fixups), my Asus M2A-VM boots >> into Linux without problems. >> >> Signed-off-by: Carl-Daniel Hailfinger >> >> >> >> > > -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] Error out on implicit declarations
Acked-by: Zheng Bao
-Original Message-
From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2...@gmx.net]
Sent: Tuesday, December 23, 2008 10:50 AM
To: Bao, Zheng
Cc: coreboot@coreboot.org
Subject: Re: [coreboot] [RFC] Error out on implicit declarations
Hi Zheng,
I have found a shorter way to fix the power_limit_encoding warnings.
What do you think?
Regards,
Carl-Daniel
Remove a unneccessary typedef from acpi_tables.c in the AMD Pistachio
and DBM690T targets.
Signed-off-by: Carl-Daniel Hailfinger
--- LinuxBIOSv2-asus_m2a-vm/src/mainboard/amd/pistachio/acpi_tables.c
(Revision 3837)
+++ LinuxBIOSv2-asus_m2a-vm/src/mainboard/amd/pistachio/acpi_tables.c
(Arbeitskopie)
@@ -133,7 +133,7 @@
u32 *v;
struct cpuid_result cpuid1;
- typedef struct power_limit_encoding {
+ struct power_limit_encoding {
u8 socket_type;
u8 cmp_cap;
u8 pwr_lmt;
--- LinuxBIOSv2-asus_m2a-vm/src/mainboard/amd/dbm690t/acpi_tables.c
(Revision 3837)
+++ LinuxBIOSv2-asus_m2a-vm/src/mainboard/amd/dbm690t/acpi_tables.c
(Arbeitskopie)
@@ -133,7 +133,7 @@
u32 *v;
struct cpuid_result cpuid1;
- typedef struct power_limit_encoding {
+ struct power_limit_encoding {
u8 socket_type;
u8 cmp_cap;
u8 pwr_lmt;
--
http://www.hailfinger.org/
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] Error out on implicit declarations
Acked-by: Zheng Bao -Original Message- From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2...@gmx.net] Sent: Tuesday, December 23, 2008 10:31 AM To: Bao, Zheng Cc: coreboot@coreboot.org Subject: Re: [coreboot] [RFC] Error out on implicit declarations Hi Zheng, sorry for the delayed response. On 23.12.2008 03:02, Bao, Zheng wrote: > Carl-Daniel, > Can you acked-by these patches for implicit declaration? > The SB600 patch is Acked-by: Carl-Daniel Hailfinger and committed in revision 3837. I think we can make the DBM690T patch shorter. What do you think? Fix implicit declarations in the AMD DBM690T target by using the right header files. Signed-off-by: Carl-Daniel Hailfinger Index: LinuxBIOSv2-asus_m2a-vm/src/mainboard/amd/dbm690t/fadt.c === --- LinuxBIOSv2-asus_m2a-vm/src/mainboard/amd/dbm690t/fadt.c (Revision 3837) +++ LinuxBIOSv2-asus_m2a-vm/src/mainboard/amd/dbm690t/fadt.c (Arbeitskopie) @@ -25,6 +25,8 @@ #include #include #include +#include +#include <../southbridge/amd/sb600/sb600.h> /*extern*/ u16 pm_base = 0x800; /* pm_base should be set in sb acpi */ Index: LinuxBIOSv2-asus_m2a-vm/src/mainboard/amd/dbm690t/mainboard.c === --- LinuxBIOSv2-asus_m2a-vm/src/mainboard/amd/dbm690t/mainboard.c (Revision 3837) +++ LinuxBIOSv2-asus_m2a-vm/src/mainboard/amd/dbm690t/mainboard.c (Arbeitskopie) @@ -25,6 +25,7 @@ #include #include #include +#include <../southbridge/amd/sb600/sb600.h> #include "chip.h" #define ADT7461_ADDRESS 0x4C @@ -34,6 +35,8 @@ extern int do_smbus_read_byte(u32 smbus_io_base, u32 device, u32 address); extern int do_smbus_write_byte(u32 smbus_io_base, u32 device, u32 address, u8 val); +extern void lb_add_memory_range(struct lb_memory *mem, uint32_t type, + uint64_t start, uint64_t size); #define ADT7461_read_byte(address) \ do_smbus_read_byte(SMBUS_IO_BASE, ADT7461_ADDRESS, address) #define ARA_read_byte(address) \ -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] Error out on implicit declarations
Hi, Carl-Daniel, I deleted trailing white spaces in your dbm690t patch. I think the style of pistachio should be match with dbm690t. Do you think? Zheng Signed-off-by: Zheng Bao -Original Message- From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2...@gmx.net] Sent: Tuesday, December 23, 2008 10:31 AM To: Bao, Zheng Cc: coreboot@coreboot.org Subject: Re: [coreboot] [RFC] Error out on implicit declarations Hi Zheng, sorry for the delayed response. On 23.12.2008 03:02, Bao, Zheng wrote: > Carl-Daniel, > Can you acked-by these patches for implicit declaration? > The SB600 patch is Acked-by: Carl-Daniel Hailfinger and committed in revision 3837. I think we can make the DBM690T patch shorter. What do you think? Fix implicit declarations in the AMD DBM690T target by using the right header files. Signed-off-by: Carl-Daniel Hailfinger Index: LinuxBIOSv2-asus_m2a-vm/src/mainboard/amd/dbm690t/fadt.c === --- LinuxBIOSv2-asus_m2a-vm/src/mainboard/amd/dbm690t/fadt.c (Revision 3837) +++ LinuxBIOSv2-asus_m2a-vm/src/mainboard/amd/dbm690t/fadt.c (Arbeitskopie) @@ -25,6 +25,8 @@ #include #include #include +#include +#include <../southbridge/amd/sb600/sb600.h> /*extern*/ u16 pm_base = 0x800; /* pm_base should be set in sb acpi */ Index: LinuxBIOSv2-asus_m2a-vm/src/mainboard/amd/dbm690t/mainboard.c === --- LinuxBIOSv2-asus_m2a-vm/src/mainboard/amd/dbm690t/mainboard.c (Revision 3837) +++ LinuxBIOSv2-asus_m2a-vm/src/mainboard/amd/dbm690t/mainboard.c (Arbeitskopie) @@ -25,6 +25,7 @@ #include #include #include +#include <../southbridge/amd/sb600/sb600.h> #include "chip.h" #define ADT7461_ADDRESS 0x4C @@ -34,6 +35,8 @@ extern int do_smbus_read_byte(u32 smbus_io_base, u32 device, u32 address); extern int do_smbus_write_byte(u32 smbus_io_base, u32 device, u32 address, u8 val); +extern void lb_add_memory_range(struct lb_memory *mem, uint32_t type, + uint64_t start, uint64_t size); #define ADT7461_read_byte(address) \ do_smbus_read_byte(SMBUS_IO_BASE, ADT7461_ADDRESS, address) #define ARA_read_byte(address) \ -- http://www.hailfinger.org/ dbm690t_implicit.patch Description: dbm690t_implicit.patch pistachio_implicit.patch Description: pistachio_implicit.patch -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SB600 flashrom hang (Patch)
myusec_delay(1) is fine. Even if we do myusec_delay(2), it will do slowly. Zheng Signed-off-by: Zheng Bao -Original Message- From: coreboot-bounces+zheng.bao=amd@coreboot.org [mailto:coreboot-bounces+zheng.bao=amd@coreboot.org] On Behalf Of Peter Stuge Sent: Tuesday, December 23, 2008 1:49 PM To: Coreboot Subject: Re: [coreboot] SB600 flashrom hang (Patch) Bao, Zheng wrote: > If the usec_delay() is called, the programming action will be > unbearably slow. I haven't got a way to solve this. What is the intended timeout period? Try using myusec_delay(3) or another low number. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot flashrom_sb600_fix_hang.patch Description: flashrom_sb600_fix_hang.patch -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Merry Christmas!
Just for fun? Does it look like coreboot logo? (`. ,-, `\ `.,;' / \`. \ ,'/ .' __ `.\ Y /.' .-' ''--.._` ` ( .'/ ` , ` ' Q ' , , `._\ | ' `-.;_' ` ;` ` --,.._; `, ) .' `._ , ' /_ ; ,''-,;' ``- ``-..__\``--` -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Fix SB600 SATA and add support for port 2-4
I just tested as the latter one you said. That is, I have only 1 sata drive, attached to each port every time. We have CIM code in assembly code. I don't know if I can provide it. I will check it ASAP. But now it is Christmas Eve in our time zone. I have to go out and have fun. :) Zheng -Original Message- From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2...@gmx.net] Sent: Wednesday, December 24, 2008 4:00 PM To: Bao, Zheng Cc: Coreboot Subject: Re: [coreboot] [PATCH] Fix SB600 SATA and add support for port 2-4 On 23.12.2008 08:10, Bao, Zheng wrote: > Sorry, I tested it again and tried it on 4 ports. It only works on 1st > and 4th ports, while doesn't work on 2nd and 3rd ports. It loops at > driver no longer selected after 10ms, retrying init > driver no longer selected after 10ms, retrying init > driver no longer selected after 10ms, retrying init > driver no longer selected after 10ms, retrying init > driver no longer selected after 10ms, retrying init > > > My SATA drive is 250 GB Seagate Barracuda ST3250620NS. > Thanks for testing! This is very strange. It seems the hardware does not follow the BDG. Did you have 4 drives attached at the same time or was it 1 drive attached to another port each time? Could you please write your own implementation of 4-port setup so we can compare this? Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Fix SB600 SATA and add support for port 2-4
What you said reminded me to connect more drives when the board boots. Yes, it changed. If 1st and 2nd ports are both connected, they can both be correctly detected and initialized. Then I unplugged the drive on 1st post and didn't change the BIOS, the 2nd ports couldn't be initialized as it was. I check our asm code and can't find any tip. Zheng -Original Message- From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2...@gmx.net] Sent: Wednesday, December 24, 2008 4:00 PM To: Bao, Zheng Cc: Coreboot Subject: Re: [coreboot] [PATCH] Fix SB600 SATA and add support for port 2-4 On 23.12.2008 08:10, Bao, Zheng wrote: > Sorry, I tested it again and tried it on 4 ports. It only works on 1st > and 4th ports, while doesn't work on 2nd and 3rd ports. It loops at > driver no longer selected after 10ms, retrying init > driver no longer selected after 10ms, retrying init > driver no longer selected after 10ms, retrying init > driver no longer selected after 10ms, retrying init > driver no longer selected after 10ms, retrying init > > > My SATA drive is 250 GB Seagate Barracuda ST3250620NS. > Thanks for testing! This is very strange. It seems the hardware does not follow the BDG. Did you have 4 drives attached at the same time or was it 1 drive attached to another port each time? Could you please write your own implementation of 4-port setup so we can compare this? Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] can AAI be used in flashrom?
The AAI (Auto Address Increment Programming) command (0xAD) can be found
in SST25VF080B. I am wondering if it is available in every SPI chip. If
yes, the SB600 pragramming would be much faster than doing it one byte
at a time. I tested on my board with SB600. I don't make a patch because
I am not sure I can do that.
Zheng
int sb600_spi_write(struct flashchip *flash, uint8_t *buf)
{
int rc = 0, i;
int total_size = flash->total_size * 1024;
uint8_t cmd[8] = {0xAD, 0x00, 0x00, 0x00};
/* Erase first */
printf("Erasing flash before programming... ");
flash->erase(flash);
printf("done.\n");
cmd[4] = buf[0];
cmd[5] = buf[1];
spi_disable_blockprotect();
spi_write_enable();
sb600_spi_command(6, 0, cmd, 0);
printf("Programming flash");
for (i = 2, buf += 2; i < total_size; i+=2, buf+=2) {
/* spi_byte_program(i, *buf); */
cmd[1] = buf[0];
cmd[2] = buf[1];
sb600_spi_command(3, 0, cmd, 0);
/* wait program complete. */
if (i % 0x8000 == 0)
printf(".");
while (spi_read_status_register() & JEDEC_RDSR_BIT_WIP)
;
}
printf(" done.\n");
spi_write_disable();
return rc;
}
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Fix SB600 SATA and add support for port 2-4
It seems to be a resolution before we can finally get the reason why
hardware behaves strange.
Please replace the multiple spaces with tab before checking in.
Acked-by: Zheng Bao
-Original Message-
From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2...@gmx.net]
Sent: Monday, December 29, 2008 10:48 AM
To: Bao, Zheng
Cc: Coreboot
Subject: Re: [coreboot] [PATCH] Fix SB600 SATA and add support for port
2-4
Hi Zheng,
On 25.12.2008 05:10, Bao, Zheng wrote:
> On 24.12.2008 16:00, Carl-Daniel Hailfinger wrote:
>
>
>> On 23.12.2008 08:10, Bao, Zheng wrote:
>>> Sorry, I tested it again and tried it on 4 ports. It only works on
1st
>>> and 4th ports, while doesn't work on 2nd and 3rd ports. It loops at
>>> driver no longer selected after 10ms, retrying init
>>> driver no longer selected after 10ms, retrying init
>>>
>>>
>>> My SATA drive is 250 GB Seagate Barracuda ST3250620NS.
>>>
>>
>> Thanks for testing!
>> This is very strange. It seems the hardware does not follow the BDG.
Did
>> you have 4 drives attached at the same time or was it 1 drive
attached
>> to another port each time?
> What you said reminded me to connect more drives when the board boots.
> Yes, it changed. If 1st and 2nd ports are both connected, they can
both
> be correctly detected and initialized. Then I unplugged the drive on
1st
> post and didn't change the BIOS, the 2nd ports couldn't be initialized
> as it was. I check our asm code and can't find any tip.
>
I have modified the code to avoid the endless loop and print better
diagnostic messages.
It will work if only 1st or if 1st and 2nd port are connected. If only
2nd is connected and the hardware acts strange, it will print an error
message and continue.
I have not tested 3rd and 4th port.
Can you please test if this works for you?
Signed-off-by: Carl-Daniel Hailfinger
Index: LinuxBIOSv2-asus_m2a-vm/src/southbridge/amd/sb600/sb600_sata.c
===
--- LinuxBIOSv2-asus_m2a-vm/src/southbridge/amd/sb600/sb600_sata.c
(Revision 3844)
+++ LinuxBIOSv2-asus_m2a-vm/src/southbridge/amd/sb600/sb600_sata.c
(Arbeitskopie)
@@ -2,6 +2,7 @@
* This file is part of the coreboot project.
*
* Copyright (C) 2008 Advanced Micro Devices, Inc.
+ * Copyright (C) 2008 Carl-Daniel Hailfinger
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -26,6 +27,28 @@
#include
#include "sb600.h"
+int sata_drive_detect(int portnum, u16 iobar)
+{
+ u8 byte, byte2;
+ int i = 0;
+ outb(0xA0 + 0x10 * (portnum % 2), iobar + 0x6);
+ while (byte = inb(iobar + 0x6),
+ byte2 = inb(iobar + 0x7),
+ (byte != (0xA0 + 0x10 * (portnum % 2))) ||
+ ((byte2 & 0x88) != 0)) {
+ printk_spew("0x6=%x, 0x7=%x\n", byte, byte2);
+ if (byte != (0xA0 + 0x10 * (portnum % 2))) {
+ printk_debug("drive no longer selected after %i
ms, retrying init\n", i * 10);
+ return 1;
+ } else
+ printk_spew("drive detection not yet completed,
waiting...\n");
+ mdelay(10);
+ i++;
+ }
+ printk_spew("drive detection done after %i ms\n", i * 10);
+ return 0;
+}
+
static void sata_init(struct device *dev)
{
u8 byte;
@@ -33,6 +56,7 @@
u32 dword;
u8 *sata_bar5;
u16 sata_bar0, sata_bar1, sata_bar2, sata_bar3, sata_bar4;
+ int i, j;
struct southbridge_ati_sb600_config *conf;
conf = dev->chip_info;
@@ -62,12 +86,12 @@
sata_bar3 = pci_read_config16(dev, 0x1C) & ~0x7;
sata_bar4 = pci_read_config16(dev, 0x20) & ~0x7;
- /* printk_debug("sata_bar0=%x\n", sata_bar0); *//* 3030
*/
- /* printk_debug("sata_bar1=%x\n", sata_bar1); *//* 3070
*/
- /* printk_debug("sata_bar2=%x\n", sata_bar2); *//* 3040
*/
- /* printk_debug("sata_bar3=%x\n", sata_bar3); *//* 3080
*/
- /* printk_debug("sata_bar4=%x\n", sata_bar4); *//* 3000
*/
- /* printk_debug("sata_bar5=%x\n", sata_bar5); *//*
e0309000 */
+ printk_spew("sata_bar0=%x\n", sata_bar0); /* 3030 */
+ printk_spew("sata_bar1=%x\n", sata_bar1); /* 3070 */
+ printk_spew("sata_bar2=%x\n", sata_bar2); /* 3040 */
+ printk_spew("sata_bar3=%x\n", sata_bar3); /* 3080 */
+ printk_spew("sata_bar4=%x\n", sata_bar4); /* 3000 */
+ printk_spew("sata_bar5=%x\n", sata_bar5); /* e
Re: [coreboot] [PATCH] Fix SB600 SATA and add support for port 2-4
I tried with proprietary BIOS and access BAR0+6 with debugging tool.
Bar0+6 are always 0x7F like it is when coreboot boots. I believe that is
some kind of hardware misleading feature.
Actually, the filo can always found the file system on each SATA port. I
think that is it. I hope.
Zheng
-Original Message-
From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2...@gmx.net]
Sent: Monday, December 29, 2008 10:48 AM
To: Bao, Zheng
Cc: Coreboot
Subject: Re: [coreboot] [PATCH] Fix SB600 SATA and add support for port
2-4
Hi Zheng,
On 25.12.2008 05:10, Bao, Zheng wrote:
> On 24.12.2008 16:00, Carl-Daniel Hailfinger wrote:
>
>
>> On 23.12.2008 08:10, Bao, Zheng wrote:
>>> Sorry, I tested it again and tried it on 4 ports. It only works on
1st
>>> and 4th ports, while doesn't work on 2nd and 3rd ports. It loops at
>>> driver no longer selected after 10ms, retrying init
>>> driver no longer selected after 10ms, retrying init
>>>
>>>
>>> My SATA drive is 250 GB Seagate Barracuda ST3250620NS.
>>>
>>
>> Thanks for testing!
>> This is very strange. It seems the hardware does not follow the BDG.
Did
>> you have 4 drives attached at the same time or was it 1 drive
attached
>> to another port each time?
> What you said reminded me to connect more drives when the board boots.
> Yes, it changed. If 1st and 2nd ports are both connected, they can
both
> be correctly detected and initialized. Then I unplugged the drive on
1st
> post and didn't change the BIOS, the 2nd ports couldn't be initialized
> as it was. I check our asm code and can't find any tip.
>
I have modified the code to avoid the endless loop and print better
diagnostic messages.
It will work if only 1st or if 1st and 2nd port are connected. If only
2nd is connected and the hardware acts strange, it will print an error
message and continue.
I have not tested 3rd and 4th port.
Can you please test if this works for you?
Signed-off-by: Carl-Daniel Hailfinger
Index: LinuxBIOSv2-asus_m2a-vm/src/southbridge/amd/sb600/sb600_sata.c
===
--- LinuxBIOSv2-asus_m2a-vm/src/southbridge/amd/sb600/sb600_sata.c
(Revision 3844)
+++ LinuxBIOSv2-asus_m2a-vm/src/southbridge/amd/sb600/sb600_sata.c
(Arbeitskopie)
@@ -2,6 +2,7 @@
* This file is part of the coreboot project.
*
* Copyright (C) 2008 Advanced Micro Devices, Inc.
+ * Copyright (C) 2008 Carl-Daniel Hailfinger
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -26,6 +27,28 @@
#include
#include "sb600.h"
+int sata_drive_detect(int portnum, u16 iobar)
+{
+ u8 byte, byte2;
+ int i = 0;
+ outb(0xA0 + 0x10 * (portnum % 2), iobar + 0x6);
+ while (byte = inb(iobar + 0x6),
+ byte2 = inb(iobar + 0x7),
+ (byte != (0xA0 + 0x10 * (portnum % 2))) ||
+ ((byte2 & 0x88) != 0)) {
+ printk_spew("0x6=%x, 0x7=%x\n", byte, byte2);
+ if (byte != (0xA0 + 0x10 * (portnum % 2))) {
+ printk_debug("drive no longer selected after %i
ms, retrying init\n", i * 10);
+ return 1;
+ } else
+ printk_spew("drive detection not yet completed,
waiting...\n");
+ mdelay(10);
+ i++;
+ }
+ printk_spew("drive detection done after %i ms\n", i * 10);
+ return 0;
+}
+
static void sata_init(struct device *dev)
{
u8 byte;
@@ -33,6 +56,7 @@
u32 dword;
u8 *sata_bar5;
u16 sata_bar0, sata_bar1, sata_bar2, sata_bar3, sata_bar4;
+ int i, j;
struct southbridge_ati_sb600_config *conf;
conf = dev->chip_info;
@@ -62,12 +86,12 @@
sata_bar3 = pci_read_config16(dev, 0x1C) & ~0x7;
sata_bar4 = pci_read_config16(dev, 0x20) & ~0x7;
- /* printk_debug("sata_bar0=%x\n", sata_bar0); *//* 3030
*/
- /* printk_debug("sata_bar1=%x\n", sata_bar1); *//* 3070
*/
- /* printk_debug("sata_bar2=%x\n", sata_bar2); *//* 3040
*/
- /* printk_debug("sata_bar3=%x\n", sata_bar3); *//* 3080
*/
- /* printk_debug("sata_bar4=%x\n", sata_bar4); *//* 3000
*/
- /* printk_debug("sata_bar5=%x\n", sata_bar5); *//*
e0309000 */
+ printk_spew("sata_bar0=%x\n", sata_bar0); /* 3030 */
+ printk_spew("sata_bar1=%x\n", sata_bar1); /* 3070 */
+ printk_spew("sata_bar2=%x\n", sata_bar2); /* 3040 */
+ printk_spew("sata_bar3=%x\n", sata_bar3); /* 3080 */
+ printk_spew("sata_bar4=%x
[coreboot] [patch]:SB600 flashrom using virtual memory
The accessing is changed to reading and writing byte to virtual memory.
Reading chip can be improved. Writing doesn't seem to get noticeable
improvement.
The patch contains my previous patch which fixes hang and is not
acked-by yet.
Zheng
diff -Nuar -x .svn -x flashrom -x '*.o' -x .dependencies
flashrom-org/chipset_enable.c
coreboot-v2-svn/util/flashrom/chipset_enable.c
--- flashrom-org/chipset_enable.c 2008-12-22 14:12:08.0
+0800
+++ coreboot-v2-svn/util/flashrom/chipset_enable.c 2008-12-23
09:46:53.0 +0800
@@ -681,8 +681,16 @@
flashbus = BUS_TYPE_SB600_SPI;
/* Enable SPI ROM in SB600 PM register. */
+ /* If we enable SPI ROM here, we have to disable it after we
leave.
+* But how can we know which ROM we are going to handle? So we
have
+* to trade off. We only access LPC ROM if we boot via LPC ROM.
And
+* only SPI ROM if we boot via SPI ROM. If you want to do it
crossly,
+* you have to use the code below.
+*/
+ /*
OUTB(0x8f, 0xcd6);
OUTB(0x0e, 0xcd7);
+ */
return 0;
}
diff -Nuar -x .svn -x flashrom -x '*.o' -x .dependencies
flashrom-org/sb600spi.c coreboot-v2-svn/util/flashrom/sb600spi.c
--- flashrom-org/sb600spi.c 2008-11-29 15:07:14.0 +0800
+++ coreboot-v2-svn/util/flashrom/sb600spi.c2008-12-29
16:17:09.0 +0800
@@ -44,13 +44,11 @@
int sb600_spi_read(struct flashchip *flash, uint8_t *buf)
{
- int rc = 0, i;
+ int rc = 0;
int total_size = flash->total_size * 1024;
- int page_size = 8;
- for (i = 0; i < total_size / page_size; i++)
- spi_nbyte_read(i * page_size, (void *)(buf + i *
page_size),
- page_size);
+ memcpy(buf, (const char *)flash->virtual_memory, total_size);
+
return rc;
}
@@ -68,17 +66,20 @@
{
int rc = 0, i;
int total_size = flash->total_size * 1024;
+ uint8_t *bios;
/* Erase first */
printf("Erasing flash before programming... ");
flash->erase(flash);
printf("done.\n");
+ spi_disable_blockprotect();
printf("Programming flash");
- for (i = 0; i < total_size; i++, buf++) {
- spi_disable_blockprotect();
+ for (i = 0, bios = (uint8_t *)flash->virtual_memory;
+ i < total_size;
+ i++, buf++, bios++) {
spi_write_enable();
- spi_byte_program(i, *buf);
+ *bios = *buf;
/* wait program complete. */
if (i % 0x8000 == 0)
printf(".");
@@ -97,12 +98,18 @@
printf("reset\n");
}
-void execute_command(void)
+int execute_command(void)
{
+ int timeout = 1000;
+
sb600_spibar[2] |= 1;
- while (sb600_spibar[2] & 1)
- ;
+ while ((sb600_spibar[2] & 1) && timeout)
+ {
+ myusec_delay(1);
+ timeout --;
+ }
+ return timeout ? 1 : 0;
}
int sb600_spi_command(unsigned int writecnt, unsigned int readcnt,
@@ -150,7 +157,8 @@
*/
reset_internal_fifo_pointer();
- execute_command();
+ if (!execute_command())
+ return 1;
/*
* After the command executed, we should find out the index of
the
flashrom_sb600_fix_hang_use_vm.patch
Description: flashrom_sb600_fix_hang_use_vm.patch
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch]:SB600 flashrom using virtual memory
Signed-off-by: Zheng Bao
-Original Message-
From: coreboot-bounces+zheng.bao=amd@coreboot.org
[mailto:coreboot-bounces+zheng.bao=amd@coreboot.org] On Behalf Of
Bao, Zheng
Sent: Monday, December 29, 2008 4:34 PM
To: Coreboot
Subject: [coreboot] [patch]:SB600 flashrom using virtual memory
The accessing is changed to reading and writing byte to virtual memory.
Reading chip can be improved. Writing doesn't seem to get noticeable
improvement.
The patch contains my previous patch which fixes hang and is not
acked-by yet.
Zheng
diff -Nuar -x .svn -x flashrom -x '*.o' -x .dependencies
flashrom-org/chipset_enable.c
coreboot-v2-svn/util/flashrom/chipset_enable.c
--- flashrom-org/chipset_enable.c 2008-12-22 14:12:08.0
+0800
+++ coreboot-v2-svn/util/flashrom/chipset_enable.c 2008-12-23
09:46:53.0 +0800
@@ -681,8 +681,16 @@
flashbus = BUS_TYPE_SB600_SPI;
/* Enable SPI ROM in SB600 PM register. */
+ /* If we enable SPI ROM here, we have to disable it after we
leave.
+* But how can we know which ROM we are going to handle? So we
have
+* to trade off. We only access LPC ROM if we boot via LPC ROM.
And
+* only SPI ROM if we boot via SPI ROM. If you want to do it
crossly,
+* you have to use the code below.
+*/
+ /*
OUTB(0x8f, 0xcd6);
OUTB(0x0e, 0xcd7);
+ */
return 0;
}
diff -Nuar -x .svn -x flashrom -x '*.o' -x .dependencies
flashrom-org/sb600spi.c coreboot-v2-svn/util/flashrom/sb600spi.c
--- flashrom-org/sb600spi.c 2008-11-29 15:07:14.0 +0800
+++ coreboot-v2-svn/util/flashrom/sb600spi.c2008-12-29
16:17:09.0 +0800
@@ -44,13 +44,11 @@
int sb600_spi_read(struct flashchip *flash, uint8_t *buf)
{
- int rc = 0, i;
+ int rc = 0;
int total_size = flash->total_size * 1024;
- int page_size = 8;
- for (i = 0; i < total_size / page_size; i++)
- spi_nbyte_read(i * page_size, (void *)(buf + i *
page_size),
- page_size);
+ memcpy(buf, (const char *)flash->virtual_memory, total_size);
+
return rc;
}
@@ -68,17 +66,20 @@
{
int rc = 0, i;
int total_size = flash->total_size * 1024;
+ uint8_t *bios;
/* Erase first */
printf("Erasing flash before programming... ");
flash->erase(flash);
printf("done.\n");
+ spi_disable_blockprotect();
printf("Programming flash");
- for (i = 0; i < total_size; i++, buf++) {
- spi_disable_blockprotect();
+ for (i = 0, bios = (uint8_t *)flash->virtual_memory;
+ i < total_size;
+ i++, buf++, bios++) {
spi_write_enable();
- spi_byte_program(i, *buf);
+ *bios = *buf;
/* wait program complete. */
if (i % 0x8000 == 0)
printf(".");
@@ -97,12 +98,18 @@
printf("reset\n");
}
-void execute_command(void)
+int execute_command(void)
{
+ int timeout = 1000;
+
sb600_spibar[2] |= 1;
- while (sb600_spibar[2] & 1)
- ;
+ while ((sb600_spibar[2] & 1) && timeout)
+ {
+ myusec_delay(1);
+ timeout --;
+ }
+ return timeout ? 1 : 0;
}
int sb600_spi_command(unsigned int writecnt, unsigned int readcnt,
@@ -150,7 +157,8 @@
*/
reset_internal_fifo_pointer();
- execute_command();
+ if (!execute_command())
+ return 1;
/*
* After the command executed, we should find out the index of
the
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] 690/600 Just starting out.
The dbm690t uses S1G1 socket. The mainboard/amd/xxx/Config.lb should be
modified to AM2.
Zheng
-Original Message-
From: coreboot-boun...@coreboot.org
[mailto:coreboot-boun...@coreboot.org] On Behalf Of Dan Lykowski
Sent: Wednesday, December 31, 2008 10:17 AM
To: coreboot@coreboot.org
Subject: [coreboot] 690/600 Just starting out.
Hi,
I'm just starting to find the time to get involved in coreboot.
My board is an Advantec SOM-5781. It seems pretty close to the reference
design so I thought I would give loading the vanilla dbm690t bios a
shot.
I have a Sempron 2100+ in a AM2 socket. ITE IT8712F SuperIO @ 0x2E.
Has anyone seen this before? It keeps happening over and over. I'll be
looking in to it tonight. My understanding so far is that it is only
supposed to happen once.
Thanks
Dan Lykowski
coreboot-2.0.0 Tue Dec 30 10:32:31 PST 2008 starting...
bsp_apicid=0x0
core0 started:
SBLink=00
NC node|link=00
rs690_early_setup()
get_cpu_rev EAX=0x40fc2.
CPU Rev is K8_Fx.
NB Revision is A12.
k8_optimization()
rs690_por_init
sb600_early_setup()
sb600_devices_por_init()
sb600_devices_por_init(): SMBus Device, BDF:0-20-0
SMBus controller enabled, sb revision is 0x13
sb600_devices_por_init(): IDE Device, BDF:0-20-1
sb600_devices_por_init(): LPC Device, BDF:0-20-3
sb600_devices_por_init(): P2P Bridge, BDF:0-20-4
sb600_devices_por_init(): SATA Device, BDF:0-18-0
sb600_pmio_por_init()
INIT detected from --- { APICID = 00 NODEID = 00 COREID = 00} ---
Issuing SOFT_RESET...
coreboot-2.0.0 Tue Dec 30 10:32:31 PST 2008 starting...
bsp_apicid=0x0
core0 started:
SBLink=00
NC node|link=00
rs690_early_setup()
get_cpu_rev EAX=0x40fc2.
CPU Rev is K8_Fx.
NB Revision is A12.
k8_optimization()
rs690_por_init
sb600_early_setup()
sb600_devices_por_init()
sb600_devices_por_init(): SMBus Device, BDF:0-20-0
SMBus controller enabled, sb revision is 0x13
sb600_devices_por_init(): IDE Device, BDF:0-20-1
sb600_devices_por_init(): LPC Device, BDF:0-20-3
sb600_devices_por_init(): P2P Bridge, BDF:0-20-4
sb600_devices_por_init(): SATA Device, BDF:0-18-0
sb600_pmio_por_init()
INIT detected from --- { APICID = 00 NODEID = 00 COREID = 00} ---
Issuing SOFT_RESET...
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD DBM690T PowerNow table problems
If fid_multiplier is 0, it doesn't seem to have any sense. So I agree.
Acked-by: zheng bao
-Original Message-
From: coreboot-boun...@coreboot.org
[mailto:coreboot-boun...@coreboot.org] On Behalf Of Marc Jones
Sent: Tuesday, January 06, 2009 9:26 AM
To: Rudolf Marek; Bao, Zheng
Cc: Carl-Daniel Hailfinger; Coreboot
Subject: Re: [coreboot] AMD DBM690T PowerNow table problems
On Sat, Jan 3, 2009 at 3:04 PM, Rudolf Marek
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi,
>
> Here we go.
>
> Its seems that the generated table has wrong conversion for frequency
and its
> FID representation. In other words the table is OK but the first field
is not
> consistent with FID and real freq.
>
> invalid freq entries 100 kHz vs. 80
>
> This means that:
>
>
>Package (0x06)
>{
>0x0320,. <--- here should be 0x3e8
>0xF230,.
>0x0064,.
>0x0007,.
>0xE8202F0A,.
>0x030A
>},.
>
>Package (0x06)
>{
>0x0320,.
>0xBB8C,.
>0x0064,.
>0x0007,.
>0xE8202C82,.
>0x0482
>}
>
>
> FID is 0A and 02 which means it should be: set to 0x3e8 and 0x320.
>
> I guess it is because your CPU is revF and not revG.
>
> fid_multiplier = ((cpuid1.edx & 0x40) >> 6) * 100;
>
> This line will cause that your CPU has fid_multiplier 0 instead of
100x.
> I believe that the multiplier should be always 100. Because revF CPU
hav LSB in
> FID always 0.
>
> Rudolf
I agree with this analysis. Patch attached.
Marc
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch] Proposed patch for FIDVID question
It works on dbm690t and pistachio. Please note some indents are spaces instead of tabs. Please correct it. Zheng Acked-by: Zheng Bao From: coreboot-bounces+zheng.bao=amd@coreboot.org [mailto:coreboot-bounces+zheng.bao=amd@coreboot.org] On Behalf Of Dan Lykowski Sent: Friday, January 09, 2009 2:28 AM To: Marc Jones Cc: Coreboot Subject: [coreboot] [patch] Proposed patch for FIDVID question Marc, I have narrowed the reset to the first msr = rdmsr(0xc0010042); line in cache_as_ram.c. I assume the second would do the same thing if it ever made it there. Booting with the orig bios, linux reports ts ttp tm stc 100mhzsteps as the available power options. It is missing fid vid. Based on the lack of cpuinfo bits and the documentation the says the processor will do exactly what it is doing, I propose the included patch. I made the changes to pistachio and norwich also but they are untested. With this patch I make it here: coreboot-2.0.0 Wed Jan 7 17:09:38 PST 2009 starting... bsp_apicid=0x0 Enabling routing table for node 00 done. Enabling UP settings Disabling read/write/fill probes for UP... done. coherent_ht_finalize done core0 started: SBLink=00 NC node|link=00 rs690_early_setup() get_cpu_rev EAX=0x60fc2. CPU Rev is K8_G0. NB Revision is A12. k8_optimization() rs690_por_init sb600_early_setup() sb600_devices_por_init() sb600_devices_por_init(): SMBus Device, BDF:0-20-0 SMBus controller enabled, sb revision is 0x13 sb600_devices_por_init(): IDE Device, BDF:0-20-1 sb600_devices_por_init(): LPC Device, BDF:0-20-3 sb600_devices_por_init(): P2P Bridge, BDF:0-20-4 sb600_devices_por_init(): SATA Device, BDF:0-18-0 sb600_pmio_por_init() Changing FIDVID not supported entering optimize_link_incoherent_ht sysinfo->link_pair_num=0x1 entering ht_optimize_link pos=0x8a, unfiltered freq_cap=0x8035 pos=0x8a, filtered freq_cap=0x35 pos=0xd2, unfiltered freq_cap=0x65 pos=0xd2, filtered freq_cap=0x65 freq_cap1=0x35, freq_cap2=0x65 dev1 old_freq=0x5, freq=0x5, needs_reset=0x0 dev2 old_freq=0x5, freq=0x5, needs_reset=0x0 width_cap1=0x11, width_cap2=0x11 dev1 input ln_width1=0x4, ln_width2=0x4 dev1 input width=0x1 dev1 output ln_width1=0x4, ln_width2=0x4 dev1 input|output width=0x11 old dev1 input|output width=0x11 dev2 input|output width=0x11 old dev2 input|output width=0x11 after ht_optimize_link for link pair 0, reset_needed=0x0 after optimize_link_read_pointers_chain, reset_needed=0x0 rs690_htinit k8_ht_freq=5. rs690_htinit NB_CFG_Q_F1000_800=0 needs_reset=0x0
[coreboot] [flashrom]: AAI program supported?
Hi, all, I am trying to add AAI command support in flashrom. We know that some chips support AAI while others don't. I want to add a member in struct flashchip to indicate whether this chip support AAI. AAI programming improves the speed of writing. Does anyone give some advice? Do you guys think it makes sense? Zheng -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] 4 GB RAM failure on DBM690T target (690G/SB600)
We will try to debug this after the Chinese New Year. Now I am debugging the shiner (RS780/SB700). The board will be returned in a week, so I have to focus on this. Now most of the feature is working, except VGA. Zheng -Original Message- From: Marc Jones [mailto:marcj...@gmail.com] Sent: Wednesday, January 21, 2009 9:58 AM To: Carl-Daniel Hailfinger Cc: Rudolf Marek; Bao, Zheng; Coreboot Subject: Re: [coreboot] 4 GB RAM failure on DBM690T target (690G/SB600) On Tue, Jan 20, 2009 at 6:50 PM, Carl-Daniel Hailfinger wrote: > On 20.01.2009 17:13, Rudolf Marek wrote: >> >>> I'm not totally sure the ACPI code is hard coded to 1 GB. The default >>> values in the ACPI code code correspond to 1 GB and there is some code >>> which will calculate BIOS memory location from TOM and TOM2. I could not >>> find any place where TOM and TOM2 are updated, >> >> its in acpi-k8.c in amd directory. Its in ssdt table. > > Thanks. Unfortunately, the situation is more complicated on DBM690T. > TOM (the top below 4 GB) is stored twice, once in the SSDT (modified > automatically) and once in the DSDT (unmodified). TOM2 is only stored in > the DSDT (unmodified). The (correct) value of TOM in the SSDT is ignored > and the (incorrect) values of TOM/TOM2 in the DSDT are used. > This sounds like a oversite. Maybe the AMD BTDC guys can help. Marc -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] 780/700 Documentation
Hi, All, We have been working on the RS780/SB700 for about 2 weeks. Before we can submit our code, we realized that it doesn't make sense if the documentation is not available. We can get the datasheet as an AMD engineer. How can the developer in Coreboot.org get? Do we need any official procedure to make the document public? Joe -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [patch] flashrom: resending my patch about SPI/LPC conflicts
Signed-off-by: Zheng Bao This patch is about flashrom running on dbm690t. It was sent several months ago and hasn't got any response yet. Now it deals with 3 problems. 1. Fix the bug that the flashrom would hang if there is not SPI chip. A timeout detection was added. 2. We only access LPC ROM if we boot via LPC ROM. And only SPI ROM if we boot via SPI ROM. Doing crossly is not allowed. Anybody has better idea? 3. When we read/write SPI, we use memory read/write instead of sending SPI command. Joe dbm690t_flashrom.patch Description: dbm690t_flashrom.patch -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch] flashrom: resending my patch about SPI/LPCconflicts
Does anybody give some comments? Joe -Original Message- From: coreboot-boun...@coreboot.org [mailto:coreboot-boun...@coreboot.org] On Behalf Of Bao, Zheng Sent: Monday, February 02, 2009 12:12 PM To: Coreboot Subject: [coreboot] [patch] flashrom: resending my patch about SPI/LPCconflicts Signed-off-by: Zheng Bao This patch is about flashrom running on dbm690t. It was sent several months ago and hasn't got any response yet. Now it deals with 3 problems. 1. Fix the bug that the flashrom would hang if there is not SPI chip. A timeout detection was added. 2. We only access LPC ROM if we boot via LPC ROM. And only SPI ROM if we boot via SPI ROM. Doing crossly is not allowed. Anybody has better idea? 3. When we read/write SPI, we use memory read/write instead of sending SPI command. Joe -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] What port needs to be open on the Firewall besides coreboot.org:29418
Hi, All, We are building a build machine, which is connect the AMD network with a firewall. We need to provide the IP address and port(29418) of coreboot.org to access the git server. It doesn't work yet. I am wondering if the OpenID needs extra website address and port to check the authorization. Does anybody know that? Thanks Zheng -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Can I change my Username of git
Hi, I tried to change my username for accessing the repository. In http://review.coreboot.org/#settings the username, which is bound to my OpenID and was accidentally set as a silly name, is unchangeable. Any chance that I can change it? Zheng -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Does the fam10 code work now? Patches for discuss.
About the MCT, the memory seems to work. But it takes coreboot nearly one minute to "Uncompressing image to RAM.". I suddenly found words above. "*** Yes, the copy/decompress is taking a while, FIXME!" It is printed in serengeti_cheetah_fam10/cache_as_ram_auto.c Does it mean it is not just my problem? Do you know about it? Zheng -Original Message- From: Marc Jones [mailto:marcj...@gmail.com] Sent: Friday, June 26, 2009 5:52 AM To: Bao, Zheng Cc: coreboot@coreboot.org Subject: Re: Does the fam10 code work now? Patches for discuss. On Thu, Jun 25, 2009 at 2:46 AM, Bao, Zheng wrote: > amd_fam10_ht_sb_only.diff: > I am not sure about this patch. Not sure to add signed-off-by line. > Don't ack it before review it and say something. > > My board is Fam10 + 1 HT SouthBridge. It is close to dbm690t. So I > set HT_CHAIN_UNITID_BASE as 0 and HT_CHAIN_END_UNITID_BASE as 1, even > though I don't know well what they actually are. Base on currently fam10 > code, I have skip some code, otherwise the HT link can not be set up > correctly. It is pretty like a workaround and my board can work in > 1.8GHz (HT3). Doesn't the code in repository cover the mode of > one HT processor + 1 HT SB device? > I assume that you are getting a failure since you skipped a section and commented out a halt on error. What do you get for AMD_CB_EventNotify? You can get more information about bus numbering in the HTIOlink spec and the device spec should have any requirements for bus numbering. http://www.hypertransport.org/docs/tech/HTC20051222-0046-0008-Final-4-21 -06.pdf But, I assume that the device will work like the 690, so the setting should be ok but compare with the vendor bios. > ** > amd_fam10_mct_am2_rough.diff: > The original code was pretty weird. It definitely can not > be build correctly. This patch is only about building error. > > The mctardk4 seems to be for AM2. Based on the code and this > patch, the memory seems to work but is unstable and unbearably > slow. I need to dig it more. > > Since I am confused about this, it is not a signed-off-by patch. AM2 was never built, just ported for reference. There wasn't a product at the time. I dontt know if the Bx table will work for Cx. You will need to work with Tim and the BIOS group to get the settings. You might need to add a fam10 version of the socket similar to the socket f in /src/cpu/amd. Marc -- http://marcjonesconsulting.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Does the fam10 code work now? Patches for discuss.
Can you tell me which is the patch or send it to me? If I set CONFIG_COMPRESS to 1, the copy is fast. But if the code jumps to RAM, the system will reboot. Is it also caused by same reason? Why doesn't dbm690t have that problem? Zheng -Original Message- From: Marc Jones [mailto:marcj...@gmail.com] Sent: Friday, June 26, 2009 10:59 PM To: Bao, Zheng Cc: coreboot@coreboot.org Subject: Re: [coreboot] Does the fam10 code work now? Patches for discuss. On Thu, Jun 25, 2009 at 9:01 PM, Bao, Zheng wrote: > About the MCT, the memory seems to work. But it takes coreboot nearly > one minute to "Uncompressing image to RAM.". I suddenly found words > above. > "*** Yes, the copy/decompress is taking a while, FIXME!" > It is printed in serengeti_cheetah_fam10/cache_as_ram_auto.c > Does it mean it is not just my problem? Do you know about it? Zheng, Yes, that is not just your problem. There is a problem with XIP and the decompression code that needs to be fixed. There was a patch posted a while ago that hasn't been merged. I will try to look at it next week. Marc -- http://marcjonesconsulting.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Does the fam10 code work now? Patches for discuss.
The reset is caused by the fact that the memcpy doesn't work. The patch works, while the way you told me doesn't. Maybe XIP_ROM_BASE is the reason. Zheng -Original Message- From: Marc Jones [mailto:marcj...@gmail.com] Sent: Tuesday, June 30, 2009 2:34 AM To: Bao, Zheng Cc: coreboot@coreboot.org Subject: Re: [coreboot] Does the fam10 code work now? Patches for discuss. On Sun, Jun 28, 2009 at 8:52 PM, Bao, Zheng wrote: > Can you tell me which is the patch or send it to me? > > If I set CONFIG_COMPRESS to 1, the copy is fast. But if the code jumps > to RAM, the system will reboot. Is it also caused by same reason? Why > doesn't dbm690t have that problem? I don't know about the reset. i think that the K8 does have the same issue but the amount of code copied is much less. The fam10 code is much larger. The thread you want to look at is this one: http://www.coreboot.org/pipermail/coreboot/2008-October/040885.html I think that a better solution is to fix up the disable car and copy code to cache the rom. For example adding set_var_mtrr(1, XIP_ROM_BASE, XIP_ROM_SIZE, MTRR_TYPE_WRBACK); to set_init_ram_access() would address the issue. Maybe you can try that. Marc -- http://marcjonesconsulting.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH]:AMD family 10 AM2r2 support
Add AMD family 10 AM2r2 support.
Coreboot used to take SYSTEM_TYPE as a label to tell what the socket is.
The patch replaces (some of, not all) SYSTEM_TYPE with CPU_SOCKET_TYPE.
Signed-off-by: Zheng Bao
Index: src/cpu/amd/socket_AM2r2/Config.lb
===
--- src/cpu/amd/socket_AM2r2/Config.lb (revision 0)
+++ src/cpu/amd/socket_AM2r2/Config.lb (revision 0)
@@ -0,0 +1,54 @@
+#
+# This file is part of the coreboot project.
+#
+# Copyright (C) 2007 Advanced Micro Devices, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; version 2 of the License.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301
USA
+#
+
+uses PCI_IO_CFG_EXT
+uses MMCONF_SUPPORT
+uses HT3_SUPPORT
+uses EXT_RT_TBL_SUPPORT
+uses EXT_CONF_SUPPORT
+uses DIMM_SUPPORT
+uses CPU_SOCKET_TYPE
+uses CBB
+uses CDB
+uses PCI_BUS_SEGN_BITS
+uses CAR_FAM10
+
+config chip.h
+
+default PCI_IO_CFG_EXT=1
+
+default HT3_SUPPORT=1
+default EXT_RT_TBL_SUPPORT=0
+default EXT_CONF_SUPPORT=0
+default DIMM_SUPPORT=0x0104 #DDR2 and REG
+default CPU_SOCKET_TYPE=0x11
+
+default CAR_FAM10=1
+
+if EXT_RT_TBL_SUPPORT
+ default CBB=0xff
+ default CDB=0
+end
+
+#default MMCONF_SUPPORT=1
+#default MMCONF_SUPPORT_DEFAULT=1
+
+object socket_AM2r2.o
+
+dir /cpu/amd/model_10xxx
Index: src/cpu/amd/socket_AM2r2/chip.h
===
--- src/cpu/amd/socket_AM2r2/chip.h (revision 0)
+++ src/cpu/amd/socket_AM2r2/chip.h (revision 0)
@@ -0,0 +1,23 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2007 Advanced Micro Devices, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
02110-1301 USA
+ */
+
+extern struct chip_operations cpu_amd_socket_AM2r2_ops;
+
+struct cpu_amd_socket_AM2r2_config {
+};
Index: src/cpu/amd/socket_AM2r2/socket_AM2r2.c
===
--- src/cpu/amd/socket_AM2r2/socket_AM2r2.c (revision 0)
+++ src/cpu/amd/socket_AM2r2/socket_AM2r2.c (revision 0)
@@ -0,0 +1,25 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2007 Advanced Micro Devices, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
02110-1301 USA
+ */
+
+#include
+#include "chip.h"
+
+struct chip_operations cpu_amd_socket_AM2r2_ops = {
+ CHIP_NAME("socket AM2r2")
+};
Index: src/northbridge/amd/amdmct/mct/mctardk4.c
===
--- src/northbridge/amd/amdmct/mct/mctardk4.c (revision 4379)
+++ src/northbridge/amd/amdmct/mct/mctardk4.c (working copy)
@@ -25,7 +25,7 @@
void mctGet_PS_Cfg_D(struct MCTStatStruc *pMCTstat,
struct DCTStatStruc *pDCTstat, u32 dct)
-
+{
print_tx("dct: ", dct);
print_tx("Speed: ", pDCTstat->Speed);
@@ -66,42 +66,43 @@
*/
static const u8 Table_ATC_ODC_D_Bx[] = {
- 1, 0xFF, 0x00, 0x2F, 0x2F, 0x0, 0x22, 0x13, 0x11, 0x0
- 2, 12, 0x00, 0x2F, 0x2F, 0x0, 0x22, 0x13, 0x11, 0x0
- 2, 16, 0x00, 0x2F, 0x00, 0x0, 0x22, 0x13, 0x11, 0x0
- 2, 20, 0x00, 0x2F, 0x38, 0x0, 0x22, 0x13, 0x11, 0x0
- 2, 24, 0x00, 0x2F, 0x37, 0x0, 0x22, 0x13, 0x11, 0x0
- 2, 32,
Re: [coreboot] [PATCH]:AMD family 10 AM2r2 support
"CONFIG_" is added. Committed, r4385. -Original Message- From: Marc Jones [mailto:marcj...@gmail.com] Sent: Tuesday, June 30, 2009 11:23 PM To: Bao, Zheng Cc: coreboot@coreboot.org Subject: Re: [coreboot] [PATCH]:AMD family 10 AM2r2 support On Mon, Jun 29, 2009 at 11:46 PM, Bao, Zheng wrote: > Add AMD family 10 AM2r2 support. > Coreboot used to take SYSTEM_TYPE as a label to tell what the socket is. > The patch replaces (some of, not all) SYSTEM_TYPE with CPU_SOCKET_TYPE. > > Signed-off-by: Zheng Bao T > +default CPU_SOCKET_TYPE=0x11 Please add an equate for the socket names. Acked-by: Marc Jones -- http://marcjonesconsulting.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] v3 Resource allocator to v2
In SB600, the IOAPIC is allocated in sb600_sm.c. Is there any conflict with sb600_lpc.c? Zheng From: coreboot-boun...@coreboot.org [mailto:coreboot-boun...@coreboot.org] On Behalf Of Myles Watson Sent: Friday, July 03, 2009 2:59 AM To: ron minnich Cc: coreboot@coreboot.org Subject: Re: [coreboot] [PATCH] v3 Resource allocator to v2 On Wed, May 27, 2009 at 7:01 PM, ron minnich wrote: Acked-by: Ronald G. Minnich Rev 4394. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] fam10 resource can not allocated.
The patch has been tested and passed on fam10 board. I added an acked-by line to it, but I didn't review it. I didn't trace what happened in these patches and don't know what they mean. I just tested it. If it is appropriate, Acked-by: Zheng Bao Zheng -Original Message- From: Myles Watson [mailto:myle...@gmail.com] Sent: Tuesday, July 07, 2009 12:44 PM To: Bao, Zheng Cc: coreboot@coreboot.org Subject: RE: [coreboot] fam10 resource can not allocated. > I tested this patch. The resource can be allocated. But the kernel can not > go. After the "Jumping to entry point...", nothing comes out. I don't know > the cause. Do you know? I guess fam10 code allocates a separate register for prefetchable memory. K8 doesn't. Since I didn't add IORESOURCE_BRIDGE to the prefetchable resource, anything prefetchable didn't get allocated (look for ERROR: ... not assigned messages) Here's an updated patch. Thanks for testing. Signed-off-by: Myles Watson The last piece of the patch isn't necessary, but it would be nice to unify the K8 and fam10 code more than they are. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD SB700/SB710/SB750 docs have been released!
My boss is getting confirm from official channel. I will submit it as soon as I get the permission. Zheng -Original Message- From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2...@gmx.net] Sent: Thursday, July 09, 2009 10:00 AM To: Coreboot Cc: Bao, Zheng; Wang, Qingpei Subject: AMD SB700/SB710/SB750 docs have been released! AMD just released the following docs we need for SB700/SB710/SB750 coreboot support: * AMD SB700/710/750 Register Reference Guide * AMD SB700/710/750 BIOS Developer's Guide * AMD SB700/710/750 Register Programming Requirements * AMD SB710 Databook Links to all data sheets are at http://www.coreboot.org/Datasheets#AMD_SB700.2FSB710.2FSB750 This is a great step towards supporting current RS780/SB700 family systems. Immediate benefits of this doc release are: - We can implement SB700/SB710/SB750 support without NDA. - We can study the embedded controller environment and the SuperI/O functionality in some SB7x0 southbridges. Future benefits are: - We can support 690/SB700 boards once the SB700 code is done. - We can test SB700 code in 690/SB700 boards and make sure it works perfectly before we start working on RS780 code. - We have 50% of the docs we need for almost all boards with AMD chipset on sale today. What can we do next? - Implement SB700 code. - RS690/SB700 boards do not exist. However, it seems that RS740 is RS690 with a modified graphics core, so RS740/SB700 boards are the best targets we can pick. List of possible targets with RS740/SB700: - ECS Elitegroup A740GM-M (89-206-V15102) http://www.ecs.com.tw/ECSWebSite/Products/ProductsDetail.aspx?detailid=8 64&CategoryID=1&DetailName=Specification&MenuID=1&LanID=0 - Gigabyte GA-MA74GM-S2 (rev 1.x and 2.0) http://www.gigabyte.com.tw/Products/Motherboard/Products_Overview.aspx?P roductID=3063 http://www.gigabyte.com.tw/Products/Motherboard/Products_Overview.aspx?P roductID=2813 - Gigabyte GA-MA74GM-S2 (rev 1.x and 2.0) http://www.gigabyte.com.tw/Products/Motherboard/Products_Overview.aspx?P roductID=2775 http://www.gigabyte.com.tw/Products/Motherboard/Products_Overview.aspx?P roductID=3062 - ASUS M2A74-AM http://www.asus.com/product.aspx?P_ID=YPZrr3KRcW3MBX5G - MSI K9A2GM-F V3 (MS-7302-020, there seem to be many variants of this board, some of them may have a 740 variant which is not compatible with 690) http://us.msi.com/product/p_spec.asp?model=K9A2GM-F_V3&class=mb Thanks to AMD for releasing these docs! Regards, Carl-Daniel -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [patch]:new dual core check function is sb600.
This seems to be a more official, common, simple way to check if the CPU
is dual core or
single core.
Signed-off-by: Zheng Bao
Index: src/southbridge/amd/sb600/sb600_early_setup.c
===
--- src/southbridge/amd/sb600/sb600_early_setup.c (revision 4413)
+++ src/southbridge/amd/sb600/sb600_early_setup.c (working copy)
@@ -125,11 +125,7 @@
static u8 dual_core()
{
- if(((cpuid_eax(0x8000) & ~0xff) >= 8)) {
- if(cpuid_ecx(0x8008) & 1)
- return 1;
- }
- return 0;
+ return (pci_read_config32(PCI_DEV(0, 0x18, 3), 0xE8) &
(0x3<<12)) != 0;
}
/*
check_dual_core_in_sb600.patch
Description: check_dual_core_in_sb600.patch
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch]:new dual core check function in sb600.
The title should be "in sb600" instead of "is sb600".
-Original Message-
From: coreboot-boun...@coreboot.org
[mailto:coreboot-boun...@coreboot.org] On Behalf Of Bao, Zheng
Sent: Friday, July 10, 2009 11:01 AM
To: Coreboot
Subject: [coreboot] [patch]:new dual core check function is sb600.
This seems to be a more official, common, simple way to check if the CPU
is dual core or
single core.
Signed-off-by: Zheng Bao
Index: src/southbridge/amd/sb600/sb600_early_setup.c
===
--- src/southbridge/amd/sb600/sb600_early_setup.c (revision 4413)
+++ src/southbridge/amd/sb600/sb600_early_setup.c (working copy)
@@ -125,11 +125,7 @@
static u8 dual_core()
{
- if(((cpuid_eax(0x8000) & ~0xff) >= 8)) {
- if(cpuid_ecx(0x8008) & 1)
- return 1;
- }
- return 0;
+ return (pci_read_config32(PCI_DEV(0, 0x18, 3), 0xE8) &
(0x3<<12)) != 0;
}
/*
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD SB700/SB710/SB750 docs have been released!
I was told the RS780 doc will also be released "by the end of next week". I will commit my code when 780 doc is ready. Then I don't have to make up a fake board. Zheng -Original Message- From: coreboot-bounces+zheng.bao=amd@coreboot.org [mailto:coreboot-bounces+zheng.bao=amd@coreboot.org] On Behalf Of Bao, Zheng Sent: Friday, July 10, 2009 10:42 AM To: Carl-Daniel Hailfinger; Coreboot Subject: Re: [coreboot] AMD SB700/SB710/SB750 docs have been released! My boss is getting confirm from official channel. I will submit it as soon as I get the permission. Zheng -Original Message- From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2...@gmx.net] Sent: Thursday, July 09, 2009 10:00 AM To: Coreboot Cc: Bao, Zheng; Wang, Qingpei Subject: AMD SB700/SB710/SB750 docs have been released! AMD just released the following docs we need for SB700/SB710/SB750 coreboot support: * AMD SB700/710/750 Register Reference Guide * AMD SB700/710/750 BIOS Developer's Guide * AMD SB700/710/750 Register Programming Requirements * AMD SB710 Databook Links to all data sheets are at http://www.coreboot.org/Datasheets#AMD_SB700.2FSB710.2FSB750 This is a great step towards supporting current RS780/SB700 family systems. Immediate benefits of this doc release are: - We can implement SB700/SB710/SB750 support without NDA. - We can study the embedded controller environment and the SuperI/O functionality in some SB7x0 southbridges. Future benefits are: - We can support 690/SB700 boards once the SB700 code is done. - We can test SB700 code in 690/SB700 boards and make sure it works perfectly before we start working on RS780 code. - We have 50% of the docs we need for almost all boards with AMD chipset on sale today. What can we do next? - Implement SB700 code. - RS690/SB700 boards do not exist. However, it seems that RS740 is RS690 with a modified graphics core, so RS740/SB700 boards are the best targets we can pick. List of possible targets with RS740/SB700: - ECS Elitegroup A740GM-M (89-206-V15102) http://www.ecs.com.tw/ECSWebSite/Products/ProductsDetail.aspx?detailid=8 64&CategoryID=1&DetailName=Specification&MenuID=1&LanID=0 - Gigabyte GA-MA74GM-S2 (rev 1.x and 2.0) http://www.gigabyte.com.tw/Products/Motherboard/Products_Overview.aspx?P roductID=3063 http://www.gigabyte.com.tw/Products/Motherboard/Products_Overview.aspx?P roductID=2813 - Gigabyte GA-MA74GM-S2 (rev 1.x and 2.0) http://www.gigabyte.com.tw/Products/Motherboard/Products_Overview.aspx?P roductID=2775 http://www.gigabyte.com.tw/Products/Motherboard/Products_Overview.aspx?P roductID=3062 - ASUS M2A74-AM http://www.asus.com/product.aspx?P_ID=YPZrr3KRcW3MBX5G - MSI K9A2GM-F V3 (MS-7302-020, there seem to be many variants of this board, some of them may have a 740 variant which is not compatible with 690) http://us.msi.com/product/p_spec.asp?model=K9A2GM-F_V3&class=mb Thanks to AMD for releasing these docs! Regards, Carl-Daniel -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] What is the way to add a VGA ROM space in target\xx\xx\Config.lb
In a Config.lb like this (in coreboot-v2/targets/amd/serengeti_cheetah_fam10/Config.lb): ## ## This file is part of the coreboot project. ## ## Copyright (C) 2007 Advanced Micro Devices, Inc. ## ## This program is free software; you can redistribute it and/or modify ## it under the terms of the GNU General Public License as published by ## the Free Software Foundation; either version 2 of the License, or ## (at your option) any later version. ## ## This program is distributed in the hope that it will be useful, ## but WITHOUT ANY WARRANTY; without even the implied warranty of ## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ## GNU General Public License for more details. ## ## You should have received a copy of the GNU General Public License ## along with this program; if not, write to the Free Software ## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA ## # Sample config file for # the amd cheetah_fam10 # This will make a target directory of ./serengeti_cheetah_fam10 target serengeti_cheetah_fam10 mainboard amd/serengeti_cheetah_fam10 # Request this level of debugging output option CONFIG_DEFAULT_CONSOLE_LOGLEVEL=9 # At a maximum only compile in this level of debugging option CONFIG_MAXIMUM_CONSOLE_LOGLEVEL=9 # 512KB ROM option CONFIG_ROM_SIZE=1024*1024 # Cheetah Family 10 #romimage "normal" # 1MB ROM # option CONFIG_ROM_SIZE = 0x10 # option CONFIG_USE_FAILOVER_IMAGE=0 # option CONFIG_USE_FALLBACK_IMAGE=0 # option CONFIG_ROM_IMAGE_SIZE=0x2 # option CONFIG_ROM_IMAGE_SIZE=0x3 # option CONFIG_XIP_ROM_SIZE=0x4 # option COREBOOT_EXTRA_VERSION="$(shell cat ../../VERSION)_Normal" # payload ../payload.elf #end romimage "fallback" option CONFIG_USE_FAILOVER_IMAGE=0 option CONFIG_USE_FALLBACK_IMAGE=1 # option CONFIG_ROM_IMAGE_SIZE=0x13800 # option CONFIG_ROM_IMAGE_SIZE=0x19800 option CONFIG_ROM_IMAGE_SIZE=0x7f000 # option CONFIG_ROM_IMAGE_SIZE=0x15800 option CONFIG_XIP_ROM_SIZE=0x8 option COREBOOT_EXTRA_VERSION="$(shell cat ../../VERSION)_Fallback" payload ../payload.elf end romimage "failover" option CONFIG_USE_FAILOVER_IMAGE=1 option CONFIG_USE_FALLBACK_IMAGE=0 option CONFIG_ROM_IMAGE_SIZE=CONFIG_FAILOVER_SIZE option CONFIG_XIP_ROM_SIZE=CONFIG_FAILOVER_SIZE option COREBOOT_EXTRA_VERSION="$(shell cat ../../VERSION)_Failover" end #buildrom ./coreboot.rom CONFIG_ROM_SIZE "normal" "fallback" "failover" buildrom ./coreboot.rom CONFIG_ROM_SIZE "fallback" "failover" end We want to get a space about 50K for VGA ROM like dbm690t does. I tried CONFIG_ROM_SIZE, CONFIG_ROM_IMAGE_SIZE, but they both don't work. What can we do? Zheng -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] What is the way to add a VGA ROM space intarget\xx\xx\Config.lb
I have tried the CONFIG_ROM_SIZE, but it doesn't work. I worked in serengeti_cheetah_fam10. I put "-60416" after CONFIG_ROM_SIZE=1024*1024. But the building fails. Please see the build.log I attached. Thanks. Zheng -Original Message- From: Ward Vandewege [mailto:w...@gnu.org] Sent: Wednesday, July 15, 2009 8:51 PM To: Bao, Zheng Cc: Coreboot; Carl-Daniel Hailfinger Subject: Re: [coreboot] What is the way to add a VGA ROM space intarget\xx\xx\Config.lb Hi Zheng, On Wed, Jul 15, 2009 at 05:55:12PM +0800, Bao, Zheng wrote: > We want to get a space about 50K for VGA ROM like dbm690t does. I tried > CONFIG_ROM_SIZE, CONFIG_ROM_IMAGE_SIZE, but they both don't work. What > can we do? Look at the example in pcengines/alix.1c: ## CONFIG_ROM_SIZE is the total number of bytes allocated for coreboot use ## (normal AND fallback images and payloads). Leave 36k for VSA. option CONFIG_ROM_SIZE = (512 * 1024) - (36 * 1024) So, CONFIG_ROM_SIZE is the place to do that. Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior Systems Administrator Config.lb Description: Config.lb build.log Description: build.log -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] What is the way to add a VGA ROM spaceintarget\xx\xx\Config.lb
Only if I tried 64*1024, the building will be no error. But the coreboot.rom is still 1MB exactly. Zheng -Original Message- From: Myles Watson [mailto:myle...@gmail.com] Sent: Thursday, July 16, 2009 10:29 AM To: Bao, Zheng; 'Coreboot' Subject: RE: [coreboot] What is the way to add a VGA ROM spaceintarget\xx\xx\Config.lb > I have tried the CONFIG_ROM_SIZE, but it doesn't work. I worked in > serengeti_cheetah_fam10. I put "-60416" after CONFIG_ROM_SIZE=1024*1024. > But the building fails. Please see the build.log I attached. Have you tried a multiple of 1024? Maybe something like 964*1024 if you want 60K. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] What is the way to add a VGA ROM spaceintarget\xx\xx\Config.lb
In my case, it should be CONFIG_FALLBACK_SIZE = CONFIG_ROM_SIZE-CONFIG_FAILOVER_SIZE It works now. Thanks. Zheng From: Myles Watson [mailto:myle...@gmail.com] Sent: Thursday, July 16, 2009 11:46 AM To: Bao, Zheng; Coreboot Subject: Re: [coreboot] What is the way to add a VGA ROM spaceintarget\xx\xx\Config.lb On Wed, Jul 15, 2009 at 9:37 PM, Myles Watson wrote: > Only if I tried 64*1024, the building will be no error. But the > coreboot.rom is still 1MB exactly. I tried it with your Config.lb, except: option CONFIG_ROM_SIZE = 960*1024 This builds a 968K image, so you'll probably have to pad your ROM. Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch] [AMD Fam10] Fix confused RB-C2 and DA-C2
RB-C2 probably uses socket type AM3, which is not supported in Coreboot currently. I wonder if your board can go through the whole image. You can contact tim.per...@amd.com about the patch releasing. Zheng -Original Message- From: Ward Vandewege [mailto:w...@gnu.org] Sent: Thursday, July 16, 2009 10:37 PM To: Bao, Zheng Cc: Coreboot Subject: Re: [coreboot] [patch] [AMD Fam10] Fix confused RB-C2 and DA-C2 Hi Zheng, On Thu, Jul 16, 2009 at 03:40:49PM +0800, Bao, Zheng wrote: > This patch is about the DA-C2 and RB-C2. Chip with install processor > Revision ID of 0x100F62 is DA-C2, instead of RB-C2 which was incorrectly > defined in raminit_amdmct.c. RB-C2's ID is 0x100F42. The Erratas applied > to them are almost the same. Aha. That would perhaps explain why my box with Quad-Core AMD Opteron(tm) Processor 2372 HE with revision id 0x100f42 really does not like ucode revision 92 (it resets itself constantly). > Issues: > 1. I really dont know what their nicknames are (Shanghai C2 or > something). Don't know about that. > 2. About the mc_patch_0186.h, I dont know if it is allowed to be > released. >If you really need it, please contact AMD Inc to see if it is public. Well, I have my box booting without any ucode update. It would be nice to have mc_patch_0186.h public if that's the revision for my cpus. Who do I ask? > 3. I haven't made coreboot go thoroughly on this RB-C2. This patch is > just half tested. I now have a working tree for Supermicro h8dmr with RB-C2 but it needs a bit more tweaking and cleaning up. I hope to get that ready soon so I can submit the patch to the list. >I am not confident it is 100% correct. I'll test tonight or tomorrow and let you know how it goes. Thanks! Ward. -- Ward Vandewege -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [patch] A bug in AMD fam10 am2r2 module
This is an obvious bug which I overlooked when I worked on the AM2r2
modules.
Zheng
Signed-off-by: Zheng Bao
Index: src/northbridge/amd/amdmct/mct/mctardk4.c
===
--- src/northbridge/amd/amdmct/mct/mctardk4.c (revision 4427)
+++ src/northbridge/amd/amdmct/mct/mctardk4.c (working copy)
@@ -121,7 +121,7 @@
*AddrTmgCTL = 0x002F2F00;
else if (Speed == 4)
*AddrTmgCTL = 0x00202520;
- else if (Speed == 4)
+ else if (Speed == 5)
*AddrTmgCTL = 0x002F2020;
else
*AddrTmgCTL = 0x002F2F2F;
@@ -130,7 +130,7 @@
*CMDmode = 2;
*AddrTmgCTL = 0x00202520;
*ODC_CTL = 0x00113222;
- } else if(Speed == 4) {
+ } else if(Speed == 5) {
*CMDmode = 2;
*AddrTmgCTL = 0x002F2020;
*ODC_CTL = 0x00113222;
AMD_fam10_AM2r2_fix_bug.patch
Description: AMD_fam10_AM2r2_fix_bug.patch
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch] A bug in AMD fam10 am2r2 module
Committed, r4430. Zheng -Original Message- From: ron minnich [mailto:rminn...@gmail.com] Sent: Friday, July 17, 2009 1:33 PM To: Bao, Zheng Cc: Coreboot Subject: Re: [coreboot] [patch] A bug in AMD fam10 am2r2 module Acked-by: Ronald G. Minnich -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch] [AMD Fam10] Fix confused RB-C2 and DA-C2
Hi, Christian, In Fam10 BKDG, it says CPUID Fn8000_0001_EBX BrandId Identifier Bits Description 31:28 PkgType: package type. Specifies the processor package type. This field is encoded as follows: b: Fr2(1207), Fr5(1207), or Fr6(1207). 0001b: AM2r2 or AM3. 0010b: S1g3 or S1g4. 0011b: G34. 0100b: ASB2. 0101b: C32. The CPUID Fn8000_0001_EBX of the CPU I am using is 0x10002056, whose bit 31:28 is 1, right? Zheng -Original Message- From: Christian Leber [mailto:christian.le...@ziti.uni-heidelberg.de] Sent: Friday, July 17, 2009 5:24 PM To: coreboot@coreboot.org Cc: Bao, Zheng Subject: Re: [coreboot] [patch] [AMD Fam10] Fix confused RB-C2 and DA-C2 On Friday 17 July 2009 04:01:35 Bao, Zheng wrote: Hi Zheng > RB-C2 probably uses socket type AM3, which is not supported in Coreboot > currently. I wonder if your board can go through the whole image. The RB-C2 / 0x100f42 is socket F. Christian -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch] [AMD Fam10] Fix confused RB-C2 and DA-C2
According to the Revision Guide, I think there might be several kinds of 0x100F42 RB-C2. They are AM2r2, AM3, F1207. The actual socket type should be read from CPUID_8001_EBX. Right? Zheng -Original Message- From: Ward Vandewege [mailto:w...@gnu.org] Sent: Friday, July 17, 2009 11:42 PM To: Bao, Zheng Cc: Coreboot Subject: Re: [coreboot] [patch] [AMD Fam10] Fix confused RB-C2 and DA-C2 On Fri, Jul 17, 2009 at 10:01:35AM +0800, Bao, Zheng wrote: > RB-C2 probably uses socket type AM3, which is not supported in Coreboot > currently. I wonder if your board can go through the whole image. Hmm, I think there is some confusion here. If RB-C2 is really 0x100F42, then we are most certainly talking about Socket F. I have a few Opteron 2372 HE CPUs that are 0x100F42. > You can contact tim.per...@amd.com about the patch releasing. Thank you, I have done so. Thanks, Ward. -- Ward Vandewege -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch] [AMD Fam10] Fix confused RB-C2 and DA-C2
If anyone can tell me what the nicknames of AMD_RB_C2 & AMD_DA_C2 are, I will submit the code. Zheng -Original Message- From: Ward Vandewege [mailto:w...@gnu.org] Sent: Tuesday, July 21, 2009 3:58 AM To: Bao, Zheng Cc: Coreboot Subject: Re: [coreboot] [patch] [AMD Fam10] Fix confused RB-C2 and DA-C2 On Thu, Jul 16, 2009 at 03:40:49PM +0800, Bao, Zheng wrote: > This patch is about the DA-C2 and RB-C2. Chip with install processor > Revision ID of 0x100F62 is DA-C2, instead of RB-C2 which was incorrectly > defined in raminit_amdmct.c. RB-C2's ID is 0x100F42. The Erratas applied > to > them are almost the same. > > Issues: > 1. I really dont know what their nicknames are (Shanghai C2 or > something). > 2. About the mc_patch_0186.h, I dont know if it is allowed to be > released. >If you really need it, please contact AMD Inc to see if it is public. > 3. I haven't made coreboot go thoroughly on this RB-C2. This patch is > just half tested. >I am not confident it is 100% correct. > > Zheng > > > Signed-off-by: Zheng Bao With this patch, I can still boot my system with 00100F42h (RB-C2) CPUs - Opteron 2372HE. Acked-by: Ward Vandewege Thanks, Ward. -- Ward Vandewege -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch] [AMD Fam10] Fix confused RB-C2 and DA-C2
I am trying to port the ddr3 feature. I will submit a full patch to replace this one. Zheng -Original Message- From: Ward Vandewege [mailto:w...@gnu.org] Sent: Tuesday, July 21, 2009 3:58 AM To: Bao, Zheng Cc: Coreboot Subject: Re: [coreboot] [patch] [AMD Fam10] Fix confused RB-C2 and DA-C2 On Thu, Jul 16, 2009 at 03:40:49PM +0800, Bao, Zheng wrote: > This patch is about the DA-C2 and RB-C2. Chip with install processor > Revision ID of 0x100F62 is DA-C2, instead of RB-C2 which was incorrectly > defined in raminit_amdmct.c. RB-C2's ID is 0x100F42. The Erratas applied > to > them are almost the same. > > Issues: > 1. I really dont know what their nicknames are (Shanghai C2 or > something). > 2. About the mc_patch_0186.h, I dont know if it is allowed to be > released. >If you really need it, please contact AMD Inc to see if it is public. > 3. I haven't made coreboot go thoroughly on this RB-C2. This patch is > just half tested. >I am not confident it is 100% correct. > > Zheng > > > Signed-off-by: Zheng Bao With this patch, I can still boot my system with 00100F42h (RB-C2) CPUs - Opteron 2372HE. Acked-by: Ward Vandewege Thanks, Ward. -- Ward Vandewege -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [patch] Fix CONFIG_GFXUMA in mtrr.c
The code between #if and #endif is only about UMA mode. The
CONFIG_GFXUMA should be 1.
We have another mode called side port mode. It is When the CONFIG_GFXUMA
is 0.
Signed-off-by: Zheng Bao
Index: src/cpu/x86/mtrr/mtrr.c
===
--- src/cpu/x86/mtrr/mtrr.c (revision 4505)
+++ src/cpu/x86/mtrr/mtrr.c (working copy)
@@ -418,7 +418,7 @@
search_global_resources(
IORESOURCE_MEM | IORESOURCE_CACHEABLE, IORESOURCE_MEM |
IORESOURCE_CACHEABLE,
set_var_mtrr_resource, &var_state);
-#ifdef CONFIG_GFXUMA
+#if (CONFIG_GFXUMA == 1) /* UMA or SP. */
// For now we assume the UMA space is at the end of memory
if (var_state.hole_startk || var_state.hole_sizek) {
printk_debug("Warning: Can't set up MTRR hole for UMA
due to pre-existing MTRR hole.\n");
fix_config_gfxuma.patch
Description: fix_config_gfxuma.patch
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch] Fix CONFIG_GFXUMA in mtrr.c
Thanks, Committed to r4525. -Original Message- From: Myles Watson [mailto:myle...@gmail.com] Sent: Monday, August 10, 2009 11:33 PM To: Bao, Zheng; 'Coreboot' Subject: RE: [coreboot] [patch] Fix CONFIG_GFXUMA in mtrr.c > The code between #if and #endif is only about UMA mode. The > CONFIG_GFXUMA should be 1. > We have another mode called side port mode. It is When the CONFIG_GFXUMA > is 0. > > Signed-off-by: Zheng Bao Acked-by: Myles Watson Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] why did set smaller ROM size for dbm690t and pistachioboard.
You need > cat vga_bios.rom coreboot.rom > coreboot-final.rom To get a 1MB image with VGA BIOS. Zheng -Original Message- From: coreboot-boun...@coreboot.org [mailto:coreboot-boun...@coreboot.org] On Behalf Of jaa...@gmail.com Sent: Thursday, August 13, 2009 12:34 PM To: coreboot@coreboot.org Subject: [coreboot] why did set smaller ROM size for dbm690t and pistachioboard. In Config.lb at those two boards, it has this line. option CONFIG_ROM_SIZE = 1024*1024 - 55808 But Config-abuild.lb is not. Final ROM size 992768 bytes by this setting. I need to set like this to boot properly? -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH]:The Errata350 is fixed as the way it should be
The Errata350 is "Write _8000h to register F2x[1, 0]9C_xD080F0C.",
instead of
F2x[1, 0]9C_x0C. It is a obvious bug. Some typos are also fixed.
Index: src/northbridge/amd/amdmct/wrappers/mcti_d.c
===
--- src/northbridge/amd/amdmct/wrappers/mcti_d.c(revision 4521)
+++ src/northbridge/amd/amdmct/wrappers/mcti_d.c(working copy)
@@ -347,45 +347,45 @@
u32Addr = mct_GetRcvrSysAddr_D(pMCTstat,
pDCTstat, u8Channel, u8Receiver, &u8Valid);
if(!u8Valid) { /* Address not supported on
current CS */
- print_t("vErrara350: Address not
supported on current CS\n");
+ print_t("vErrata350: Address not
supported on current CS\n");
continue;
}
- print_t("vErrara350: dummy read \n");
+ print_t("vErrata350: dummy read \n");
read32_fs(u32Addr);
}
}
- print_t("vErrara350: step 2a\n");
+ print_t("vErrata350: step 2a\n");
/* 2. Write _8000h to register F2x[1, 0]9C_xD080F0C. */
u32DctDev = pDCTstat->dev_dct;
- Set_NB32_index_wait(u32DctDev, 0x098, 0x0c, 0x8000);
+ Set_NB32_index_wait(u32DctDev, 0x098, 0xD080F0C, 0x8000);
/*^--- value
- ^---F2x[1, 0]9C_x0C DRAM
Phy Miscellaneous Register
+ ^---F2x[1,
0]9C_x0D080F0C, No description in BKDG.
^F2x[1, 0]98 DRAM
Controller Additional Data Offset Register */
if(!pDCTstat->GangedMode) {
- print_t("vErrara350: step 2b\n");
- Set_NB32_index_wait(u32DctDev, 0x198, 0x0c, 0x8000);
+ print_t("vErrata350: step 2b\n");
+ Set_NB32_index_wait(u32DctDev, 0x198, 0xD080F0C,
0x8000);
/*^---
value
- ^---F2x[1,
0]9C_x0C DRAM Phy Miscellaneous Register
+ ^---F2x[1,
0]9C_x0D080F0C, No description in BKDG
^F2x[1, 0]98 DRAM
Controller Additional Data Offset Register */
}
- print_t("vErrara350: step 3\n");
+ print_t("vErrata350: step 3\n");
/* 3. Wait at least 300 nanoseconds. */
coreDelay();
- print_t("vErrara350: step 4\n");
+ print_t("vErrata350: step 4\n");
/* 4. Write _h to register F2x[1, 0]9C_xD080F0C. */
- Set_NB32_index_wait(u32DctDev, 0x098, 0x0c, 0x);
+ Set_NB32_index_wait(u32DctDev, 0x098, 0xD080F0C, 0x);
if(!pDCTstat->GangedMode) {
- print_t("vErrara350: step 4b\n");
- Set_NB32_index_wait(u32DctDev, 0x198, 0x0c, 0x);
+ print_t("vErrata350: step 4b\n");
+ Set_NB32_index_wait(u32DctDev, 0x198, 0xD080F0C,
0x);
}
- print_t("vErrara350: step 5\n");
+ print_t("vErrata350: step 5\n");
/* 5. Wait at least 2 microseconds. */
coreDelay();
fix_fam10_Errata350.patch
Description: fix_fam10_Errata350.patch
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]:The Errata350 is fixed as the way it should be
Committed to r4553. -Original Message- From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2...@gmx.net] Sent: Wednesday, August 19, 2009 3:04 PM To: Bao, Zheng Cc: Coreboot Subject: Re: [coreboot] [PATCH]:The Errata350 is fixed as the way it should be On 19.08.2009 04:39, Bao, Zheng wrote: > The Errata350 is "Write _8000h to register F2x[1, 0]9C_xD080F0C.", > instead of > F2x[1, 0]9C_x0C. It is a obvious bug. Some typos are also fixed. > Acked-by: Carl-Daniel Hailfinger Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH]: AMD FAM10 MCT: Channel B only.
Without this patch, if we only got a DIMM in Channel B, memory can not
be
set up correctly. Now it can. Please test it.
Moving "mct_AfterGetCLT(pMCTstat, pDCTstat, dct);" out of the "if" is
the
key point.
Changing the Get_DIMMAddress_D(pDCTstat, i) to
Get_DIMMAddress_D(pDCTstat, dct + i)
doesnt seem to take any effect. But I believe this is what it should be.
Zheng
Signed-off-by: Zheng Bao
Index: src/northbridge/amd/amdmct/mct/mct_d.c
===
--- src/northbridge/amd/amdmct/mct/mct_d.c (revision 4561)
+++ src/northbridge/amd/amdmct/mct/mct_d.c (working copy)
@@ -982,8 +982,8 @@
if ( mctGet_NVbits(NV_MCTUSRTMGMODE) == 2)
pDCTstat->Speed = mctGet_NVbits(NV_MemCkVal) +
1;
- mct_AfterGetCLT(pMCTstat, pDCTstat, dct);
}
+ mct_AfterGetCLT(pMCTstat, pDCTstat, dct);
/* Gather all DIMM mini-max values for cycle timing data */
Rows = 0;
@@ -1001,7 +1001,7 @@
for ( i = 0; i< MAX_DIMMS_SUPPORTED; i++) {
LDIMM = i >> 1;
if (pDCTstat->DIMMValid & (1 << i)) {
- smbaddr = Get_DIMMAddress_D(pDCTstat, i);
+ smbaddr = Get_DIMMAddress_D(pDCTstat, dct + i);
byte = mctRead_SPD(smbaddr, SPD_ROWSZ);
if (Rows < byte)
Rows = byte;/* keep track of largest
row sz */
amd_fam10_mct_only_channel_B.patch
Description: amd_fam10_mct_only_channel_B.patch
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch] [AMD Fam10] Fix confused RB-C2 and DA-C2
Committed to r4562. -Original Message- From: coreboot-boun...@coreboot.org [mailto:coreboot-boun...@coreboot.org] On Behalf Of Bao, Zheng Sent: Thursday, August 06, 2009 10:27 AM To: Ward Vandewege Cc: Coreboot Subject: Re: [coreboot] [patch] [AMD Fam10] Fix confused RB-C2 and DA-C2 I am trying to port the ddr3 feature. I will submit a full patch to replace this one. Zheng -Original Message- From: Ward Vandewege [mailto:w...@gnu.org] Sent: Tuesday, July 21, 2009 3:58 AM To: Bao, Zheng Cc: Coreboot Subject: Re: [coreboot] [patch] [AMD Fam10] Fix confused RB-C2 and DA-C2 On Thu, Jul 16, 2009 at 03:40:49PM +0800, Bao, Zheng wrote: > This patch is about the DA-C2 and RB-C2. Chip with install processor > Revision ID of 0x100F62 is DA-C2, instead of RB-C2 which was incorrectly > defined in raminit_amdmct.c. RB-C2's ID is 0x100F42. The Erratas applied > to > them are almost the same. > > Issues: > 1. I really dont know what their nicknames are (Shanghai C2 or > something). > 2. About the mc_patch_0186.h, I dont know if it is allowed to be > released. >If you really need it, please contact AMD Inc to see if it is public. > 3. I haven't made coreboot go thoroughly on this RB-C2. This patch is > just half tested. >I am not confident it is 100% correct. > > Zheng > > > Signed-off-by: Zheng Bao With this patch, I can still boot my system with 00100F42h (RB-C2) CPUs - Opteron 2372HE. Acked-by: Ward Vandewege Thanks, Ward. -- Ward Vandewege -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch] [AMD Fam10] Fix confused RB-C2 and DA-C2
Issues: 1. I really don't know what their nicknames are (Shanghai C2 or something). 2. About the mc_patch_0186.h, I don't know if it is allowed to be released. If you really need it, please contact AMD Inc to see if it is public. 3. My RB-C2 is Socket type AM3, which needs DDR3 support. Probably your RB-C2 doesn't need DDR3. If it does and you really need it, please contact AMD Inc to see if it is allowed to release DDR3 code. Zheng -Original Message- From: coreboot-boun...@coreboot.org [mailto:coreboot-boun...@coreboot.org] On Behalf Of Bao, Zheng Sent: Monday, August 24, 2009 2:32 PM To: Coreboot Subject: Re: [coreboot] [patch] [AMD Fam10] Fix confused RB-C2 and DA-C2 Committed to r4562. -Original Message- From: coreboot-boun...@coreboot.org [mailto:coreboot-boun...@coreboot.org] On Behalf Of Bao, Zheng Sent: Thursday, August 06, 2009 10:27 AM To: Ward Vandewege Cc: Coreboot Subject: Re: [coreboot] [patch] [AMD Fam10] Fix confused RB-C2 and DA-C2 I am trying to port the ddr3 feature. I will submit a full patch to replace this one. Zheng -Original Message- From: Ward Vandewege [mailto:w...@gnu.org] Sent: Tuesday, July 21, 2009 3:58 AM To: Bao, Zheng Cc: Coreboot Subject: Re: [coreboot] [patch] [AMD Fam10] Fix confused RB-C2 and DA-C2 On Thu, Jul 16, 2009 at 03:40:49PM +0800, Bao, Zheng wrote: > This patch is about the DA-C2 and RB-C2. Chip with install processor > Revision ID of 0x100F62 is DA-C2, instead of RB-C2 which was incorrectly > defined in raminit_amdmct.c. RB-C2's ID is 0x100F42. The Erratas applied > to > them are almost the same. > > Issues: > 1. I really dont know what their nicknames are (Shanghai C2 or > something). > 2. About the mc_patch_0186.h, I dont know if it is allowed to be > released. >If you really need it, please contact AMD Inc to see if it is public. > 3. I haven't made coreboot go thoroughly on this RB-C2. This patch is > just half tested. >I am not confident it is 100% correct. > > Zheng > > > Signed-off-by: Zheng Bao With this patch, I can still boot my system with 00100F42h (RB-C2) CPUs - Opteron 2372HE. Acked-by: Ward Vandewege Thanks, Ward. -- Ward Vandewege -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]: AMD FAM10 MCT: Channel B only.
Have you guys tried 2 different types of DIMM on Channel A/B respectively? By
"different", I mean "very different, totally different". Maybe one is
Single-Rank, while the other is Dual-Rank.
Zheng
-Original Message-
From: Stefan Reinauer [mailto:ste...@coresystems.de]
Sent: Monday, August 24, 2009 6:01 PM
To: Bao, Zheng
Cc: Coreboot
Subject: Re: [coreboot] [PATCH]: AMD FAM10 MCT: Channel B only.
On 8/24/09 5:41 AM, Bao, Zheng wrote:
> Without this patch, if we only got a DIMM in Channel B, memory can not
> be
> set up correctly. Now it can. Please test it.
>
> Moving "mct_AfterGetCLT(pMCTstat, pDCTstat, dct);" out of the "if" is
> the
> key point.
> Changing the Get_DIMMAddress_D(pDCTstat, i) to
> Get_DIMMAddress_D(pDCTstat, dct + i)
> doesnt seem to take any effect. But I believe this is what it should be.
>
> Zheng
>
> Signed-off-by: Zheng Bao
>
Awesome finding!
Acked-by: Stefan Reinauer
> Index: src/northbridge/amd/amdmct/mct/mct_d.c
> ===
> --- src/northbridge/amd/amdmct/mct/mct_d.c(revision 4561)
> +++ src/northbridge/amd/amdmct/mct/mct_d.c(working copy)
> @@ -982,8 +982,8 @@
> if ( mctGet_NVbits(NV_MCTUSRTMGMODE) == 2)
> pDCTstat->Speed = mctGet_NVbits(NV_MemCkVal) +
> 1;
>
> - mct_AfterGetCLT(pMCTstat, pDCTstat, dct);
> }
> + mct_AfterGetCLT(pMCTstat, pDCTstat, dct);
>
> /* Gather all DIMM mini-max values for cycle timing data */
> Rows = 0;
> @@ -1001,7 +1001,7 @@
> for ( i = 0; i< MAX_DIMMS_SUPPORTED; i++) {
> LDIMM = i >> 1;
> if (pDCTstat->DIMMValid & (1 << i)) {
> - smbaddr = Get_DIMMAddress_D(pDCTstat, i);
> + smbaddr = Get_DIMMAddress_D(pDCTstat, dct + i);
> byte = mctRead_SPD(smbaddr, SPD_ROWSZ);
> if (Rows < byte)
> Rows = byte;/* keep track of largest
> row sz */
>
--
coresystems GmbH * Brahmsstr. 16 * D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 * Fax: +49 761 7664613
Email: i...@coresystems.de * http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg * HRB 7656
Geschäftsführer: Stefan Reinauer * Ust-IdNr.: DE245674866
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]: AMD FAM10 MCT: Channel B only.
Committed, r4569.
And the extra semicolon is removed.
-Original Message-
From: Stefan Reinauer [mailto:ste...@coresystems.de]
Sent: Monday, August 24, 2009 6:01 PM
To: Bao, Zheng
Cc: Coreboot
Subject: Re: [coreboot] [PATCH]: AMD FAM10 MCT: Channel B only.
On 8/24/09 5:41 AM, Bao, Zheng wrote:
> Without this patch, if we only got a DIMM in Channel B, memory can not
> be
> set up correctly. Now it can. Please test it.
>
> Moving "mct_AfterGetCLT(pMCTstat, pDCTstat, dct);" out of the "if" is
> the
> key point.
> Changing the Get_DIMMAddress_D(pDCTstat, i) to
> Get_DIMMAddress_D(pDCTstat, dct + i)
> doesnt seem to take any effect. But I believe this is what it should be.
>
> Zheng
>
> Signed-off-by: Zheng Bao
>
Awesome finding!
Acked-by: Stefan Reinauer
> Index: src/northbridge/amd/amdmct/mct/mct_d.c
> ===
> --- src/northbridge/amd/amdmct/mct/mct_d.c(revision 4561)
> +++ src/northbridge/amd/amdmct/mct/mct_d.c(working copy)
> @@ -982,8 +982,8 @@
> if ( mctGet_NVbits(NV_MCTUSRTMGMODE) == 2)
> pDCTstat->Speed = mctGet_NVbits(NV_MemCkVal) +
> 1;
>
> - mct_AfterGetCLT(pMCTstat, pDCTstat, dct);
> }
> + mct_AfterGetCLT(pMCTstat, pDCTstat, dct);
>
> /* Gather all DIMM mini-max values for cycle timing data */
> Rows = 0;
> @@ -1001,7 +1001,7 @@
> for ( i = 0; i< MAX_DIMMS_SUPPORTED; i++) {
> LDIMM = i >> 1;
> if (pDCTstat->DIMMValid & (1 << i)) {
> - smbaddr = Get_DIMMAddress_D(pDCTstat, i);
> + smbaddr = Get_DIMMAddress_D(pDCTstat, dct + i);
> byte = mctRead_SPD(smbaddr, SPD_ROWSZ);
> if (Rows < byte)
> Rows = byte;/* keep track of largest
> row sz */
>
--
coresystems GmbH * Brahmsstr. 16 * D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 * Fax: +49 761 7664613
Email: i...@coresystems.de * http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg * HRB 7656
Geschäftsführer: Stefan Reinauer * Ust-IdNr.: DE245674866
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Fix SB600 SATA BAR printing
It is a bug itself, not made by new thing. Thanks.
Acked-by: Zheng Bao
-Original Message-
From: coreboot-bounces+zheng.bao=amd@coreboot.org
[mailto:coreboot-bounces+zheng.bao=amd@coreboot.org] On Behalf Of
Carl-Daniel Hailfinger
Sent: Thursday, August 27, 2009 10:31 AM
To: Coreboot
Subject: [coreboot] [PATCH] Fix SB600 SATA BAR printing
The new resource allocator made a bug in SB600 SATA BAR printing very
visible (the SB600 code printed that two BARs had the same address).
Mask the correct number of bits.
Tested on Asus M2A-VM (AMD DBM690T target).
Signed-off-by: Carl-Daniel Hailfinger
Index: LinuxBIOSv2-asus_m2a-vm/src/southbridge/amd/sb600/sb600_sata.c
===
--- LinuxBIOSv2-asus_m2a-vm/src/southbridge/amd/sb600/sb600_sata.c
(Revision 4589)
+++ LinuxBIOSv2-asus_m2a-vm/src/southbridge/amd/sb600/sb600_sata.c
(Arbeitskopie)
@@ -86,10 +86,10 @@
/* get base addresss */
sata_bar5 = (u8 *) (pci_read_config32(dev, 0x24) & ~0x3FF);
sata_bar0 = pci_read_config16(dev, 0x10) & ~0x7;
- sata_bar1 = pci_read_config16(dev, 0x14) & ~0x7;
+ sata_bar1 = pci_read_config16(dev, 0x14) & ~0x3;
sata_bar2 = pci_read_config16(dev, 0x18) & ~0x7;
- sata_bar3 = pci_read_config16(dev, 0x1C) & ~0x7;
- sata_bar4 = pci_read_config16(dev, 0x20) & ~0x7;
+ sata_bar3 = pci_read_config16(dev, 0x1C) & ~0x3;
+ sata_bar4 = pci_read_config16(dev, 0x20) & ~0xf;
printk_spew("sata_bar0=%x\n", sata_bar0); /* 3030 */
printk_spew("sata_bar1=%x\n", sata_bar1); /* 3070 */
--
http://www.hailfinger.org/
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD 780 support
RS780 code has been roughly done. I don't have the permission to give it to you. Please contact kevin.tang...@amd.com to get that. Zheng From: coreboot-boun...@coreboot.org [mailto:coreboot-boun...@coreboot.org] On Behalf Of Daniel Toussaint Sent: Monday, September 07, 2009 6:57 PM To: coreboot@coreboot.org Subject: [coreboot] AMD 780 support Dear Coreboot , Is there any sign of the AMD 780 code yet ? I have a board just waiting to be flashed with it ... :) Greetings, Daniel Toussaint -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] unstable AMD Fam10h boot
Are you sure the pci functions will cover the case that the address is more than 0x100? Zheng -Original Message- From: coreboot-boun...@coreboot.org [mailto:coreboot-boun...@coreboot.org] On Behalf Of Marc Jones Sent: Tuesday, September 15, 2009 12:45 AM To: ron minnich Cc: coreboot@coreboot.org Subject: Re: [coreboot] unstable AMD Fam10h boot I am not sure what I was thinking last night. This is really simple... There is no address manipulation to be done before calling the coreboot pci functions. Thanks Patrick Marc -- http://marcjonesconsulting.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] r4633 building error of serengeti_cheetah_fam10
I am using FC10. GCC 4.3.2. ... make[1]: Leaving directory `/home/baozheng/LinuxBIOS/coreboot-v2-org/util/cbfstool' make -C fallback coreboot.rom cat: ../../VERSION: No such file or directory make[1]: Entering directory `/home/baozheng/LinuxBIOS/coreboot-v2-org/targets/amd/serengeti_cheetah_ fam10/serengeti_cheetah_fam10/fallback' gcc -m32 -x assembler-with-cpp -DASSEMBLY -E -I/home/baozheng/LinuxBIOS/coreboot-v2-org/src/include -I/home/baozheng/LinuxBIOS/coreboot-v2-org/src/arch/i386/include -I/usr/lib/gcc/i386-redhat-linux/4.3.2/include -include /home/baozheng/LinuxBIOS/coreboot-v2-org/targets/amd/serengeti_cheetah_f am10/serengeti_cheetah_fam10/fallback/settings.h -I/home/baozheng/LinuxBIOS/coreboot-v2-org/util/x86emu/include -I. -I/home/baozheng/LinuxBIOS/coreboot-v2-org/src crt0.S > crt0.s.new && mv crt0.s.new crt0.s gcc -m32 -Wa,-acdlns -c -o crt0.o crt0.s >crt0.disasm gcc -m32 -Wl,--build-id=none -nostdlib -nostartfiles -static -o coreboot -T ldscript.ld crt0.o src/lib/lzma.o src/lib/cbfs.o src/arch/i386/lib/cbfs_and_run.o src/lib/uart8250.o src/lib/memcmp.o src/lib/memcpy.o src/lib/memset.o src/console/vtxprintf.o src/arch/i386/lib/printk_init.o nm -n coreboot | sort > coreboot.map objdump -dS coreboot > coreboot.disasm objcopy --gap-fill 0xff -O binary coreboot coreboot.strip PAYLOAD=payload; if [ 1 -eq 1 ]; then PAYLOAD=/dev/null; touch cbfs-support; fi; ./buildrom coreboot.strip coreboot.rom $PAYLOAD 0x7f000 0x7f000 Payload: 0 coreboot: 520192 ROM size: 520192 Left space: 0 if [ 0 -eq 1 -a 1 -eq 1 ]; then echo l > cbfs-support; fi make[1]: Leaving directory `/home/baozheng/LinuxBIOS/coreboot-v2-org/targets/amd/serengeti_cheetah_ fam10/serengeti_cheetah_fam10/fallback' make -C failover coreboot.rom cat: ../../VERSION: No such file or directory make[1]: Entering directory `/home/baozheng/LinuxBIOS/coreboot-v2-org/targets/amd/serengeti_cheetah_ fam10/serengeti_cheetah_fam10/failover' gcc -m32 -x assembler-with-cpp -DASSEMBLY -E -I/home/baozheng/LinuxBIOS/coreboot-v2-org/src/include -I/home/baozheng/LinuxBIOS/coreboot-v2-org/src/arch/i386/include -I/usr/lib/gcc/i386-redhat-linux/4.3.2/include -include /home/baozheng/LinuxBIOS/coreboot-v2-org/targets/amd/serengeti_cheetah_f am10/serengeti_cheetah_fam10/failover/settings.h -I/home/baozheng/LinuxBIOS/coreboot-v2-org/util/x86emu/include -I. -I/home/baozheng/LinuxBIOS/coreboot-v2-org/src crt0.S > crt0.s.new && mv crt0.s.new crt0.s gcc -m32 -Wa,-acdlns -c -o crt0.o crt0.s >crt0.disasm gcc -m32 -Wl,--build-id=none -nostdlib -nostartfiles -static -o coreboot -T ldscript.ld crt0.o src/lib/uart8250.o src/lib/memcmp.o src/lib/memcpy.o src/lib/memset.o src/console/vtxprintf.o src/arch/i386/lib/printk_init.o nm -n coreboot | sort > coreboot.map objdump -dS coreboot > coreboot.disasm objcopy --gap-fill 0xff -O binary coreboot coreboot.strip cp coreboot.strip coreboot.rom make[1]: Leaving directory `/home/baozheng/LinuxBIOS/coreboot-v2-org/targets/amd/serengeti_cheetah_ fam10/serengeti_cheetah_fam10/failover' rm -f ./coreboot.rom cat fallback/coreboot.rom failover/coreboot.rom > ./coreboot.rom.bootblock ./cbfs/cbfstool ./coreboot.rom create 1048576 528384 ./coreboot.rom.bootblock ./cbfs/cbfstool ./coreboot.rom add-payload ../payload.elf fallback/payload make: *** [coreboot.rom] Segmentation fault make: *** Deleting file `coreboot.rom' -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] r4633 building error of serengeti_cheetah_fam10
It was fixed. Zheng -Original Message- From: Patrick Georgi [mailto:patr...@georgi-clan.de] Sent: Tuesday, September 15, 2009 4:26 PM To: Bao, Zheng Cc: coreboot@coreboot.org Subject: Re: [coreboot] r4633 building error of serengeti_cheetah_fam10 Am Dienstag, den 15.09.2009, 11:00 +0800 schrieb Bao, Zheng: > ./cbfs/cbfstool ./coreboot.rom add-payload ../payload.elf > fallback/payload > > make: *** [coreboot.rom] Segmentation fault r4634 fixes segmentation faults when the file cannot be found. "../payload.elf" is suspicious - are you sure that is the right path? If you're certain that this file should exist at that place, and if the segmentation fault still occurs with r4634, some more information is necessary: - which payload is this (so I can try to reproduce it, a copy of the payload binary would help the most) - is your build machine 32bit or 64bit? Regards, Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] r4633 building error of serengeti_cheetah_fam10
Wrote coreboot table at: 3fff4000 - 3fff4918 checksum c71b
Check CBFS header at fff7efe0
magic is 4f524243
Found CBFS header at fff7efe0
Check fallback/payload
Got a payload
Loading segment from rom address 0xfff00038
parameter section (skipped)
Loading segment from rom address 0xfff00054
data (compression=0)
malloc Enter, size 36, free_mem_ptr 0023d57c
malloc 0023d57c
New segment dstaddr 0x10 memsize 0x1650b0 srcaddr 0xfff000d8
filesize 0x15960
(cleaned up) New segment addr 0x10 size 0x1650b0 offset 0xfff000d8
filesize 0x15960
Loading segment from rom address 0xfff00070
data (compression=0)
malloc Enter, size 36, free_mem_ptr 0023d5a0
malloc 0023d5a0
New segment dstaddr 0x2650b0 memsize 0x48 srcaddr 0xfff15a38 filesize
0x48
(cleaned up) New segment addr 0x2650b0 size 0x48 offset 0xfff15a38
filesize 0x48
Loading segment from rom address 0xfff0008c
Entry Point 0x0010008c
Loading Segment: addr: 0x0010 memsz: 0x001650b0
filesz: 0x00015960
lb: [0x0020, 0x002fc000)
segment: [0x0010, 0x00115960, 0x002650b0)
malloc Enter, size 36, free_mem_ptr 0023d5c4
malloc 0023d5c4
early: [0x0010, 0x00115960, 0x0020)
bounce: [0x2fe08000, 0x2fe08000, 0x2fe6d0b0)
Post relocation: addr: 0x2fe08000 memsz: 0x000650b0
filesz: 0x
Loading Segment: addr: 0x002650b0 memsz: 0x0048
filesz: 0x0048
lb: [0x0020, 0x002fc000)
segment: [0x002650b0, 0x002650f8, 0x002650f8)
bounce: [0x2fe6d0b0, 0x2fe6d0f8, 0x2fe6d0f8)
Post relocation: addr: 0x2fe6d0b0 memsz: 0x0048
filesz: 0x0048
it's not compressed!
[ 0x2fe6d0b0, 2fe6d0f8, 0x2fe6d0f8) <-
fff15a38
Loaded segments
Jumping to boot code at 10008c
entry= 0x0010008c
lb_start = 0x0020
lb_size = 0x000fc000
adjust = 0x2fc08000
buffer = 0x2fe08000
elf_boot_notes = 0x002318d0
adjusted_boot_notes = 0x2fe398d0
INIT detected from --- {APICID = 00 NODEID = 00 COREID = 00}
---
Issuing SOFT_RESET...
-Original Message-
From: coreboot-boun...@coreboot.org
[mailto:coreboot-boun...@coreboot.org] On Behalf Of Bao, Zheng
Sent: Wednesday, September 16, 2009 10:56 AM
To: Patrick Georgi
Cc: coreboot@coreboot.org
Subject: Re: [coreboot] r4633 building error of serengeti_cheetah_fam10
It was fixed.
Zheng
-Original Message-
From: Patrick Georgi [mailto:patr...@georgi-clan.de]
Sent: Tuesday, September 15, 2009 4:26 PM
To: Bao, Zheng
Cc: coreboot@coreboot.org
Subject: Re: [coreboot] r4633 building error of serengeti_cheetah_fam10
Am Dienstag, den 15.09.2009, 11:00 +0800 schrieb Bao, Zheng:
> ./cbfs/cbfstool ./coreboot.rom add-payload ../payload.elf
> fallback/payload
>
> make: *** [coreboot.rom] Segmentation fault
r4634 fixes segmentation faults when the file cannot be found.
"../payload.elf" is suspicious - are you sure that is the right path?
If you're certain that this file should exist at that place, and if the
segmentation fault still occurs with r4634, some more information is
necessary:
- which payload is this (so I can try to reproduce it, a copy of the
payload binary would help the most)
- is your build machine 32bit or 64bit?
Regards,
Patrick
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] r4633 building error of serengeti_cheetah_fam10
I use the fam10+RS780+SB7x0. That is why I doubt it is my problem. Anyone who has the Serengeti_cheetah could try it. If it is ok, I will check my board and code. Zheng -Original Message- From: ron minnich [mailto:rminn...@gmail.com] Sent: Wednesday, September 16, 2009 1:53 PM To: Bao, Zheng Cc: Patrick Georgi; coreboot@coreboot.org Subject: Re: [coreboot] r4633 building error of serengeti_cheetah_fam10 can you recommend a fam10 board that I could try to get and test on? ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] duplicated code in Coreboot
Since I started to work on the coreboot, I always sense that the much code is duplicated. By duplicated, it doesn't mean the code in different folders is almost same. As a matter of fact, it should be same. For example, the most feature of it871(2,6,8) should be the same. But it8712f_enable_serial doesn't use the first parameter dev, while it8716f_enable_serial does. When the board changes the super io, you can not just change the 2 to 6. You should also change the parameters. That makes me confused. This also happens on some chips which are close. Is it possible to fix this in future? Zheng -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] coreboot hangs on my AMD fam10 board.
Current coreboot seems to hang somewhere. Before the 60th anniversary of
People's Republic of China, I always disable the CBFS when I worked on
my fam10 board, otherwise it would be error. But now, I can not find
where I can disable it. It seems to stop at waiting AP cores.
I am wondering if it is caused by CBFS and if it happens on other board.
If any one can test it, I will be appreciating.
Zheng
---
coreboot-2.0.0-r623M_tilapia_fam10_Fallback Fri Oct 9 13:15:49 CST 2009
starting...
BSP Family_Model: 00100f42
*sysinfo range: [000cc000,000cf360]
bsp_apicid = 00
cpu_init_detectedx =
microcode: equivalent rev id = 0x1041, current patch id = 0x
microcode: patch id to apply = 0x0186
microcode: updated to patch id = 0x0186 success
cpuSetAMDMSR done
Enter amd_ht_init()
AMD_CB_EventNotify()
event class: 05
event: 2006
data: 04 00 00 00
Exit amd_ht_init()
cpuSetAMDPCI 00 done
Prep FID/VID Node:00
F3x80: e600a681
F3x84: a0e641e6
F3xD4: c8810f24
F3xD8: 03001816
F3xDC: 5322
Wait all core0s started
Wait all core0s started done
start_other_cores()
init node: 00 cores: 03
Start other core - nodeid: 00 cores: 03
started ap apicid:cccooorrreeexxx::: - {{{
AAAPPPIIICCC
IIIDDD === 000312 NNNOOODDDEEEIIIDDD === 00
CCCOOORRREEEIIIDDD === 000321}}
} -
APmmm isiictccrarrorootccceoooeee0ee1eqqAquuPui
iivsvvataalallereetnnnetttd rrr:e
uuuvvv0 2 iiAiddPd s =t== a 0r00xtxxe111d000:444 111,,,0 3ccc
00seee7nn8ntt0t _ ppeptrttclcchyhh_ siiiedddt ===u
p(000)xxx
u 000g000e000t00_000c000p0
_
attv EAmmmiXiic=cc0rrrxoooccc1ooo0ddd0eeef:::4 2 pp.paa
0x tcccChhPh U i iidRdd e tvtt oooi saaa ppKlll8yyy_ 1==0= .
00
t xx000f1011a00m000100_808o686p
im
upimmiciizrccorracootocciooodddneee(:::)
hh uuppdrdsada7tat8et0dee_ ddpt oott oorp _appiaatnittctcch
ss iiid dd === 0 0x00xx0010110080886 66
sussucuccceccesesss
cccpuppuSuSSeteetAtAAMDMMDDMMSMSRSR R FFIFIXIMXXsEbMM!7EE0!! 0
C_CCPePPUUU a VrVVeleeryrrs_s
kknioeionto unnup n(uuk)nn
nnooowsbwwnnn 7 o0oor0rr _ nd noenotvot it sc
suesupsup_ppoppproootrrre_ttieedndd!i!! t
(
d FdI
!0 ooXsnnMbeeE7
0
inC_inPdiiUet v_tVif_ecifredisvds_ivipdioodn_ar
_ap_up(insnk(tinsatot(wag)nge: e1 o1)Sr) M a
r3e,opiutics ci idDsd:eu: vp 0ip02co
Fe t
V: IdFBD!IDV DFI
P!P0DD- FI 2oo0nXn- M 0AEA
V : : C 0P02U3
e
edsion unknSoMwBnu so rc onnottr oslulpepro rteenda!b l
kn,F IsXbM Er!e CvPiUs iVoenr siiso nA 12u
own or snbo70t0 _sudpepviocretesd_!po r
oiFnIiXtME(!) : CIPDU EV eDervsiiocne, unBkDFn:ow0n- 20o-r 1n
vt supposrb7t0e0d!_ de
tiFIcXesM_E!p oCr_PiUn Viet(r)s:io nLP Cu nkDneoviwcne o,r BDnFo:t
0s-u20p-p3or
ed!
2IXsMbE7!00 _CdPUe vViceerssi_oponr _unikninto(wn) :o Pr2 Pno tBr
isdupgpeo, rBtDedF!: 0-
n0 d-4o
e
ATit_fsidbv70i0d__daepv(sitceasg_e1p)o ra_ipniciitd():: 0 1S
8 AFI DDVevIiDc oen, BADPF: :00-11
-0
sb700_pmio_por_init()
Begin FIDVID MSR 0xc0010071 0x30b200c3 0x40035c40
FIDVID on BSP, APIC_id: 00
BSP fid = 10600
Wait for AP stage 1: ap_apicid = 1
readback = 1010601
common_fid(packed) = 10600
Wait for AP stage 1: ap_apicid = 2
readback = 2010601
common_fid(packed) = 10600
Wait for AP stage 1: ap_apicid = 3
readback = 3010601
common_fid(packed) = 10600
common_fid = 10600
FID Change Node:00, F3xD4: c8810f26
End FIDVIDMSR 0xc0010071 0x30b200c3 0x38035c40
rs780_htinit cpu_ht_freq=b.
rs780_htinit: HT3 mode
...WARM RESET...
coreboot-2.0.0-r623M_tilapia_fam10_Fallback Fri Oct 9 13:15:49 CST 2009
starting...
BSP Family_Model: 00100f42
*sysinfo range: [000cc000,000cf360]
bsp_apicid = 00
cpu_init_detectedx =
microcode: equivalent rev id = 0x1041, current patch id = 0x
microcode: patch id to apply = 0x0186
microcode: updated to patch id = 0x0186 success
cpuSetAMDMSR done
Enter amd_ht_init()
AMD_CB_EventNotify()
event class: 05
event: 2006
data: 04 00 00 00
Exit amd_ht_init()
cpuSetAMDPCI 00 done
Prep FID/VID Node:00
F3x80: e600a681
F3x84: a0e641e6
F3xD4: c8810f26
F3xD8: 03001816
F3xDC: 5322
Wait all core0s started
Wait all core0s started done
start_other_cores()
init node: 00 cores: 03
Start other core - nodeid: 00 cores: 03
started ap apicid:cccooorrreeexxx::: - {{{
AAAPPPIIICCC
IIIDDD === 000132 NNNOOODDDEEEIIIDDD === 00
CCCOOORRREEEIIIDDD === 000123}}
} -
APmmm isiitcccaoootccceooo:eee :::0 eee1qqqAuuuPiii
vvvsaaatlllaeeernnne d rr:re
cccvv0v 2 iiAiddPd s =t== a 0r00xtxx1e110d004:441 110,,,3
00srrr7eee8nnn0ttt_ eppprtttccclhhhy _iiisddde t===u
p(000)xxx
u 000g000e000t000_000c000p
tttev EAmmmiiXicc=c0rrroooxccc1ooo0ddd0eeef:::4 2ppp.aaa
xxxcccChPhh U i iidRdd e tvtto ooi saaa pppKppp8lll_yyy1 0===.
000
t 000fa111m001000_888o666p
icczcrrarootoccicdd
Re: [coreboot] coreboot hangs on my AMD fam10 board.
Does it mean the buildtarget is obsolete? Zheng -Original Message- From: Marc Jones [mailto:marcj...@gmail.com] Sent: Friday, October 09, 2009 11:34 PM To: Bao, Zheng Cc: coreboot@coreboot.org Subject: Re: [coreboot] coreboot hangs on my AMD fam10 board. On Fri, Oct 9, 2009 at 12:10 AM, Bao, Zheng wrote: > Current coreboot seems to hang somewhere. Before the 60th anniversary of > People's Republic of China, I always disable the CBFS when I worked on > my fam10 board, otherwise it would be error. But now, I can not find > where I can disable it. It seems to stop at waiting AP cores. > > I am wondering if it is caused by CBFS and if it happens on other board. > If any one can test it, I will be appreciating. > Hi Zheng, There has been a lot of work with CBFS and with Kconfig in the last few weeks. Myles and Patrick have been testing in system and in SimNow so it should work. Can you try updating your platform to use them? Marc -- http://marcjonesconsulting.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot hangs on my AMD fam10 board (update debug message).
I update the code. It hangs at somewhere else. It seems to be what
Carl-Daniel said. Is there any workaround way to skip this and let do my
own job?
Zheng
-Original Message-
From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2...@gmx.net]
Sent: Saturday, October 10, 2009 9:16 AM
To: Bao, Zheng
Cc: coreboot@coreboot.org
Subject: Re: [coreboot] coreboot hangs on my AMD fam10 board.
On 09.10.2009 08:10, Bao, Zheng wrote:
> Current coreboot seems to hang somewhere. Before the 60th anniversary
of
> People's Republic of China, I always disable the CBFS when I worked on
> my fam10 board, otherwise it would be error. But now, I can not find
> where I can disable it. It seems to stop at waiting AP cores.
>
> I am wondering if it is caused by CBFS and if it happens on other
board.
> If any one can test it, I will be appreciating.
>
We have not solved the SMP startup printk locking yet. That explains the
mangled log messages.
Unless I'm mistaken we still decompress some parts multiple times
concurrently to the same address and that can crash the code.
Overlapping stack might also crash the code during lzma decompression.
Decompression of AP code should happen on the BSP or on exactly one AP,
but not on all APs.
> coreboot-2.0.0-r623M_tilapia_fam10_Fallback Fri Oct 9 13:15:49 CST
2009
> starting...
> [...]
> Start other core - nodeid: 00 cores: 03
> started ap apicid:cccooorrreeexxx::: - {{{
> AAAPPPIIICCC
> IIIDDD === 000312 NNNOOODDDEEEIIIDDD === 00
> CCCOOORRREEEIIIDDD === 000321}}
> } -
>
Regards,
Carl-Daniel
--
Developer quote of the week:
"We are juggling too many chainsaws and flaming arrows and tigers."
amd_fam10_hang.log
Description: amd_fam10_hang.log
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot hangs on my AMD fam10 board (update debugmessage).
Ping. What is the way to solve this?
I can merge the CBFS to our code for a long time.
Zheng
-Original Message-
From: coreboot-boun...@coreboot.org
[mailto:coreboot-boun...@coreboot.org] On Behalf Of Bao, Zheng
Sent: Saturday, October 10, 2009 10:12 AM
To: coreboot@coreboot.org; Carl-Daniel Hailfinger
Subject: Re: [coreboot] coreboot hangs on my AMD fam10 board (update
debugmessage).
I update the code. It hangs at somewhere else. It seems to be what
Carl-Daniel said. Is there any workaround way to skip this and let do my
own job?
Zheng
-Original Message-
From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2...@gmx.net]
Sent: Saturday, October 10, 2009 9:16 AM
To: Bao, Zheng
Cc: coreboot@coreboot.org
Subject: Re: [coreboot] coreboot hangs on my AMD fam10 board.
On 09.10.2009 08:10, Bao, Zheng wrote:
> Current coreboot seems to hang somewhere. Before the 60th anniversary
of
> People's Republic of China, I always disable the CBFS when I worked on
> my fam10 board, otherwise it would be error. But now, I can not find
> where I can disable it. It seems to stop at waiting AP cores.
>
> I am wondering if it is caused by CBFS and if it happens on other
board.
> If any one can test it, I will be appreciating.
>
We have not solved the SMP startup printk locking yet. That explains the
mangled log messages.
Unless I'm mistaken we still decompress some parts multiple times
concurrently to the same address and that can crash the code.
Overlapping stack might also crash the code during lzma decompression.
Decompression of AP code should happen on the BSP or on exactly one AP,
but not on all APs.
> coreboot-2.0.0-r623M_tilapia_fam10_Fallback Fri Oct 9 13:15:49 CST
2009
> starting...
> [...]
> Start other core - nodeid: 00 cores: 03
> started ap apicid:cccooorrreeexxx::: - {{{
> AAAPPPIIICCC
> IIIDDD === 000312 NNNOOODDDEEEIIIDDD === 00
> CCCOOORRREEEIIIDDD === 000321}}
> } -
>
Regards,
Carl-Daniel
--
Developer quote of the week:
"We are juggling too many chainsaws and flaming arrows and tigers."
amd_fam10_hang.log
Description: amd_fam10_hang.log
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot hangs on my AMD fam10 board (updatedebugmessage).
Ping. What is the way to solve this?
I can NOT merge the CBFS to our code for a long time.
Zheng
-Original Message-
From: coreboot-boun...@coreboot.org
[mailto:coreboot-boun...@coreboot.org] On Behalf Of Bao, Zheng
Sent: Saturday, October 10, 2009 10:12 AM
To: coreboot@coreboot.org; Carl-Daniel Hailfinger
Subject: Re: [coreboot] coreboot hangs on my AMD fam10 board (update
debugmessage).
I update the code. It hangs at somewhere else. It seems to be what
Carl-Daniel said. Is there any workaround way to skip this and let do my
own job?
Zheng
-Original Message-
From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2...@gmx.net]
Sent: Saturday, October 10, 2009 9:16 AM
To: Bao, Zheng
Cc: coreboot@coreboot.org
Subject: Re: [coreboot] coreboot hangs on my AMD fam10 board.
On 09.10.2009 08:10, Bao, Zheng wrote:
> Current coreboot seems to hang somewhere. Before the 60th anniversary
of
> People's Republic of China, I always disable the CBFS when I worked on
> my fam10 board, otherwise it would be error. But now, I can not find
> where I can disable it. It seems to stop at waiting AP cores.
>
> I am wondering if it is caused by CBFS and if it happens on other
board.
> If any one can test it, I will be appreciating.
>
We have not solved the SMP startup printk locking yet. That explains the
mangled log messages.
Unless I'm mistaken we still decompress some parts multiple times
concurrently to the same address and that can crash the code.
Overlapping stack might also crash the code during lzma decompression.
Decompression of AP code should happen on the BSP or on exactly one AP,
but not on all APs.
> coreboot-2.0.0-r623M_tilapia_fam10_Fallback Fri Oct 9 13:15:49 CST
2009
> starting...
> [...]
> Start other core - nodeid: 00 cores: 03
> started ap apicid:cccooorrreeexxx::: - {{{
> AAAPPPIIICCC
> IIIDDD === 000312 NNNOOODDDEEEIIIDDD === 00
> CCCOOORRREEEIIIDDD === 000321}}
> } -
>
Regards,
Carl-Daniel
--
Developer quote of the week:
"We are juggling too many chainsaws and flaming arrows and tigers."
amd_fam10_hang.log
Description: amd_fam10_hang.log
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH]: vga bios was added into image by cbfstool, not by "cat" any more.
Add CONFIG_VGA_ROM_RUN to dbm690t and pistachio, otherwise the
VGA ROM can not run. After make, run
> ./cbfs/cbfstool ./coreboot.rom add ../vga_bios.rom pci1002,791f.rom
optionrom
to make the final image with vga bios.
The macro vga_rom_address is out-of-date when CBFS starts play its role.
it also should
be eliminated from rs690/chip.h as below. But it will cause building
error on other board, which I
can not make test on.
##Index: src/southbridge/amd/rs690/chip.h
##
===
##--- src/southbridge/amd/rs690/chip.h (revision 4782)
##+++ src/southbridge/amd/rs690/chip.h (working copy)
##@@ -23,7 +23,6 @@
## /* Member variables are defined in Config.lb. */
## struct southbridge_amd_rs690_config
## {
##- u32 vga_rom_address;/* The location that the VGA rom
has been appened. */
## u8 gpp_configuration; /* The configuration of General Purpose
Port, A/B/C/D/E. */
## u8 port_enable; /* Which port is enabled? GFX(2,3),
GPP(4,5,6,7) */
## u8 gfx_dev2_dev3; /* for GFX Core initialization
REFCLK_SEL */
##
Don't apply the above patch about rs690/chip.h before every board has
fixed.
Signed-off-by: Zheng Bao
Index: src/southbridge/amd/rs690/rs690_gfx.c
===
--- src/southbridge/amd/rs690/rs690_gfx.c (revision 4782)
+++ src/southbridge/amd/rs690/rs690_gfx.c (working copy)
@@ -77,13 +77,9 @@
(struct southbridge_amd_rs690_config *)dev->chip_info;
deviceid = pci_read_config16(dev, PCI_DEVICE_ID);
vendorid = pci_read_config16(dev, PCI_VENDOR_ID);
- printk_info("internal_gfx_pci_dev_init device=%x, vendor=%x,
vga_rom_address=0x%x.\n",
-deviceid, vendorid, cfg->vga_rom_address);
+ printk_info("internal_gfx_pci_dev_init device=%x, vendor=%x.\n",
+deviceid, vendorid);
-#if 0 /* I think these should be done in Config.lb. Please check it. */
- dev->on_mainboard = 1;
- dev->rom_address = cfg->vga_rom_address;/* 0xfff0;
*/
-#endif
pci_dev_init(dev);
/* clk ind */
Index: src/mainboard/amd/dbm690t/Options.lb
===
--- src/mainboard/amd/dbm690t/Options.lb(revision 4782)
+++ src/mainboard/amd/dbm690t/Options.lb(working copy)
@@ -73,6 +73,7 @@
uses CONFIG_OBJCOPY
uses CONFIG_CONSOLE_VGA
uses CONFIG_PCI_ROM_RUN
+uses CONFIG_VGA_ROM_RUN
uses CONFIG_HW_MEM_HOLE_SIZEK
uses CONFIG_HT_CHAIN_UNITID_BASE
uses CONFIG_HT_CHAIN_END_UNITID_BASE
@@ -103,8 +104,6 @@
##
## CONFIG_FALLBACK_SIZE is the amount of the ROM the complete fallback
image will use
##
-#default CONFIG_FALLBACK_SIZE = CONFIG_ROM_IMAGE_SIZE
-#256K
default CONFIG_FALLBACK_SIZE = CONFIG_ROM_IMAGE_SIZE
##
@@ -160,6 +159,7 @@
#VGA Console
default CONFIG_CONSOLE_VGA=1
default CONFIG_PCI_ROM_RUN=1
+default CONFIG_VGA_ROM_RUN=1
# BTDC: Only one HT device on Herring.
#HT Unit ID offset
Index: src/mainboard/amd/dbm690t/Config.lb
===
--- src/mainboard/amd/dbm690t/Config.lb (revision 4782)
+++ src/mainboard/amd/dbm690t/Config.lb (working copy)
@@ -136,7 +136,6 @@
#The variables belong to mainboard are defined here.
#Define gpp_configuration, A=0, B=1, C=2, D=3, E=4(default)
-#Define vga_rom_address = 0xfff
#Define port_enable, (bit map): GFX(2,3), GPP(4,5,6,7)
#Define gfx_dev2_dev3, 0: a link will never be established on Dev2 or
Dev3,
# 1: the system allows a PCIE
link to be established on Dev2 or Dev3.
@@ -170,7 +169,6 @@
device pci 6.0 on end # PCIE P2P
bridge 0x7916
device pci 7.0 on end # PCIE P2P
bridge 0x7917
device pci 8.0 off end # NB/SB
Link P2P bridge
- register "vga_rom_address" =
"0xfff0"
register "gpp_configuration" =
"4"
register "port_enable" = "0xfc"
register "gfx_dev2_dev3" = "1"
Index: src/mainboard/amd/dbm690t/devicetree.cb
===
--- src/mainboard/amd/dbm690t/devicetree.cb (revision 4782)
+++ src/mainboard/amd/dbm690t/devicetree.cb (working copy)
@@ -1,5 +1,4 @@
#Define gpp_configuration, A=0, B=1, C=2, D=3, E=4(default)
-#Define vga_rom_address = 0xfff
#Define port_enable, (bit map): GFX(2,3), GPP(4,5,6,7)
#Define gfx_dev2_dev3, 0: a link will never be established on Dev2 or
Dev3,
# 1: the system allows a PCIE link to be
established on Dev2 or Dev3.
@@ -33,7 +32,6 @@
device pci 6.0 on end # PCIE P2P
bridge 0x7916
Re: [coreboot] [PATCH]: vga bios was added into image by cbfstool, not by "cat" any more.
Other board has been fixed. Please have a test.
Add CONFIG_VGA_ROM_RUN to tim5690, tim8690, kt690, otherwise the
VGA ROM can not run. After make, run
> ./cbfs/cbfstool ./coreboot.rom add ../vga_bios.rom pci1002,791f.rom
optionrom
to make the final image with vga bios.
The macro vga_rom_address is out-of-date when CBFS starts play its role.
it also should
be eliminated from rs690/chip.h.
Zheng
Signed-off-by: Zheng Bao
Index: src/southbridge/amd/rs690/chip.h
===
--- src/southbridge/amd/rs690/chip.h(revision 4782)
+++ src/southbridge/amd/rs690/chip.h(working copy)
@@ -23,7 +23,6 @@
/* Member variables are defined in Config.lb. */
struct southbridge_amd_rs690_config
{
- u32 vga_rom_address;/* The location that the VGA rom
has been appened. */
u8 gpp_configuration; /* The configuration of General Purpose
Port, A/B/C/D/E. */
u8 port_enable; /* Which port is enabled? GFX(2,3),
GPP(4,5,6,7) */
u8 gfx_dev2_dev3; /* for GFX Core initialization
REFCLK_SEL */
Index: src/mainboard/kontron/kt690/Options.lb
===
--- src/mainboard/kontron/kt690/Options.lb (revision 4782)
+++ src/mainboard/kontron/kt690/Options.lb (working copy)
@@ -91,6 +91,7 @@
uses CONFIG_VIDEO_MB
uses CONFIG_GFXUMA
uses CONFIG_HAVE_MAINBOARD_RESOURCES
+uses CONFIG_VGA_ROM_RUN
###
### Build options
@@ -161,6 +162,7 @@
#VGA Console
default CONFIG_CONSOLE_VGA=1
default CONFIG_PCI_ROM_RUN=1
+default CONFIG_VGA_ROM_RUN=1
# BTDC: Only one HT device on Herring.
#HT Unit ID offset
Index: src/mainboard/kontron/kt690/Config.lb
===
--- src/mainboard/kontron/kt690/Config.lb (revision 4782)
+++ src/mainboard/kontron/kt690/Config.lb (working copy)
@@ -136,7 +136,6 @@
#The variables belong to mainboard are defined here.
#Define gpp_configuration, A=0, B=1, C=2, D=3, E=4(default)
-#Define vga_rom_address = 0xfff
#Define port_enable, (bit map): GFX(2,3), GPP(4,5,6,7)
#Define gfx_dev2_dev3, 0: a link will never be established on Dev2 or
Dev3,
# 1: the system allows a PCIE
link to be established on Dev2 or Dev3.
@@ -170,7 +169,6 @@
device pci 6.0 on end # PCIE P2P
bridge 0x7916
device pci 7.0 on end # PCIE P2P
bridge 0x7917
device pci 8.0 off end # NB/SB
Link P2P bridge
- register "vga_rom_address" =
"0xfff0"
register "gpp_configuration" =
"4"
register "port_enable" = "0xfc"
register "gfx_dev2_dev3" = "1"
Index: src/mainboard/kontron/kt690/devicetree.cb
===
--- src/mainboard/kontron/kt690/devicetree.cb (revision 4782)
+++ src/mainboard/kontron/kt690/devicetree.cb (working copy)
@@ -1,5 +1,4 @@
#Define gpp_configuration, A=0, B=1, C=2, D=3, E=4(default)
-#Define vga_rom_address = 0xfff
#Define port_enable, (bit map): GFX(2,3), GPP(4,5,6,7)
#Define gfx_dev2_dev3, 0: a link will never be established on Dev2 or
Dev3,
# 1: the system allows a PCIE
link to be established on Dev2 or Dev3.
@@ -33,7 +32,6 @@
device pci 6.0 on end # PCIE P2P
bridge 0x7916
device pci 7.0 on end # PCIE P2P
bridge 0x7917
device pci 8.0 off end # NB/SB
Link P2P bridge
- register "vga_rom_address" =
"0xfff0"
register "gpp_configuration" =
"4"
register "port_enable" = "0xfc"
register "gfx_dev2_dev3" = "1"
Index: src/mainboard/technexion/tim8690/Options.lb
===
--- src/mainboard/technexion/tim8690/Options.lb (revision 4782)
+++ src/mainboard/technexion/tim8690/Options.lb (working copy)
@@ -90,6 +90,7 @@
uses CONFIG_VIDEO_MB
uses CONFIG_GFXUMA
uses CONFIG_HAVE_MAINBOARD_RESOURCES
+uses CONFIG_VGA_ROM_RUN
###
### Build options
@@ -159,6 +160,7 @@
#VGA Console
default CONFIG_CONSOLE_VGA=1
default CONFIG_PCI_ROM_RUN=1
+default CONFIG_VGA_ROM_RUN=1
# BTDC: Only one HT device on Herring.
#HT Unit ID offset
Index: src/mainboard/technexion/tim8690/Config.lb
===
--- src/mainboard/technexion/tim8690/Config.lb (revision 4782)
+++ src/mainboard/technexion/tim8690/Config.lb (working copy)
@@ -136,7 +136,6 @@
#The variables belong to mainboard are def
[coreboot] FW: [PATCH]: vga bios was added into image by cbfstool, not by "cat" any more.
Ping. Have you guys tested on all the supported boards?
Zheng
-Original Message-
From: coreboot-boun...@coreboot.org
[mailto:coreboot-boun...@coreboot.org] On Behalf Of Bao, Zheng
Sent: Friday, October 16, 2009 4:20 PM
To: Carl-Daniel Hailfinger
Cc: coreboot@coreboot.org
Subject: Re: [coreboot] [PATCH]: vga bios was added into image by
cbfstool,not by "cat" any more.
Other board has been fixed. Please have a test.
Add CONFIG_VGA_ROM_RUN to tim5690, tim8690, kt690, otherwise the
VGA ROM can not run. After make, run
> ./cbfs/cbfstool ./coreboot.rom add ../vga_bios.rom pci1002,791f.rom
optionrom
to make the final image with vga bios.
The macro vga_rom_address is out-of-date when CBFS starts play its role.
it also should
be eliminated from rs690/chip.h.
Zheng
Signed-off-by: Zheng Bao
Index: src/southbridge/amd/rs690/chip.h
===
--- src/southbridge/amd/rs690/chip.h(revision 4782)
+++ src/southbridge/amd/rs690/chip.h(working copy)
@@ -23,7 +23,6 @@
/* Member variables are defined in Config.lb. */
struct southbridge_amd_rs690_config
{
- u32 vga_rom_address;/* The location that the VGA rom
has been appened. */
u8 gpp_configuration; /* The configuration of General Purpose
Port, A/B/C/D/E. */
u8 port_enable; /* Which port is enabled? GFX(2,3),
GPP(4,5,6,7) */
u8 gfx_dev2_dev3; /* for GFX Core initialization
REFCLK_SEL */
Index: src/mainboard/kontron/kt690/Options.lb
===
--- src/mainboard/kontron/kt690/Options.lb (revision 4782)
+++ src/mainboard/kontron/kt690/Options.lb (working copy)
@@ -91,6 +91,7 @@
uses CONFIG_VIDEO_MB
uses CONFIG_GFXUMA
uses CONFIG_HAVE_MAINBOARD_RESOURCES
+uses CONFIG_VGA_ROM_RUN
###
### Build options
@@ -161,6 +162,7 @@
#VGA Console
default CONFIG_CONSOLE_VGA=1
default CONFIG_PCI_ROM_RUN=1
+default CONFIG_VGA_ROM_RUN=1
# BTDC: Only one HT device on Herring.
#HT Unit ID offset
Index: src/mainboard/kontron/kt690/Config.lb
===
--- src/mainboard/kontron/kt690/Config.lb (revision 4782)
+++ src/mainboard/kontron/kt690/Config.lb (working copy)
@@ -136,7 +136,6 @@
#The variables belong to mainboard are defined here.
#Define gpp_configuration, A=0, B=1, C=2, D=3, E=4(default)
-#Define vga_rom_address = 0xfff
#Define port_enable, (bit map): GFX(2,3), GPP(4,5,6,7)
#Define gfx_dev2_dev3, 0: a link will never be established on Dev2 or
Dev3,
# 1: the system allows a PCIE
link to be established on Dev2 or Dev3.
@@ -170,7 +169,6 @@
device pci 6.0 on end # PCIE P2P
bridge 0x7916
device pci 7.0 on end # PCIE P2P
bridge 0x7917
device pci 8.0 off end # NB/SB
Link P2P bridge
- register "vga_rom_address" =
"0xfff0"
register "gpp_configuration" =
"4"
register "port_enable" = "0xfc"
register "gfx_dev2_dev3" = "1"
Index: src/mainboard/kontron/kt690/devicetree.cb
===
--- src/mainboard/kontron/kt690/devicetree.cb (revision 4782)
+++ src/mainboard/kontron/kt690/devicetree.cb (working copy)
@@ -1,5 +1,4 @@
#Define gpp_configuration, A=0, B=1, C=2, D=3, E=4(default)
-#Define vga_rom_address = 0xfff
#Define port_enable, (bit map): GFX(2,3), GPP(4,5,6,7)
#Define gfx_dev2_dev3, 0: a link will never be established on Dev2 or
Dev3,
# 1: the system allows a PCIE
link to be established on Dev2 or Dev3.
@@ -33,7 +32,6 @@
device pci 6.0 on end # PCIE P2P
bridge 0x7916
device pci 7.0 on end # PCIE P2P
bridge 0x7917
device pci 8.0 off end # NB/SB
Link P2P bridge
- register "vga_rom_address" =
"0xfff0"
register "gpp_configuration" =
"4"
register "port_enable" = "0xfc"
register "gfx_dev2_dev3" = "1"
Index: src/mainboard/technexion/tim8690/Options.lb
===
--- src/mainboard/technexion/tim8690/Options.lb (revision 4782)
+++ src/mainboard/technexion/tim8690/Options.lb (working copy)
@@ -90,6 +90,7 @@
uses CONFIG_VIDEO_MB
uses CONFIG_GFXUMA
uses CONFIG_HAVE_
Re: [coreboot] The filo crashes if the filo and coreboot overlap.
In relocate_segment(). If the coreboot and filo overlap, it will "slice off" a piece at the beginning or end. A new segment is allocated. If it is inserted before the "seg" that is being processed, is there any chance that the "new" segment will be processed? I am confused about it. On my fam 10 board, it seems that the "new" segment was not processed and an error happens when the code jumps to filo which is actually middle of nowhere. Zheng -Original Message- From: coreboot-bounces+zheng.bao=amd@coreboot.org [mailto:coreboot-bounces+zheng.bao=amd@coreboot.org] On Behalf Of Patrick Georgi Sent: Sunday, November 01, 2009 12:13 AM To: Zheng Bao Cc: coreboot@coreboot.org Subject: Re: [coreboot] The filo crashes if the filo and coreboot overlap. Am Samstag, den 31.10.2009, 15:43 + schrieb Zheng Bao: > The filo crashes if the filo and coreboot overlap. > Since the CBFS is the must-have feature, my family 10 > board crashes when it jumps to filo. I am trying to > find out why. I need help. > Based on current code, the AMD Family 10 will cause the filo > and coreboot overlap in RAM. The overlaps_coreboot() in selfboot.c > will return 1. But I am not sure if it will make the system > crashes. What revision is that? There was an issue like that but I fixed it several weeks ago. > If anybody explains briefly what happens if they > overlap. When coreboot and payload overlap, coreboot uses a bounce buffer. The bounce buffer is twice the size of coreboot. The first half is for the part of the payload that overlaps coreboot, the other half is for coreboot itself. The SELF loader loads data that would overlap coreboot to the bounce buffer, and jumps into jmp_to_elf_entry when it's done with loading. The jmp_to_elf_entry function copies coreboot to the upper half of the bounce buffer, and jumps in there, so the code is out of the way. Then it copies the lower half to the coreboot area and jumps to the entry point. There are some complications to that because of the decompression routine, so the code is not as nice as it should be. But I specifically tested your scenario (payload from 1mb to 2.3mb or so, coreboot starting at 2mb) > The coreboot information: > CONFIG_RAMBASE=0x0020 Try changing that to 0x10. Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
