On Tue, Apr 21, 2015 at 9:54 AM, Aaron Durbin <[email protected]> wrote: > On Mon, Apr 20, 2015 at 9:29 PM, Matt DeVillier > <[email protected]> wrote: >> On 4/20/2015 3:29 PM, Aaron Durbin wrote: >>> On Mon, Apr 20, 2015 at 9:23 AM, Matt DeVillier >>> <[email protected]> wrote: >>>> On 4/20/2015 8:51 AM, Aaron Durbin wrote: >>>>> On Fri, Apr 17, 2015 at 12:32 AM, Matt DeVillier >>>>> <[email protected]> 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. >>> >>> http://review.coreboot.org/#/c/9851/ >> >> 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 -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
