[coreboot] Asus M2A-VM (patch for this issue)

[Bao, Zheng]

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 <Zheng.bao at amd.com>

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-bounces at coreboot.org
[mailto:coreboot-bounces at 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-bounces at coreboot.org
[mailto:coreboot-bounces at 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 at coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot



--
coreboot mailing list: coreboot at coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

-------------- next part --------------
A non-text attachment was scrubbed...
Name: cb_table.patch
Type: application/octet-stream
Size: 2020 bytes
Desc: cb_table.patch
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081218/7a487e8b/attachment.obj>