Re: [coreboot] cbmem console broken on Intel hardware since ec5e5e0

[Matt DeVillier]

On 4/20/2015 3:29 PM, Aaron Durbin wrote:
> On Mon, Apr 20, 2015 at 9:23 AM, Matt DeVillier
>  wrote:
> > On 4/20/2015 8:51 AM, Aaron Durbin wrote:
> > > On Fri, Apr 17, 2015 at 12:32 AM, Matt DeVillier
> > >  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'
> > > > regards,
> > > > Matt

cbmem console broken on Intel hardware since ec5e5e0

[Aaron Durbin]

On Mon, Apr 20, 2015 at 9:29 PM, Matt DeVillier
 wrote:
> On 4/20/2015 3:29 PM, Aaron Durbin wrote:
> > On Mon, Apr 20, 2015 at 9:23 AM, Matt DeVillier
> >  wrote:
> > > On 4/20/2015 8:51 AM, Aaron Durbin wrote:
> > > > On Fri, Apr 17, 2015 at 12:32 AM, Matt DeVillier
> > > >  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