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