[coreboot] F2A85-M coreboot not working

[Scott Duplichan]

Rostislav Lisovy [mailto:lisovy at gmail.com] wrote:

]On Sun, 2014-03-02 at 00:00 -0600, Scott Duplichan wrote:
]> This looks like a divide exception. Finding the source code
]> for the failing divide might help narrow down the problem. I
]> can't recreate your binary exactly so I can't find the failing
]> instruction from the eip value. But based on register values,
]> it looks like it is somewhere around line 334 of file
]> amd/agesa/f15tn/Proc/GNB/Modules/GnbInitTN/GfxGmcInitTN.c
]> You might be able to use the link map, disassembly, or debug
]> prints to figure out the exact source line that is failing.
]
]I compiled the GDB support and connected to it from the other computer.
]The outcome of the debugging:
]
]_text () at src/arch/x86/lib/c_start.S:89
]warning: Source file is more recent than executable.
]89		call	main
](gdb) c
]Continuing.
]
]Program received signal SIGFPE, Arithmetic exception.
]0x0022fabf in GfxGmcInitializeSequencerTN (Gfx=0x10000660) at
]src/vendorcode/amd/agesa/f15tn/Proc/GNB/Modules/GnbInitTN/GfxGmcInitTN.c:334
]warning: Source file is more recent than executable.
]334	  scale_mp0 = (GfxLibGetMaxSclk (GnbLibGetHeader (Gfx)) * 100) / memps0_freq;
]
](gdb) p memps0_freq
]$1 = 0
]
](gdb) p Gfx
]$2 = (GFX_PLATFORM_CONFIG *) 0x10000660
]
](gdb) l
]329	  }
]330	
]331	  //scale_mp0 = sclk_max_freq / memps0_freq
]332	  //scale_mp1 = sclk_max_freq / memps1_freq
]333	  //Multiply it by 100 to avoid dealing with floating point values
]334	  scale_mp0 = (GfxLibGetMaxSclk (GnbLibGetHeader (Gfx)) * 100) / memps0_freq;
]335	  scale_mp1 = (GfxLibGetMaxSclk (GnbLibGetHeader (Gfx)) * 100) / memps1_freq;
]336	
]337	  GnbRegisterReadTN (TYPE_GMM , 0x2774 , &ex1047.Value, 0, GnbLibGetHeader (Gfx));
]338	  GnbRegisterReadTN (TYPE_GMM , 0x2778 , &ex1048.Value, 0, GnbLibGetHeader (Gfx));
]
](gdb) p memps1_freq
]$5 = 333

It is good to see you have a debugger working. That confirms the problem
really is line 334. You dumped memps1_freq, but line 334 divides by
memps0_freq. Presumable memps0_freq is zero. If the failing instruction 
is "div esi", then memps0_freq=0 is confirmed by your original email that
shows value 0 in the esi register.

Apparently something is going wrong with the code a few lines above
that initializes memps0_freq. You could step through that code and try
to understand the problem. You could also try forcing a non-zero value
such as 333 into memps0_freq to see how much farther execution gets.
Thanks,
Scott

]Regards;
]Rostislav Lisovy



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