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