[Pdbg] [PATCH v2 13/15] main: Convert getcfam/putcfam to use path based targeting
alistair at popple.id.au
Thu Nov 15 15:49:35 AEDT 2018
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
> 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?).
More information about the Pdbg