[U-Boot] [PATCH 6/8] cpu: Add cpu_print_info function

[Simon Glass]

Hi Mario,

On 19 April 2018 at 01:50, Mario Six <mario.six at gdsys.cc> wrote:
>
> Hi Simon,
>
> On Wed, Apr 18, 2018 at 5:45 PM, Simon Glass <sjg at chromium.org> wrote:
> > Hi Mario,
> >
> > On 18 April 2018 at 02:35, Mario Six <mario.six at gdsys.cc> wrote:
> >> Hi Simon,
> >>
> >> On Thu, Apr 12, 2018 at 6:37 PM, Simon Glass <sjg at chromium.org> wrote:
> >>> Hi Mario,
> >>>
> >>> On 11 April 2018 at 00:39, Mario Six <mario.six at gdsys.cc> wrote:
> >>>> Hi Simon,
> >>>>
> >>>> On Fri, Mar 30, 2018 at 10:41 AM, Simon Glass <sjg at chromium.org> wrote:
> >>>>> Hi,
> >>>>>
> >>>>> On 28 March 2018 at 20:38, Mario Six <mario.six at gdsys.cc> wrote:
> >>>>>> Add a cpu_print_info function to the CPU uclass to emulate the behavior
> >>>>>> of some current non-DM drivers (e.g. MPC83xx) to print CPU information
> >>>>>> during startup.
> >>>>>>
> >>>>>> Signed-off-by: Mario Six <mario.six at gdsys.cc>
> >>>>>> ---
> >>>>>>  drivers/cpu/cpu-uclass.c | 10 ++++++++++
> >>>>>>  include/cpu.h            | 15 +++++++++++++++
> >>>>>>  2 files changed, 25 insertions(+)
> >>>>>>
> >>>>>
> >>>>> I really don't want drivers printing stuff. Can you use the existing
> >>>>> get_info() method?
> >>>>>
> >>>>
> >>>> I could, but I'm just emulating the behavior of the legacy code here, which
> >>>> prints some information when the CPU is initialized. I think that's pretty
> >>>> useful, and I can do that in our board file, but that would mean implementing
> >>>> the same routine in every MPC83xx board to get the legacy behavior back.
> >>>
> >>> Yes, but I don't want the legacy code creeping into the eclass. Can
> >>> you convert the board to use the CPU eclass instead?
> >>>
> >>
> >> That's what I did, and I just discovered DISPLAY_CPUINFO, which does exactly
> >> what is needed. I'll implement the print_cpuinfo function in the CPU driver, so
> >> I can get rid of the print function in the uclass (and still retain the
> >> information printing at bootup).
> >
> > OK I see. Ideally we would have a function (perhaps in board_f) which
> > prints out the CPU info after obtaining it from the uclass. So could
> > you move your print_cpuinfo() function into board_f? Would it be
> > possible to use that if CONFIG_CPU is defined?
> >
> > At some point print_cpuinfo() could be removed from various board files.
> >
>
> The function prints the following (example for our device):
>
> --- >8 ---
>
> Reset Status: External/Internal Soft, External/Internal Hard
>
> CPU:   e300c3, MPC8308, Rev: 1.1 at 400 MHz, CSB: 133.333 MHz
>
> --- >8 ---
>
> So there are some values that are very specific to the platform, such as the
> CSB (Coherent System Bus) frequency, or the reset status. While it's probably
> possible to put some of that into a generic info printing routine, lots of it
> is so MPC83xx-specific that it doesn't make much sense for other CPUs.

Well you get to provide a string from get_desc() so you can add
whatever you like!

>
> Any idea how to tackle this? I don't really want to get rid of the Reset Status
> printing especially, since it's pretty useful information for debugging devices
> in the field.

Re the reset status, shouldn't that come from the sysreset driver? I
wonder if we should add an API call for that? Or is it something
printed by the board?

Regards,
Simon