Hi Mario, On 19 April 2018 at 01:50, Mario Six <mario....@gdsys.cc> wrote: > > Hi Simon, > > On Wed, Apr 18, 2018 at 5:45 PM, Simon Glass <s...@chromium.org> wrote: > > Hi Mario, > > > > On 18 April 2018 at 02:35, Mario Six <mario....@gdsys.cc> wrote: > >> Hi Simon, > >> > >> On Thu, Apr 12, 2018 at 6:37 PM, Simon Glass <s...@chromium.org> wrote: > >>> Hi Mario, > >>> > >>> On 11 April 2018 at 00:39, Mario Six <mario....@gdsys.cc> wrote: > >>>> Hi Simon, > >>>> > >>>> On Fri, Mar 30, 2018 at 10:41 AM, Simon Glass <s...@chromium.org> wrote: > >>>>> Hi, > >>>>> > >>>>> On 28 March 2018 at 20:38, Mario Six <mario....@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....@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
