[coreboot] Asus M2V-MX memory init
David Hillman
hillmands at gmail.com
Thu Feb 23 18:58:38 CET 2012
Thanks for the quick reply. My experience with Coreboot is very limited; I started playing with the code a few weeks ago. As far as getting this particular board going, I started with the code from the Asus M2V-MX_SE (different SuperIO, mainly). Then, I changed info in devicetree.cb, romstage.c, mainboard.c and Kconfig files as needed.
"what is 12.0?"
It is listed as VIA LAN in devicetree.cb. I turned it off because M2V-MX has separate Realtek chip. I don't know why it is still there.
What do fn_ctrl_lo and fn_ctrl_hi in devicetree.cb do? I don't really understand them, so I left them alone.
It seems devicetree.cb needs to be looked at. I will investigate more to get a better understanding.
coreboot-request at coreboot.org wrote:
Send coreboot mailing list submissions to
coreboot at coreboot.org
To subscribe or unsubscribe via the World Wide Web, visit
http://www.coreboot.org/mailman/listinfo/coreboot
or, via email, send a message with subject or body 'help' to
coreboot-request at coreboot.org
You can reach the person managing the list at
coreboot-owner at coreboot.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of coreboot digest..."
Today's Topics:
1. Re: Asus M2V-MX memory init (Peter Stuge)
2. Re: flash-chip (and compatibles) (Oliver Schinagl)
3. Patch merged into coreboot/master: 3d3abb2 Remove old AMD
fam10 fixme comment (gerrit at coreboot.org)
4. Re: Coreboot support for ASUS M5 A99X EVO ? (Bernhard Urban)
----------------------------------------------------------------------
Message: 1
Date: Wed, 22 Feb 2012 04:40:06 +0100
From: Peter Stuge <peter at stuge.se>
To: coreboot at coreboot.org
Subject: Re: [coreboot] Asus M2V-MX memory init
Message-ID: <20120222034006.29372.qmail at stuge.se>
Content-Type: text/plain; charset=us-ascii
David Hillman wrote:
> It looks like I am missing something to properly initialize memory
> to get correct SPD info. Maybe SMBUS isn't working properly?
I think SMBUS is OK and memory init too. Here's the diff between your
two logs with some comments, but there may be more relevant stuff
than what I see.
Next time when posting logs please make sure that they do not wrap.
One good way is to send them as attachments, under all circumstances
with text/plain mime type.
--- m2v_mx-2g 2012-02-22 04:13:21.309138502 +0100
+++ m2v_mx-4g 2012-02-22 04:13:02.663139149 +0100
@@ -1,4 +1,4 @@
-coreboot-4.0-2000-g91be49b-dirty Mon Feb 20 22:44:53 EST 2012 starting...
+coreboot-4.0-2000-g91be49b-dirty Wed Feb 15 22:11:37 EST 2012 starting...
now booting...
Enabling routing table for node 00 done.
Enabling UP settings
@@ -47,16 +47,21 @@
sdram_set_spd_registers: paramx :000ceee8
Device error
Device error
-Device error
+Enabling dual channel memory
Unbuffered
400MHz
400MHz
Interleaved
-RAM end at 0x00200000 kB
+RAM end at 0x00400000 kB
Ram3
IN TEST WAKEUP
800Initializing memory: done
Setting variable MTRR 2, base: 0MB, range: 2048MB, type WB
+Setting variable MTRR 3, base: 2048MB, range: 1024MB, type WB
+Setting variable MTRR 4, base: 3072MB, range: 512MB, type WB
+Setting variable MTRR 5, base: 3584MB, range: 256MB, type WB
+Setting variable MTRR 6, base: 3840MB, range: 128MB, type WB
+Setting variable MTRR 7, base: 3968MB, range: 64MB, type WB
DQS Training:RcvrEn:Pass1: 00
CTLRMaxDelay=1d
done
@@ -68,41 +73,45 @@
TrainDQSPos: MutualCSPassW[48] :000ce828
TrainDQSPos: MutualCSPassW[48] :000ce828
TrainDQSPos: MutualCSPassW[48] :000ce828
+TrainDQSPos: MutualCSPassW[48] :000ce828
+TrainDQSPos: MutualCSPassW[48] :000ce828
+TrainDQSPos: MutualCSPassW[48] :000ce828
+TrainDQSPos: MutualCSPassW[48] :000ce828
done
DQS Training:RcvrEn:Pass2: 00
- CTLRMaxDelay=43
+ CTLRMaxDelay=34
done
DQS SAVE NVRAM: c2000
Writing 113222 of size 4 to nvram pos: 0
-Writing 17161515 of size 4 to nvram pos: 4
+Writing 17151515 of size 4 to nvram pos: 4
Writing 17171615 of size 4 to nvram pos: 8
Writing 15 of size 1 to nvram pos: 12
Writing 202520 of size 4 to nvram pos: 13
-Writing 17171918 of size 4 to nvram pos: 17
-Writing 17191718 of size 4 to nvram pos: 21
+Writing 18171819 of size 4 to nvram pos: 17
+Writing 18181718 of size 4 to nvram pos: 21
Writing 17 of size 1 to nvram pos: 25
-Writing 33 of size 1 to nvram pos: 26
+Writing 32 of size 1 to nvram pos: 26
Writing 0 of size 1 to nvram pos: 27
Writing 0 of size 1 to nvram pos: 28
Writing 0 of size 1 to nvram pos: 29
-Writing 111222 of size 4 to nvram pos: 30
-Writing 0 of size 4 to nvram pos: 34
-Writing 0 of size 4 to nvram pos: 38
-Writing 0 of size 1 to nvram pos: 42
-Writing 0 of size 4 to nvram pos: 43
-Writing 2f2f2f2f of size 4 to nvram pos: 47
-Writing 2f2f2f2f of size 4 to nvram pos: 51
-Writing 0 of size 1 to nvram pos: 55
-Writing 43 of size 1 to nvram pos: 56
+Writing 113222 of size 4 to nvram pos: 30
+Writing 15141615 of size 4 to nvram pos: 34
+Writing 15141515 of size 4 to nvram pos: 38
+Writing 15 of size 1 to nvram pos: 42
+Writing 202520 of size 4 to nvram pos: 43
+Writing 17191818 of size 4 to nvram pos: 47
+Writing 18191716 of size 4 to nvram pos: 51
+Writing 16 of size 1 to nvram pos: 55
+Writing 34 of size 1 to nvram pos: 56
Writing 0 of size 1 to nvram pos: 57
Writing 0 of size 1 to nvram pos: 58
Writing 0 of size 1 to nvram pos: 59
-Writing 741080ab of size 4 to nvram pos: 60
-DQS Training:tsc[00]=000000005eac6acb
-DQS Training:tsc[01]=000000006087914d
-DQS Training:tsc[02]=0000000060879156
-DQS Training:tsc[03]=00000000df309c2e
-DQS Training:tsc[04]=00000000f2a194b3
+Writing 7410809b of size 4 to nvram pos: 60
+DQS Training:tsc[00]=000000008cbdd63c
+DQS Training:tsc[01]=000000008f476e2e
+DQS Training:tsc[02]=000000008f476e37
+DQS Training:tsc[03]=000000015b152149
+DQS Training:tsc[04]=000000016daed79e
Ram4
v_esp=000cef28
testx = 5a5a5a5a
@@ -121,7 +130,7 @@
0x100000
Stage: done loading.
Jumping to image.
-coreboot-4.0-2000-g91be49b-dirty Mon Feb 20 22:44:53 EST 2012 booting...
+coreboot-4.0-2000-g91be49b-dirty Wed Feb 15 22:11:37 EST 2012 booting...
Enumerating buses...
Show all devs...Before device enumeration.
Root Device: enabled 1
@@ -147,7 +156,7 @@
PNP: 002e.8: enabled 0
PNP: 002e.9: enabled 0
PNP: 002e.a: enabled 0
-PCI: 00:12.0: enabled 0
+PCI: 00:12.0: enabled 1
Why is 12.0 enabled with 4G? What is 12.0?
PCI: 00:13.0: enabled 1
PCI: 00:13.1: enabled 1
PCI: 00:18.1: enabled 1
@@ -177,7 +186,7 @@
PNP: 002e.8: enabled 0
PNP: 002e.9: enabled 0
PNP: 002e.a: enabled 0
- PCI: 00:12.0: enabled 0
+ PCI: 00:12.0: enabled 1
PCI: 00:13.0: enabled 1
PCI: 00:13.1: enabled 1
PCI: 00:18.1: enabled 1
@@ -265,7 +274,7 @@
PCI: 00:00.2 [1106/2336] ops
PCI: 00:00.2 [1106/2336] enabled
PCI: 00:00.3 [1106/3336] ops
-K8M890: UMA base is 7e000000 size is 32 (MB)
+K8M890: UMA base is fa000000 size is 32 (MB)
VIA_X_3 device dump:
00: 06 11 36 33 06 00 00 02 00 00 00 06 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
@@ -275,7 +284,7 @@
50: 22 22 00 00 00 00 e4 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-80: ff ff ff 30 00 80 19 00 80 00 00 00 00 00 00 00
+80: ff ff ff 30 00 fc 19 00 fc 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 80 00 00 00 00 3f 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
@@ -363,7 +372,7 @@
d0: 50 00 00 00 02 00 00 00 00 00 00 00 08 00 02 a8
e0: 00 0b 01 9a f8 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 06 00 00 00 00 00 00 00 00 00 00 00 00
-PCI: 00:03.0 PCIe link up after 15000 us
+PCI: 00:03.0 PCIe link up after 15100 us
00: 06 11 38 c2 00 00 10 00 00 00 04 06 00 00 01 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 f0 00 00 00
20: f0 ff 00 00 f1 ff 01 00 00 00 00 00 00 00 00 00
@@ -399,6 +408,7 @@
PCI: 00:11.0 [1106/3337] enabled
PCI: 00:11.7 [1106/287e] ops
PCI: 00:11.7 [1106/287e] enabled
+PCI: Static device PCI: 00:12.0 not found, disabling it.
Capability: type 0x08 @ 0x60
Capability: type 0x0d @ 0x70
Capability: type 0x08 @ 0x60
@@ -978,10 +988,10 @@
PCI: 00:13.1 allocate_resources_mem: next_base: febfffff size: 0 align: 20
gran: 20 done
Root Device assign_resources, bus 0 link: 0
-node 0 : uma_memory_base/1024=0x001f8000, mmio_basek=0x00300000,
-basek=0x00000300, limitk=0x00200000
-node 0: UMA memory starts below mmio_basek
-0: mmio_basek=00300000, basek=00000300, limitk=00200000
+node 0 : uma_memory_base/1024=0x003e8000, mmio_basek=0x00300000,
+basek=0x00000300, limitk=0x00400000
+ split: 1088K table at =f9ef0000
+0: mmio_basek=00300000, basek=00300000, limitk=00400000
Adding UMA memory area
PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0
amdk8_set_resource, enabling legacy VGA IO forwarding for PCI: 00:18.0 link
@@ -1114,9 +1124,11 @@
limit febfffff flags 40040200 index 10000100
PCI_DOMAIN: 0000 resource base 0 size a0000 align 0 gran 0 limit 0 flags e0004200 index 10
- PCI_DOMAIN: 0000 resource base c0000 size 7df40000 align 0 gran 0 limit 0
+ PCI_DOMAIN: 0000 resource base c0000 size bff40000 align 0 gran 0 limit 0 flags e0004200 index 20
- PCI_DOMAIN: 0000 resource base 7e000000 size 2000000 align 0 gran 0 limit
+ PCI_DOMAIN: 0000 resource base c0000000 size 3fffe000000 align 0 gran 0 limit 0 flags e0004200 index 30
+ PCI_DOMAIN: 0000 resource base fa000000 size 2000000 align 0 gran 0 limit 0 flags f0000200 index 7
The size for the c0000000 domain is crazy. This is worth looking into
further. I did some manual line unwrapping above. The email had extra
line endings damaging the log messages. It will be easier for you if
you fix that.
PCI: 00:18.0 child on link 0 PCI: 00:00.0
PCI: 00:18.0 resource base 1000 size 2000 align 12 gran 12 limit ffff
@@ -1368,7 +1380,9 @@
DONE fixed MTRRs
Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB
ADDRESS_MASK_HIGH=0xff
-Setting variable MTRR 1, base: 2016MB, range: 32MB, type UC
+Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB
+ADDRESS_MASK_HIGH=0xff
+Setting variable MTRR 2, base: 4000MB, range: 32MB, type UC
Find out why the 32 MB framebuffer ends at TOM on 2GB, but ends at
TOM-64MB on 4GB, what the top 64MB is for. Hopefully PCI resources
but 64MB is unexpectedly small for that. Investigate.
ADDRESS_MASK_HIGH=0xff
DONE variable MTRRs
Clear out the extra MTRR's
@@ -1493,7 +1507,7 @@
60: 00 00 00 00 00 00 00 04 80 00 d0 fe 80 00 00 00
70: 43 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 20 84 49 00 b2 30 00 00 01 05 00 00 05 18 00 00
-90: 00 06 19 88 a0 cc 00 00 00 3a 00 00 00 00 00 00
+90: 00 04 99 88 a0 cc 00 02 00 3a 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
@@ -1506,7 +1520,7 @@
20: 00 00 00 00 00 00 00 00 00 00 00 00 06 11 7e 33
30: 00 00 00 00 58 00 00 00 00 00 00 00 00 00 00 00
40: f4 24 00 80 82 00 00 00 23 3b 88 80 82 44 00 43
-50: 00 03 33 03 00 04 01 80 08 00 01 80 00 00 00 00
+50: 00 03 33 03 00 04 01 fc 08 00 01 80 00 00 00 00
60: 00 ff ff 30 30 00 00 00 00 00 00 00 00 00 00 00
70: c2 c8 ee 01 3c 0f 50 48 01 00 00 00 77 00 00 12
80: 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
@@ -1605,14 +1619,14 @@
PCI: 03:00.0: enabled 1
PCI: 04:01.0: enabled 1
cbmem_initialize: acpi_slp_type=0
-Initializing CBMEM area to 0x7def0000 (1114112 bytes)
-Adding CBMEM entry as no. 1
-Moving GDT to 7def0200...ok
-High Tables Base is 7def0000.
-Adding CBMEM entry as no. 2
-ACPI: Writing ACPI tables at 7def0400...
+Initializing CBMEM area to 0xf9ef0000 (1114112 bytes)
+ERROR: CBMEM was not initialized yet.
+Error: Could not relocate GDT.
+High Tables Base is f9ef0000.
+ERROR: CBMEM was not initialized yet.
This is very bad. Investigate. The CBMEM code should be easy to
follow.
+ACPI: Writing ACPI tables at f0000...
ACPI: * FACS
-ACPI: * DSDT @ 7def0540 Length ba5
+ACPI: * DSDT @ 000f0140 Length ba5
So with 2GB ACPI tables are written high, with 4GB because CBMEM
fails they end up in F-segment.
ACPI: * FADT
ACPI: added table 1/32, length now 40
ACPI: * HPET
@@ -1626,7 +1640,9 @@
set_srat_mem: dev PCI_DOMAIN: 0000, res->index=0010 startk=00000000,
sizek=00000280
-set_srat_mem: dev PCI_DOMAIN: 0000, res->index=0020 startk=00000300, sizek=001f7d00
+set_srat_mem: dev PCI_DOMAIN: 0000, res->index=0020 startk=00000300, sizek=002ffd00
+set_srat_mem: dev PCI_DOMAIN: 0000, res->index=0030 startk=00300000, sizek=ffff8000
At least the last one is bogus.
ACPI: added table 5/32, length now 56
ACPI: * SLIT
ACPI: added table 6/32, length now 60
@@ -1645,9 +1661,8 @@
1100mv Pstate_power[4] = 169141mw
ACPI: added table 7/32, length now 64
ACPI: done.
-ACPI tables: 4677 bytes.
-Adding CBMEM entry as no. 3
-smbios_write_tables: 7defb800
+ERROR: CBMEM was not initialized yet.
+smbios_write_tables: 000f1400
Root Device (ASUS M2V-MX Mainboard)
APIC_CLUSTER: 0 (AMD K8 Root Complex)
APIC: 00 (Socket AM2 CPU)
@@ -1697,36 +1712,37 @@
PCI: 01:00.0 ()
PCI: 03:00.0 ()
PCI: 04:01.0 ()
-SMBIOS tables: 277 bytes.
-Adding CBMEM entry as no. 4
+SMBIOS size 277 bytes
+ERROR: CBMEM was not initialized yet.
Writing high table forward entry at 0x00000500
-Wrote coreboot table at: 00000500 - 00000518 checksum c1ee
+Wrote coreboot table at: 00000500 - 00000518 checksum eaaf
New low_table_end: 0x00000518
-Now going to write high coreboot table at 0x7defc000
-rom_table_end = 0x7defc000
+Now going to write high coreboot table at 0x000f1520
+rom_table_end = 0x000f1520
Adjust low_table_end from 0x00000518 to 0x00001000
-Adjust rom_table_end from 0x7defc000 to 0x7df00000
+Adjust rom_table_end from 0x000f1520 to 0x00100000
Adding high table area
coreboot memory table:
0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES
1. 0000000000001000-000000000009ffff: RAM
- 2. 00000000000c0000-000000007deeffff: RAM
- 3. 000000007def0000-000000007dffffff: CONFIGURATION TABLES
- 4. 000000007e000000-000000007fffffff: RESERVED
- 5. 00000000e0000000-00000000efffffff: RESERVED
- 6. 00000000fec00000-00000000fec000ff: RESERVED
- 7. 00000000fecc0000-00000000fecc00ff: RESERVED
- 8. 00000000ff000000-00000000ffffffff: RESERVED
-Wrote coreboot table at: 7defc000 - 7defc214 checksum 336b
-coreboot table: 532 bytes.
-Adding CBMEM entry as no. 5
+ 2. 00000000000c0000-00000000000effff: RAM
+ 3. 00000000000f0000-00000000000fffff: CONFIGURATION TABLES
+ 4. 0000000000100000-00000000bfffffff: RAM
+ 5. 00000000c0000000-00000000dfffffff: RAM
+ 6. 00000000e0000000-00000000efffffff: RESERVED
+ 7. 00000000f0000000-00000000f9eeffff: RAM
+ 8. 00000000f9ef0000-00000000f9ffffff: CONFIGURATION TABLES
+ 9. 00000000fa000000-00000000fbffffff: RESERVED
+10. 00000000fc000000-00000000febfffff: RAM
+11. 00000000fec00000-00000000fec000ff: RESERVED
+12. 00000000fec00100-00000000fecbffff: RAM
+13. 00000000fecc0000-00000000fecc00ff: RESERVED
+14. 00000000fecc0100-00000000feffffff: RAM
+15. 00000000ff000000-00000000ffffffff: RESERVED
+16. 0000000100000000-00000400bdffffff: RAM
Here, coreboot says that you have almost 4 TB of RAM. Investigate.
+Wrote coreboot table at: 000f1520 - 000f17d4 checksum f32e
+ERROR: CBMEM was not initialized yet.
Multiboot Information structure has been written.
- 0. FREE SPACE 7dffe000 00002000
- 1. GDT 7def0200 00000200
- 2. ACPI 7def0400 0000b400
- 3. SMBIOS 7defb800 00000800
- 4. COREBOOT 7defc000 00002000
- 5. ACPI RESUME7defe000 00100000
Searching for fallback/payload
Check cmos_layout.bin
Check pci1106,3230.rom
@@ -1737,26 +1753,30 @@
Loading segment from rom address 0xfffad538
data (compression=1)
- New segment dstaddr 0xe6b54 memsize 0x194ac srcaddr 0xfffad570 filesize 0xc8aa
- (cleaned up) New segment addr 0xe6b54 size 0x194ac offset 0xfffad570 filesize 0xc8aa
+ New segment dstaddr 0xe6b54 memsize 0x194ac srcaddr 0xfffad570 filesize 0xc8ba
+ (cleaned up) New segment addr 0xe6b54 size 0x194ac offset 0xfffad570 filesize 0xc8ba
Loading segment from rom address 0xfffad554
Entry Point 0x00000000
-Loading Segment: addr: 0x00000000000e6b54 memsz: 0x00000000000194ac filesz:
-0x000000000000c8aa
-lb: [0x0000000000100000, 0x0000000000198000)
-Post relocation: addr: 0x00000000000e6b54 memsz: 0x00000000000194ac filesz:
-0x000000000000c8aa
-using LZMA
-[ 0x000e6b54, 00100000, 0x00100000) <- fffad570
-dest 000e6b54, end 00100000, bouncebuffer 7ddc0000
-Loaded segments
-Jumping to boot code at fc8e4
-entry = 0x000fc8e4
-lb_start = 0x00100000
-lb_size = 0x00098000
-adjust = 0x7dd58000
-buffer = 0x7ddc0000
- elf_boot_notes = 0x001270c8
-adjusted_boot_notes = 0x7de7f0c8
-Start bios (version 1.6.3-20120215_224505-debby)
+No matching ram area found for range:
+ [0x00000000000e6b54, 0x0000000000100000)
And finally instead of the "Start bios" message from SeaBIOS it's not
possible to load the payload to it's address, because..
+Ram areas
+ [0x0000000000000000, 0x0000000000001000) Reserved
+ [0x0000000000001000, 0x00000000000a0000) RAM
+ [0x00000000000c0000, 0x00000000000f0000) RAM
+ [0x00000000000f0000, 0x0000000000100000) Reserved
..the F segment has been marked reserved, because this is where the
ACPI tables were written to, because the highmem address was not
available, because CBMEM failed to initialize.
The error isn't really with hardware init I believe, but with
calculation, generation and preparation of system description data
for the payload and later the operating system. You need to find out
why coreboot gets upset with 4G of memory.
//Peter
------------------------------
Message: 2
Date: Wed, 22 Feb 2012 10:35:54 +0100
From: Oliver Schinagl <oliver at schinagl.nl>
To: coreboot at coreboot.org
Subject: Re: [coreboot] flash-chip (and compatibles)
Message-ID: <4F44B6FA.8070509 at schinagl.nl>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Having trouble ordering from several webshops in Europe (The only want
to send you parts if you order in huge quantities or if you are a
company) I've found the following at digikey in the US.
http://search.digikey.com/nl/en/products/SST25VF032B-80-4I-S2AF/SST25VF032B-80-4I-S2AF-ND/2297800
http://search.digikey.com/nl/en/products/W25Q64FVSSIG/W25Q64FVSSIG-ND/2815931
I know they are 8-SOIC but have ordered (and received) 8-SOIC -> 8-DIP
pcb's so can easily convert between the sockets. I guess these should
work just fine?
On 16-02-12 02:44, Peter Stuge wrote:
> Oliver Schinagl wrote:
>> I was pointed to this one: A25L032-F
>> http://nl.farnell.com/amic/a25l032-f/memory-flash-spi-32m-8dip/dp/1907085
>>
>> (There's also a Q version, which I don't think is what I'd want).
> Correct. Q is a WSON package which does not fit at all. Make sure you
> buy farnell nr. 1907085 and nothing else. A25L032-F is indeed the
> accurate manufacturer's part number, if you order somewhere else.
>
>
>> I haven't found a 64Mbit chip yet, so I hope I could use a linux
>> kernel as payload using a 4MB one (the current 32Mbit)
> Winbond W25Q64CV
>
> But Winbond's distributors AVNET and Digi-Key,
>
> http://www.winbond-usa.com/winbondcms/Application/member/Distributors.aspx?partno=W25Q64CV
>
> only have SO-8 in stock, and you wanted DIP. You could look for
> adapters, but then you must do some soldering.
>
> http://search.digikey.com/scripts/DkSearch/dksus.dll?site=us&lang=en&v=256&WT.z_supplier_id=256&WT.z_page_type=SP&WT.z_page_sub_type=SS&WT.z_oss_type=View+All&chp=0
>
> AVNET only have SO-8 stock in Asia. You'll have to pay import fees
> and tax. Digi-Keys f-ing website barfs some idiotic error at me
> whenever I try to use it nowadays.
>
>
> You can buy DIP from bios-repair.co.uk, but they only have the older
> revision W25Q64BVAIG. For once they don't charge more than AVNET&co
> in single quantity.
>
> http://bios-repair.co.uk/Products/EEPROM/SPI-SerialFlash-EEPROM.html
>
> Click Winbond, then there's W25Q64BVAIG 64Mb PDIP top left in the
> product listing.
>
>
> //Peter
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20120222/fbfcab14/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 22 Feb 2012 11:35:19 +0100
From: gerrit at coreboot.org
To: coreboot at coreboot.org
Subject: [coreboot] Patch merged into coreboot/master: 3d3abb2 Remove
old AMD fam10 fixme comment
Message-ID: <E1S09Xb-0003x8-8w at ra.coresystems.de>
Content-Type: text/plain; charset="UTF-8"
the following patch was just integrated into master:
commit 3d3abb2e9ce3a175c9182b6bc3ad17bc3487735b
Author: Marc Jones <marc.jones at se-eng.com>
Date: Tue Feb 21 17:53:13 2012 -0700
Remove old AMD fam10 fixme comment
The family10 code had a very slow decompress before the cache settings were
fixed. This has been fixed for some time. Remove all the old messages from the
serial stream.
Change-Id: I476efe1a430f702af394734f354ff69bd053f1d2
Signed-off-by: Marc Jones <marc.jones at se-eng.com>
Reviewed-By: Patrick Georgi <patrick at georgi-clan.de> at Wed Feb 22 11:35:17 2012, giving +2
See http://review.coreboot.org/672 for details.
-gerrit
------------------------------
Message: 4
Date: Wed, 22 Feb 2012 12:51:38 +0100
From: Bernhard Urban <lewurm at gmail.com>
To: coreboot at coreboot.org
Cc: Chris Leaver <zeonglow at gmail.com>
Subject: Re: [coreboot] Coreboot support for ASUS M5 A99X EVO ?
Message-ID:
<CAAr_hs4iJ2ETxqWP4u9h0BzR8p9hHVMXgFJMHeqBbXFXeVp+ew at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
hi,
so finally, I spent some time on porting coreboot to the asus board
"m5a99x evo". http://www.asus.com/Motherboards/AMD_AM3Plus/M5A99X_EVO/
I was equipped with three DIP chips and decided to use my target
machine also for developing. I had also set up a quite complicated
configuration for serial debugging, as I didn't own a second machine
with a rs232 board. Although the first try (just flash the "m5a88-v"
configuration) showed some output :-) ( http://tinyurl.com/89a33m5 ),
the build cycle was a pain in the ass.
(0) building coreboot (takes some seconds...)
(1) flashing the chip (~30seconds, without verifying)
(2) reboot (~20sec)
(3) starting coreboot and analyse the output (between 1sec and some minutes ;-))
(4) switch chip with vendor bios on it (some seconds)
(5) booting vendor bios and linux (35sec + 11sec. yes, the vendor
firmware takes three times longer than linux + x11. BOAR ;-))
(6) switch chip again.
So I was looking for alternatives. I remembered the ft2232 stuff by
Uwe. I had it anyway on my "order it some day"-list, so it was the
right time ;-)
In the meanwhile, I refit my old machine with a new hdd and a
reasoneable graphic card. Luckily, it has also a serial port :-)
I was a bit afraid of building a programmer (the ft2232 thingy) as I'm
not really the hardware guy. However, the first dump was successful.
Writing was working too. I was impressed :-) Thanks to Uwe at this
point!
So the build cycle is more convenient now:
(0) building coreboot (takes longer than on my new machine, but it's okay ;-))
(1) flash the chip with the ft2232 thingy (~30 seconds, without verifying)
(2) put the chip onto the mainboard
(3) start machine and watch serial output
all in all, it take like one minute to test one build. nice!
So, now I was able to do some serious coreboot hacking. I started from
the "m5a88-v" port. What I did:
- Changed the southbridge from "SB800" to "SB900"
- Adapted some compile-breaks due to this change.
- hardcoded some pci device instead of locating it @ early.c -> ohai
ramstage :-)
- again, some pci related change/hack (aborting the enumeration
earlier). I didn't really understand what I did here, I just figured
out it hangs here (could be related with the quirk below). After that
-> OHAI SEABIOS!
I was very happy ;) However, SeaBIOS itself hang somewhere.
In the meanwhile, Kerry pushed RD890 patches, which seemed to be more
appropriate for my board (i used RS780 code so far, hence the ugly
hacks mentioned above I guess). So I used them, and it felt much
cleaner immediately. The payload was still loading -> nice.
After that, I investigated a bit what the problem is with SeaBIOS. At
this moment, it hanged after printing "Relocating init from 0x000e8450
to 0xcffd57a0 (size 42812)" (see http://tinyurl.com/78evzex ). I
looked into the SeaBIOS code and found out, that you can disable
relocation. So I did.
The result was a bit more confusing. http://tinyurl.com/7uh8xty
The output get distorted (which seems not to be deterministically,
http://tinyurl.com/6opakzl ) and something issues a soft reset (but
not everytime...). Eventually I gave up at this point (had to do other
stuff anyway). I guess it is something wrong with RAM initialization
as relocation in higher memory regions doesn't work. Also, the graphic
card isn't found on the pci bus as the RD890 code inlcudes a quirk
which "disable all pcie bridges" aka
`sr56x0_rd890_disable_pcie_bridge()'. According to `lspci' (with
vendor bios), the graphic card is on bus 1, so this seem reasonably.
@Kerry: is there some way to enable it again after "early"?
my WIP branch is available here (please tell me if you pull from it,
because atm I'm rebasing stuff on it and using `git push -f' to
overwrite it...):
http://wien.tomnetworks.com/gitweb/?p=coreboot.git;a=shortlog;h=refs/heads/WIP
full logs (including config and rom images) are available here:
http://wien.tomnetworks.com/gitweb/?p=cbimages.git;a=tree
Some questions:
- What does "CIMX" stands for? I grep'd my #coreboot logs for it. One
guy asked that already, but he didn't get an answer :-/
- What's the best/easiest way to verify if RAM init was successful?
- I think it would be nice to have an entry on the wiki page for this
board. How I get an account? Stefan? :-)
I appreciate any comment, I know resources are short :-(
anyways, it was fun and exciting so far :-) thanks!
regards,
bernhard
On Wed, Nov 23, 2011 at 10:29 PM, Bernhard Urban <lewurm at gmail.com> wrote:
> Hi Chris,
>
> I reported flashrom compatibility here:
> http://www.flashrom.org/pipermail/flashrom/2011-October/008152.html
>
> Regarding coreboot support: I'll try to port coreboot to this board. I
> already have two additional flashchips and at the moment I'm waiting
> for a serial port connector. I don't know how long it'll talke to port
> it, but don't except anything useful in less than three months, since
> I'm new to coreboot (and lazy :-))
>
>
> Bernhard
>
> On Sat, Nov 19, 2011 at 6:33 PM, Christopher Huang-Leaver
> <zeonglow at googlemail.com> wrote:
>> Hello,
>> I noticed earlier versions of this board are fully supported, but not this
>> one.
>> I have attached the output of, ?lspci, ?flashrom and dmidecode, if that is
>> any use to anyone.
>> The spec sheet is easy to find by typing ASUS M5 A99X into Google. ?The
>> board does have a neat feature of being able to flash the BIOS from within
>> the BIOS menu, which I have already used to update it.
>> Many thanks
>> Chris
------------------------------
_______________________________________________
coreboot mailing list
coreboot at coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
End of coreboot Digest, Vol 84, Issue 68
****************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20120223/fc2e714a/attachment.html>
More information about the coreboot
mailing list