Re: Accessng phy registers

2007-03-27 Thread Alex Zeffertt
DI BACCO ANTONIO - technolabs wrote:
 
  I saw that both in phy,c and mii.c (linux 2.6.19) there is support to
  handle ioctls to read PHY registers. Why? And what should be used from a
  user application? I have both CONFIG_MII and CONFIG_PHYLIB set to y.

Try mii-tool -vv.  This uses the ioctls to extract the PHY registers.

If your ethernet driver doesn't support mii-tool it may support ethtool
instead.  Some drivers support both.

Alex

--

Cambridge Broadband appoints telecoms industry veteran John Cronin as chairman 
http://www.cambridgebroadband.com/mi20feb07.htm

Maxis to upgrade its backhaul network using Cambridge Broadband; Alcatel-Lucent 
selected to manage entire upgrade project 
http://www.cambridgebroadband.com/mi12feb07.htm


--
Cambridge Broadband Networks Limited
Registered in England and Wales under company number: 03879840
Registered office: Selwyn House, Cambridge Business Park, Cowley Road, 
Cambridge CB4 0WZ, UK
 
This email and any attachments are private and confidential. If you believe you 
have received this email in error please inform the sender and delete it from 
your mailbox or any other storage mechanism. Cambridge Broadband Networks 
Limited cannot accept liability for any statements made which are clearly the 
individual sender's own and not expressly made on behalf of Cambridge Broadband 
Networks Limited.


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded


Re: Reading and writing from/to VME device

2007-03-27 Thread Konstantin Boyanov

Hi,

First of all, thanks for the feedback!

@Tim Martin:

I'm not sure what a Linux v3.5 is - Montavista?  There are patches
available from Motorola to the vanila kernel if you're interested in
using something newer than 2.6.15.


Well, 3.5 is just the version of the driver, which is shown by
# cat /proc/vmeinfo
Otherwise, I'm using ELinOS 4.1 for building the linux system. And as for
now I think the 2.6.15 is fine for testing purposes.


The target VME address will be 0x, since you didn't configure
the .xlatedAddrU or .xlatedAddrL portions of outWinCfgADC.  Typically,
the VME address space is partitioned by VME chassis slot number or some
other application-specific scheme.


I tried to assign it to some other value (just a guess like 0x1000,
which I think is 0x1000 in A16), and then try to read through as many
addresses as the size of the window contains. I get the following output
(source again @EOM):

# Read @ VME address a000 = 0
# Read @ VME address a002 = 0
# Read @ VME address a004 = 1
# Read @ VME address a006 = 0
# Read @ VME address a008 = 0
# Read @ VME address a00c = eda2
# Read @ VME address a00e = eda2
# Read @ VME address a010 = 0
# Read @ VME address a012 = 0
# Read @ VME address a014 = 0
# Read @ VME address a016 = 0
# Read @ VME address a018 = 0
# Read @ VME address a01a = 0
# Read @ VME address a01c = 0
# Read @ VME address a020 = 0
# Read @ VME address a080 = 4546
# Read @ VME address a082 = 5f4c
# Read @ VME address a084 = 4146
# Read @ VME address a086 = 4344
# Read @ VME address a088 = 4445
# Read @ VME address a08a = 5953
# Read @ VME address a08c = 3
# Read @ VME address a08e = 3
# Read @ VME address a090 = 2
# Read @ VME address a092 = 0
# Read @ VME address a094 = 0
# Read @ VME address a096 = 0
# Read @ VME address a098 = 0
# Read @ VME address a09a = 0
# Read @ VME address a09c = 0
# Read @ VME address a09e = e369

repeatedly for all addresses up to 0xFD04F when I get a Segmentation fault.
At least now I got something, but I just cannot figure out why the output
repeats again and again about 20-30. The ADC board is in slot 4, and it's
CSR space is available at 0x1010 (set by junpers) , containing 15
registers. Is it possible that I'm actualy accessing them, or I just read
garbage?


Typically, the VME address space is partitioned by VME chassis slot number

or some

other application-specific scheme.

Does this mean that (theoretically) all slots (respectively boards in them)
are visible through a single outbound window? Or one must configure one
outbound window per slot?
I tried ot find some more info on this issue but with no success. I only
found something similar to what you are refering in the driver
documentation, but it is about the inbound windows, not the outbound ones.
The schema for the inbound wins is the following:

Each of the inbound windows is mapped into A32/D32 space at an address
determined by the boards slot
number. The address is calculated as
0x8000+(0x2000*slotnum)+(0x40*inboundnum).
Thus, in total, each board responds to a 32 MB chunk of VME address space.

I don't know whether the schema for the outbound wins is the same, or where
to find it. Maybe its driver specific, in other words defined by some driver
function? Can somebody shed some light on this please?

@Didier Kryn:

 1) You declare outWinCfg and use later in the code outWinCfgADC. I
guess the compiler will complain, unless I missed something. I guess
this is not the file you actually compiled.

This is just a typo, and yes, that's not the code that I compiled, just a
snippet to illustrate how I've really implemented my ideas.
About the MAP_SHARED flag - after getting over the VME accesses I'll have to
integrate the API to the VME bus ina control server, which uses shared
memory when reading out the data from the ADC, so I thought it would be a
good idea to test with shared memory in the first place.

Thanks again for all the help.

Best regards,
Konstantin
___

int main(int argc, char ** args)
{
   vmeInfoCfg_t  outWinCfgInfo;
   vmeOutWindowCfg_t outWinCfgADC;
   vmeOutWindowCfg_t outWinGetADC;

   int fdOut, status, i, j;
   unsigned int  n;
   unsigned short *rdPtr, *getPtr;

   fdOut = open(/dev/vme_m0, O_RDWR);
   perror(open);
   if(fdOut  0){
 printf(Opening /dev/vme_m0 failed. Errno = %d\n, errno);
   }

   memset(outWinCfgADC, 0, sizeof(vmeOutWindowCfg_t));
   perror(memset);

   outWinCfgADC.windowNbr= 0;
   outWinCfgADC.windowEnable= 1;
   outWinCfgADC.wrPostEnable= 0;
   outWinCfgADC.userAccessType = VME_SUPER;
   outWinCfgADC.dataAccessType = VME_DATA;
   outWinCfgADC.windowSizeL= 0x20;
   outWinCfgADC.xferProtocol   = VME_SCT;
   outWinCfgADC.addrSpace = VME_A16;
   outWinCfgADC.maxDataWidth = VME_D16;
   outWinCfgADC.xlatedAddrL= 0x1000;

   status = ioctl(fdOut, VME_IOCTL_SET_OUTBOUND, outWinCfgADC);
   perror(ioctl);
   if(status  0){
   printf(*** ioctl 

RE: Reading and writing from/to VME device

2007-03-27 Thread Martin, Tim
I tried to assign it to some other value (just a guess like 0x1000,
which I think is
 0x1000 in A16), and then try to read through as many  addresses as the
size of the
 window contains.

Your code indicated said you're using A24 addressing.  You should assign
an A24 address.

 I get the following output (source again @EOM):   
...
 repeatedly for all addresses up to 0xFD04F when I get a Segmentation
fault. At least now
 I got something, but I just cannot figure out why the output repeats
again and again about
 20-30. The ADC board is in slot 4, and it's CSR space is available at
0x1010 (set by junpers)
, containing 15 registers. Is it possible that I'm actualy accessing
them, or I just read garbage? 

Looks like you're reading something.  Address 0x1010 is larger than
a 24 bit address.  Perhaps you should be using A32 transfers instead of
A24?

Typically, the VME address space is partitioned by VME chassis slot
number or some 
other application-specific scheme.

Does this mean that (theoretically) all slots (respectively boards in
them) are visible
 through a single outbound window? Or one must configure one outbound
window per slot?

Yes, theoretically, all boards could be visible through one outbound
window, IF
1. The boards are configured to respond to an address in that window
2. None of the boards address spaces overlap.

 I tried ot find some more info on this issue but with no success. I
only found something
 similar to what you are refering in the driver documentation, but it
is about the inbound
 windows, not the outbound ones. The schema for the inbound wins is the
following: 
   
 Each of the inbound windows is mapped into A32/D32 space at an address
determined by the
 boards slot number. The address is calculated as
0x8000+(0x2000*slotnum)+(0x40*inboundnum). 
 Thus, in total, each board responds to a 32 MB chunk of VME address
space. 

I don't believe there are any VITA / VME requirements for a particular
addressing scheme.  The one above looks reasonable...I've used other
schemes as well.  It depends on your system configuration.

 I don't know whether the schema for the outbound wins is the same, or
where to find it.
 Maybe its driver specific, in other words defined by some driver
function?
 Can somebody shed some light on this please?

I believe Outbound/Inbound windows in the Tundra chip refer to the bus
mastership, not direction of data transfer.
VME Bus Master  VME Target  Data Direction  Window
SelfOther   ReadOutbound
SelfOther   Write   Outbound
Other   SelfReadInbound
Other   SelfWrite   Inbound

You would configure an Inbound window if you want some other board in
the system to be able to read/write your local address space.  You would
configure an Outbound window if you want to read/write some other
board's address space.

Tim 


___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded