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 <[email protected]> > > 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 -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
