[U-Boot] suggest on how to convey value of 'CCSRBAR' to user on FSL PPC parts

[U-Boot] suggest on how to convey value of 'CCSRBAR' to user on FSL PPC parts

[Kumar Gala]

I had two ideas on simple ways to convey the value of CCSRBAR, IMMR,  
etc.. on various Freescale PPC SoCs.  Knowing the value is useful in  
debugging if you need to dump the register space.  I wanted to see if  
people had a preference or other ideas:

1. add it as output when we boot:

U-Boot 2009.08-rc1-00030-g56bdfa9 (Jul 30 2009 - 10:52:13)

CPU:   8536E, Version: 1.1, (0x803f0091)
Core:  E500, Version: 3.0, (0x80210030)
..
CCSRBAR: 0xfe000000

2. add it as a environment variable

ccsrbar=fe000000

I also thought about having it as a command but that seems like a lot  
of code w/o any real purpose.

- k

[U-Boot] suggest on how to convey value of 'CCSRBAR' to user on FSL PPC parts

[Wolfgang Denk]

Dear Kumar Gala,

In message <7ACC3970-1B73-4828-941C-48C6601A7F80@kernel.crashing.org> you wrote:
> I had two ideas on simple ways to convey the value of CCSRBAR, IMMR,  
> etc.. on various Freescale PPC SoCs.  Knowing the value is useful in  
> debugging if you need to dump the register space.  I wanted to see if  
> people had a preference or other ideas:
> 
> 1. add it as output when we boot:

This would be only acceptable when DEBUG is enabled, and even this
it's ugly.

> 2. add it as a environment variable
> 
> ccsrbar=fe000000

Please don't.

> I also thought about having it as a command but that seems like a lot  
> of code w/o any real purpose.

I don't understand what exactly you need it for.

The information should be part of struct bd_info for all relevant
architectures, and struct global_data holds a pointer to bd_info as
the first element, and on PowerPC R2 holds a pointer to the global
data.

So you can easily define a GDB macro to do something like this:

(gdb) print/x ((gd_t *)$r2)->bd->bi_immr_base

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"If you'll excuse me a minute, I'm going to have a cup of coffee."
- broadcast from Apollo 11's LEM, "Eagle", to Johnson  Space  Center,
Houston July 20, 1969, 7:27 P.M.

[U-Boot] suggest on how to convey value of 'CCSRBAR' to user on FSL PPC parts

[Kumar Gala]

On Aug 4, 2009, at 9:24 AM, Wolfgang Denk wrote:

> Dear Kumar Gala,
>
> In message  
> <7ACC3970-1B73-4828-941C-48C6601A7F80@kernel.crashing.org> you wrote:
>> I had two ideas on simple ways to convey the value of CCSRBAR, IMMR,
>> etc.. on various Freescale PPC SoCs.  Knowing the value is useful in
>> debugging if you need to dump the register space.  I wanted to see if
>> people had a preference or other ideas:
>>
>> 1. add it as output when we boot:
>
> This would be only acceptable when DEBUG is enabled, and even this
> it's ugly.
>
>> 2. add it as a environment variable
>>
>> ccsrbar=fe000000
>
> Please don't.
>
>> I also thought about having it as a command but that seems like a lot
>> of code w/o any real purpose.
>
> I don't understand what exactly you need it for.
>
> The information should be part of struct bd_info for all relevant
> architectures, and struct global_data holds a pointer to bd_info as
> the first element, and on PowerPC R2 holds a pointer to the global
> data.
>
> So you can easily define a GDB macro to do something like this:
>
> (gdb) print/x ((gd_t *)$r2)->bd->bi_immr_base

I didn't think about it being in the bd.  I can use 'bdinfo' to output  
its value.

- k

[U-Boot] suggest on how to convey value of 'CCSRBAR' to user on FSL PPC parts

[Peter Tyser]

On Tue, 2009-08-04 at 09:27 -0500, Kumar Gala wrote:
> On Aug 4, 2009, at 9:24 AM, Wolfgang Denk wrote:
> 
> > Dear Kumar Gala,
> >
> > In message  
> > <7ACC3970-1B73-4828-941C-48C6601A7F80@kernel.crashing.org> you wrote:
> >> I had two ideas on simple ways to convey the value of CCSRBAR, IMMR,
> >> etc.. on various Freescale PPC SoCs.  Knowing the value is useful in
> >> debugging if you need to dump the register space.  I wanted to see if
> >> people had a preference or other ideas:
> >>
> >> 1. add it as output when we boot:
> >
> > This would be only acceptable when DEBUG is enabled, and even this
> > it's ugly.
> >
> >> 2. add it as a environment variable
> >>
> >> ccsrbar=fe000000
> >
> > Please don't.
> >
> >> I also thought about having it as a command but that seems like a lot
> >> of code w/o any real purpose.
> >
> > I don't understand what exactly you need it for.
> >
> > The information should be part of struct bd_info for all relevant
> > architectures, and struct global_data holds a pointer to bd_info as
> > the first element, and on PowerPC R2 holds a pointer to the global
> > data.
> >
> > So you can easily define a GDB macro to do something like this:
> >
> > (gdb) print/x ((gd_t *)$r2)->bd->bi_immr_base
> 
> I didn't think about it being in the bd.  I can use 'bdinfo' to output  
> its value.

We'd toyed around with adding a "memmap" command which would display
chip select mappings, and/or tlb mappings.  I think lots of people
(especially end-users) would find this info useful as the same issue you
have with determining the CCSR address applies to other memory regions.

The bd_info structure has some of the same data that the memmap command
would show, but it doesn't have info such as bank width, cache
attributes, and only supports mem, NOR flash, CCSR, and SRAM.

Do others think such a command would be useful?

Best,
Peter

[U-Boot] suggest on how to convey value of 'CCSRBAR' to user on FSL PPC parts

[Kumar Gala]

On Aug 4, 2009, at 9:43 AM, Peter Tyser wrote:

>
> We'd toyed around with adding a "memmap" command which would display
> chip select mappings, and/or tlb mappings.  I think lots of people
> (especially end-users) would find this info useful as the same issue  
> you
> have with determining the CCSR address applies to other memory  
> regions.
>
> The bd_info structure has some of the same data that the memmap  
> command
> would show, but it doesn't have info such as bank width, cache
> attributes, and only supports mem, NOR flash, CCSR, and SRAM.
>
> Do others think such a command would be useful?

It would be useful, I would suggest possible looking at CMD_REGINFO.

- k