Re: [coreboot] How to make graphical issue go away with 4GB of ram

[Kyösti Mälkki]

On Sat, 2012-06-30 at 23:47 +0200, Denis 'GNUtoo' Carikli wrote:
  On Sat, 2012-06-30 at 12:44 -0600, Marc Jones wrote:
  On Sat, Jun 30, 2012 at 12:01 PM, Kyösti Mälkki
<kyosti.malkki(a)gmail.com> wrote:
  On Sat, 2012-06-30 at 18:18 +0200, Denis
'GNUtoo' Carikli wrote:
  Hi,

 me and Kyösti Mälkki(kmalkki on IRC) figured out how to workarround the
 following problem:
 If I installed 4GB of ram in the m4a785t-m the screen comes up,however
 it's black.
 If I only installed 2GB of ram it worked fine.

 I made a patch(I'll send it right after that email) but it seem to break
 graphics for the case where 2GB of ram is installed.

 So I wonder what would be the correct fix(a fix that would work for
 every cases).

 Explanation of the patch that will be sent right after the mail:
 "basek - mmio_basek;" should be 1048576 (1G):
 According to Kyösti Mälkki the correct value for the sizek is 1048576.
 So I looked for what could create that size and found that.
 I'm not convinced that "basek - mmio_basek" is the right fix but at
 least we're in the right direction.
 My explanation of the issue: uma_memory_size must reduce the size of the
 last RAM resource _below_ 4GB. It now touches the last RAM resource,
 even if located over 4GB.
 
 Yes, The UMA graphics memory is allocated in the lower 4GB. I think
 that should be happening in mainboard.c. See the AMD reference
 platforms.
 Do you mean the following:
 
 #if CONFIG_GFXUMA
 uint64_t uma_memory_base, uma_memory_size;
 #endif
 
 int add_mainboard_resources(struct lb_memory *mem)
 {
 #if CONFIG_GFXUMA
         lb_add_memory_range(mem, LB_MEM_RESERVED,
                 uma_memory_base, uma_memory_size);
 #endif
         return 0;
 }
 
 With the addition of "select HAVE_MAINBOARD_RESOURCES" in Kconfig ?
 
 if so I already tried that change alone(without other changes) and it
 didn't work, I don't remember what it did exactly tough, I can retry if
 needed.
 
 Denis.
Marc,

the only problem I identified was in the coreboot memory table. In this
table, the last RAM resource located over 4G was truncated by UMA
framebuffer size. I saw similar (not identical) code for Agesa.

I believe Denis first reported the X screen fixed once he reduced the
size of the last RAM resource below 4G.


Denis,

Can you post logs of both a broken and working 4G setup? It will make
discussing this easier if we can reference the same memory tables.

Kyösti