[Pdbg] [PATCH v2 13/15] main: Convert getcfam/putcfam to use path based targeting

[Alistair Popple]

On Thursday, 15 November 2018 3:31:07 PM AEDT Amitay Isaacs wrote:
> On Thu, 2018-11-15 at 15:13 +1100, Alistair Popple wrote:
> > On Wednesday, 14 November 2018 4:42:59 PM AEDT Amitay Isaacs wrote:
> > > On Tue, 2018-11-13 at 16:01 +1100, Alistair Popple wrote:
> > > > Hi Amitay,
> > > > 
> > > > >  test_result 0 <<EOF
> > > > > 
> > > > > -p0:0xc09 = HEX8
> > > > > +/kernelfsi at 0: 0xc09 = HEX8
> > > > 
> > > > We may have discussed this sorry if I'm changing my mind but can
> > > > we
> > > > keep the
> > > > output the same for the time being? ie. Something like ("p%d",
> > > > pdbg_target_index(fsi))?
> > > 
> > > Well the question is what targets we want for getcfam/putcfam?
> > 
> > I think just the root/top level fsi targets are fine for now. In
> > practice we
> > don't have any FSI children that would need translation atm.
> > 
> > > As per your thinking, if we want pib target to be selected for
> > > getcfam/putcfam commands, then the the existing output makes sense.
> > > In that case, the implementation should find the fsi target for
> > > selected pib target for actual operations.
> > 
> > I don't think we actually want the pib targets selected. I'm really
> > just
> > talking about the output formatting which it would be nice to keep
> > the same -
> > ie:
> > 
> > "p<chip index>:<addr> = <value>"
> 
> I find it a bit confusing since 'p' is used to indicate pib class (-p).
> It's also the same as processor (or chip).

It was actually meant to refer to processor rather than pib.

> For example, how do you do getcfam on second chip? (Does that even make
> sense?  Read more pdfs Amitay!)

Yes and yes (and feel free to ask the interactive pdf) :-)

Every processor/module is physically identical and therefore each has a CFAM 
(as do the memory buffers but lets ignore that for now ;). These CFAM are all 
mostly accesable (there are a few exceptions, notably when using i2c on P8 the 
primary CFAM can't be accessed)

Currently you would do `pdbg -p1 getcfam 0xc09` to get a cfam register on the 
second processor.

> If we need fsi target, then may be "-P fsi1" will work provided we have
> the second fsi target with correct index.  If there is no fsi target
> with index 1, then we might have to actually know the topology to
> select the right fsi target (e.g. "-P fsi/fsi").  In that how do we
> generate the output "p1: <addr> = <value>"?
> 
> It's more intuitive if we always use pib as a package/processor/chip.
> It's easier to either use "-p 1" or "-P pib1" for second processor/chip
> and then we can internally pick the "right" target to actually perform
> the fsi_read() operation.

For `pdbg -p1 getcfam` sure, all I'm really thinking is that we should keep 
the existing behaviour the same.

I am not so convinced `pdbg -P pib1 getcfam` should work. It would become 
difficult for example if we add all the cfam targets (such as SBE or memory 
buffer fsi/cfams). We should really just bail with an error in this case. I 
think the path needs to match what you're targetting - the existing shortcuts 
can be used for "magic" to select what the user really wants.

Ie. users can always stick to things like `-p1` to specify "getcfam blah on 
processor 1" if they want convenient shortcuts (or we can add other shortcuts 
if you think -p is not sufficient?).

- Alistair
 
> Amitay.