[U-Boot-Users] DCR register read/write for PPC440EP

[Leonid]

On Thursday 28 September 2006 11:45 AM, Stefan wrote:
> > > What you really need, is an U-Boot command to set/get SDR
registers,
> > > indirectly accessed via the DCR 0x0e/0x0f registers. Something
> > > like "setsdr/getsdr".
> >
> > [Leonid] I thought rather of some generic function, allowing
indirect
> > access to DCR-related registers....

> > Something like that I guess:
> >
> > getidcr e f 0x40
> > setidcr e f 40 0xbadd
> >
> > where "i" in the middle stays for "indirect". What do you think?
>
> Good idea. Much more flexible this way. I'm just thinking, if we
really 
> need this 2nd argument for the "DCR data register", since all "DCR
data 
> registers" I found upon a quick look into on of the AMCC manuals, are 
> located at "DCR address register + 1". This way we would save one 
> parameter, but would loose some flexibility. Best would be, if you
made 
> the 2nd paramter optional:
> 
> getidcr e [f] 0x40
> setidcr e [f] 40 0xbadd
> 
> This way, you could decide upon the parameter count (argc), if the
"DCR 
> data register" is supplied or not. What do you think?
> 

I think it would be better to provide both address and data DCR register
numbers (DCRNs) in the first parameter, separated by "." or ":", like
this:

getidcr e.f 40

or simple (omitted data DCRN will be 0xE+1=0xF as you have suggested):

getidcr e 40

This is more "u-bootish" style I deem (it's used in cp command for
example). This way offset will always be the second parameter which is
more convenient.  

Help line will look like this:

=> help getidcr
getidcr addr_dcrn[.data_dcrn] offset 
 - return a value of register, addressed indirectly via DCR. data_dcrn
is assumed to be addr_dcrn+1 if not specified.
  
> > Now regarding implementation. 
> 
> Yes, you should definitely disable the interrupts in this function.
> 

What is simplest way of doing that for PPC440? I mean, should I insert
asm into C code, or u-boot already has something better to use?

> > Can you refer me to proper link how I do proceed with patch
submission:
> > review, help information, actual sources delivering, etc...
> 
> This is explained at the end of the README under "Submitting
Patches:". 
> And please also take a look at "Coding Standards:".

I'll be preparing the patch; it will be ready next week most likely.

Thanks.
 
Leonid.