On Tue, Apr 21, 2015 at 9:54 AM, Aaron Durbin adurbin@chromium.org wrote:
On Mon, Apr 20, 2015 at 9:29 PM, Matt DeVillier matt.devillier@gmail.com wrote:
On 4/20/2015 3:29 PM, Aaron Durbin wrote:
On Mon, Apr 20, 2015 at 9:23 AM, Matt DeVillier matt.devillier@gmail.com wrote:
On 4/20/2015 8:51 AM, Aaron Durbin wrote:
On Fri, Apr 17, 2015 at 12:32 AM, Matt DeVillier matt.devillier@gmail.com wrote:
Greetings! When building upstream master tonight, discovered that cbmem console output is broken for Intel hardware (testing on google/panther). With some help on IRC from kmalkki, was able to determine the culprit is commit ec5e5e0 (New mechanism to define SRAM/memory map with automatic bounds checking). I verified this via bisecting; the prior commit, 06ef046, functions normally.
Did this get fixed?
not as of yet (cdf92ea still has the issue)
Try this if you have time? I'm sure I haven't handled all the cases, but it my work for you.
applying this as a cherry-pick gives me garbage/binary output for 'cbmem -c'
Thanks, Matt. That was my first pass w/o any real checking on my end. I may have time to tinker on my end to see what I can work out. However, there's a fundamental problem w/ the code as checked in and that previous changes. cbmem was enabled all the time, but that code wasn't exactly used based on compile time options. However, there's not compile-time check anymore. The decision to use cbmem console in various stages have to be done at runtime now. That creates more work outside of just fixing your problem.
-Aaron
http://review.coreboot.org/9851 -- updated CL http://review.coreboot.org/9933 -- to address cbmem console missing large amounts of ramstage
-
Aaron Durbin