2008-01-22 16:48:39     usability/reliability of blkfin-test programs

Document created by Aaronwu Employee on Aug 5, 2013
Version 1Show Document
  • View in full screen mode

2008-01-22 16:48:39     usability/reliability of blkfin-test programs

Bill Fassler (UNITED STATES)

Message: 49966    I try to use these utilities a lot just to discover they appear useless to me.  For instance, it appears to me that i2c is working since I can communicate with my camera through it and PPI0 and PPI1 also seem to be doing OK since I can use both my LCD and camera which uses them.

 

However when I run these test applications on my custom BF561 board I often get what seems like nonsense.  I assume these are not universal utilities but written for particular processors. ??!??

 

I suppose what I am saying is that if these don't work for BF561 then perhaps it would be best for me not to be seeing them in menuconfig as if I should be able to use them......

 

root:/bin> ppitest -h

Error opening /dev/ppi: No such file or directory

 

I have PPI0 and PPI1 and I know they work.

 

root:/bin> twi_test 0x20 0x58

slave addr: 0x20

Case 1: Program with correct I2C_SLAVE address

-----------------------------------------

local_cam_get_register: error sending register address 0x02, errno = 121

Fail to get data from register 2

 

My camera is located at 0x20, but as you can see it doesn't matter whether I use a good address a bad address or even a ridiculous address (ones that don't even exist on the i2c) I get the same results:

 

root:/bin> twi_test 0x58 0x20

slave addr: 0x58

Case 1: Program with correct I2C_SLAVE address

-----------------------------------------

local_cam_get_register: error sending register address 0x02, errno = 121

Fail to get data from register 2

root:/bin> twi_test 0x90 0x80

slave addr: 0x90

Case 1: Program with correct I2C_SLAVE address

-----------------------------------------

local_cam_get_register: error sending register address 0x02, errno = 121

Fail to get data from register 2

root:/bin>

 

So now that I am having trouble with SPI and trying to test it, I am not sure if I can have any faith

in SPI_TEST either which gives me a stack dump.

 

root:/bin> spi_test -c 0x2

NULL pointer access (probably)

Deferred excecption or HW Error context

CURRENT PROCESS:

COMM=spi_test PID=134

TEXT = 0x0359a000-0x0359af7c  DATA = 0x035b4f7c-0x035b519c

BSS = 0x035b519c-0x016c0000   USER-STACK = 0x016dfeb0

 

return address: [0x002df35c]; contents of:

0x002df330:  300a  2005  3211  9950  0c00  1837  6409  6018

0x002df340:  5401  0c00  17f8  e147  fefe  e143  8080  3211

0x002df350:  e107  feff  e103  8080  09ca  101d [9010] 5038

0x002df360:  5418  0c00  1c16  e590  fffc  304a  0c00  67e1

 

SEQUENCER STATUS:

SEQSTAT: 00060027  IPEND: 0030  SYSCFG: 0006

  HWERRCAUSE: 0x18

  EXCAUSE   : 0x27

RETE: <0x00000000> /* Maybe null pointer? */

RETN: <0x016a4000> /* unknown address */

RETX: <0x002df35c> [ /lib/libuClibc-0.9.29.so + 0x1f35c ]

RETS: <0x0359abf4> [ /bin/spi_test + 0xbf4 ]

PC  : <0x002df35c> [ /lib/libuClibc-0.9.29.so + 0x1f35c ]

DCPLB_FAULT_ADDR: <0x00000000> /* Maybe null pointer? */

ICPLB_FAULT_ADDR: <0x002df35c> [ /lib/libuClibc-0.9.29.so + 0x1f35c ]

 

PROCESSOR STATE:

R0 : 00000000    R1 : 00000000    R2 : 00000000    R3 : 80808080

R4 : 0359ae54    R5 : 035b50f8    R6 : 00000000    R7 : fefefeff

P0 : 016a8b6c    P1 : 00000003    P2 : 00000000    P3 : 016a9118

P4 : 016a8798    P5 : 016dfeb4    FP : 016dfe20    SP : 016a3f24

LB0: 0029dda1    LT0: 0029dd94    LC0: 00000000

LB1: 0029cbfd    LT1: 0029cbfc    LC1: 00000000

B0 : 00000000    L0 : 00000000    M0 : 00000000    I0 : 016dffe3

B1 : 00000000    L1 : 00000000    M1 : 00000000    I1 : 016a9118

B2 : 00000000    L2 : 00000000    M2 : 00000000    I2 : 00000000

B3 : 00000000    L3 : 00000000    M3 : 00000000    I3 : 00000000

A0.w: 00000000   A0.x: 00000000   A1.w: 00000000   A1.x: 00000000

USP : 016dfe20  ASTAT: 02003025

 

Hardware Trace:

   0 Target : <0x001035c0> { _trap_c + 0x0 }

     Source : <0xffa00a8c> { _exception_to_level5 + 0xb4 }

   1 Target : <0xffa009d8> { _exception_to_level5 + 0x0 }

     Source : <0xffa00930> { _ex_trap_c + 0x5c }

   2 Target : <0xffa008d4> { _ex_trap_c + 0x0 }

     Source : <0xffa00b2c> { _trap + 0x28 }

   3 Target : <0xffa00b04> { _trap + 0x0 }

     Source : <0x002df35a> [ /lib/libuClibc-0.9.29.so + 0x1f35a ]

   4 Target : <0x002df346> [ /lib/libuClibc-0.9.29.so + 0x1f346 ]

     Source : <0x002df3bc> [ /lib/libuClibc-0.9.29.so + 0x1f3bc ]

   5 Target : <0x002df3ba> [ /lib/libuClibc-0.9.29.so + 0x1f3ba ]

     Source : <0x002df326> [ /lib/libuClibc-0.9.29.so + 0x1f326 ]

   6 Target : <0x002df316> [ /lib/libuClibc-0.9.29.so + 0x1f316 ]

     Source : <0x002df30a> [ /lib/libuClibc-0.9.29.so + 0x1f30a ]

   7 Target : <0x002df300> [ /lib/libuClibc-0.9.29.so + 0x1f300 ]

     Source : <0x0029dd7e> { _setup_arch + 0x3ce }

   8 Target : <0x0029dd6c> { _setup_arch + 0x3bc }

     Source : <0x0029dc92> { _setup_arch + 0x2e2 }

   9 Target : <0x0029dc86> { _setup_arch + 0x2d6 }

     Source : <0x0029dc50> { _setup_arch + 0x2a0 }

  10 Target : <0x0029dc3c> { _setup_arch + 0x28c }

     Source : <0x0029bc92> { _do_header + 0x4e }

  11 Target : <0x0029bc84> { _do_header + 0x40 }

     Source : <0x0029bebc> { _huft_build + 0x28 }

  12 Target : <0x0029beba> { _huft_build + 0x26 }

     Source : <0x0029bc52> { _do_header + 0xe }

  13 Target : <0x0029bc08> { _inflate_codes + 0x42c }

     Source : <0x0029bcbc> { _do_header + 0x78 }

  14 Target : <0x0029bcb8> { _do_header + 0x74 }

     Source : <0x0029bbfe> { _inflate_codes + 0x422 }

  15 Target : <0x0029bbf4> { _inflate_codes + 0x418 }

     Source : <0x0029bc04> { _inflate_codes + 0x428 }

Stack from 016a3f04:

        00000110 ffa00a90 00288788 00288788 00288780 016dfa74 00000000 002ccf38

        002df35c 00000030 00060027 00000000 016a4000 002df35c 002df35c 0359abf4

        00000000 02003025 0029cbfd 0029dda1 0029cbfc 0029dd94 00000000 00000000

        00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

        00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

        00000000 00000000 016a9118 016dffe3 016dfe20 016dfe20 016dfeb4 016a8798

 

Call Trace:

 

SIGSEGV

QuoteReplyEditDelete

 

 

2008-01-22 17:41:24     Re: usability/reliability of blkfin-test programs

Mike Frysinger (UNITED STATES)

Message: 49974    the tests are written to be called as part of the test suite, but beyond that they arent really designed to be user friendly

 

the ppitest test obviously relies on the kernel character PPI driver being enabled/working which is not true for the BF561 EZKIT

 

the twi_test merely passes your arguments to the kernel via the i2c char interface driver

QuoteReplyEditDelete

 

 

2008-01-23 09:53:04     Re: usability/reliability of blkfin-test programs

Bill Fassler (UNITED STATES)

Message: 50026    Here is a set of very useful and fairly friendly and generic i2c troubleshooting utilities that should work for all blackfin platforms.  You can peek and poke using the i2cget and i2cset commands and you can probe your entire i2c to see what devices it can pick up and what addresses they are at using i2cdetect.  I personally found it more helpful than some of the test programs in the dist.

 

I'm sure your familiar with this anyway, but thought I'd throw it out on the forum.

 

Currently I hand modify the Makefile to select the particular blackfin compiler I am using and then I have to manually place them in the ROMFS. I would advocate for the inclusion of the utilties into the blkfin-test suite.

 

Bill

i2c-tools-3.0.0.tar

QuoteReplyEditDelete

 

 

2008-01-23 10:05:22     Re: usability/reliability of blkfin-test programs

Mike Frysinger (UNITED STATES)

Message: 50027    is this something you wrote ?  or did you grab it from somewhere else ?  (and if so, what's the URL)

QuoteReplyEditDelete

 

 

2008-01-23 10:19:24     Re: usability/reliability of blkfin-test programs

Bill Fassler (UNITED STATES)

Message: 50031    I gotta be honest and say I don't always take good notes and I am not positive, but I think I got them from here:

 

http://linux.softpedia.com/get/System/Hardware/I2C-Tools-31650.shtml

 

Bill

QuoteReplyEditDelete

 

 

2008-01-23 10:51:17     Re: usability/reliability of blkfin-test programs

Mike Frysinger (UNITED STATES)

Message: 50036    did you make modifications, or did you just download/unpack/build/run ?

QuoteReplyEditDelete

 

 

2008-01-23 11:54:44     Re: usability/reliability of blkfin-test programs

Bill Fassler (UNITED STATES)

Message: 50043    The only change I recall making was to the Makefile.  The only advantage perhaps in adding it to the distribution is that you could make it so it will automagically use the appropriate compiler and copy the files into ROMFS for you.

 

If you do a lot of 'make clean' then a person will really appreciate not have to repopulate their ROMFS manually with stuff like this and if you play around with different formats like ELF and FDPIC you won't have to keep editing your Makefile.

 

I found these utilities very helpful in bringing up our new boards.

 

Bill

QuoteReplyEditDelete

 

 

2008-01-23 12:04:55     Re: usability/reliability of blkfin-test programs

Mike Frysinger (UNITED STATES)

Message: 50047    ive added it to trunk now, thanks

QuoteReplyEditDelete

 

 

2008-01-24 10:50:52     Re: usability/reliability of blkfin-test programs

Bill Fassler (UNITED STATES)

Message: 50097    Super! I assume all the top level decisions like compiler, compiler and linker flags are passed down automagically which is awesome.

 

As a side note though, I assume folks might want to install these on their host machine just so they have easy access to the man pages.  I myself did so since I am still learning how to use these utilities, but I strongly advise against running any of these on your desktop/host build machine!

 

Bill

QuoteReplyEditDelete

 

 

2008-01-24 10:55:34     Re: usability/reliability of blkfin-test programs

Bill Fassler (UNITED STATES)

Message: 50098    Just so you know, I sorta tried putting them in my distro, but I couldn't figure out how to do it.  I can add my own drivers to the kernel and have them show up in the menuconfig but the blkfin-apps and blkfin-test stuff looks different and I couldn't figure out how to get them in there. (I didn't spend much time at....)

 

Bill

QuoteReplyEditDelete

 

 

2008-01-24 11:14:47     Re: usability/reliability of blkfin-test programs

Mike Frysinger (UNITED STATES)

Message: 50100    when you say "my distro" you mean "uclinux distribution" right ?

 

that stuff should be covered here (it could do with cleaning up now though):

http://docs.blackfin.uclinux.org/doku.php?id=adding_user_applications

Attachments

    Outcomes