EngineerZone: Message List

IRQ Schedule latency test build fail

analogvm-admin@analog-vm.hosted.jivesoftware.com — Tue, 19 Jun 2012 20:15:53 GMT

Hi,

I encountered build failure for IRQ Schedule latency test. The below log indicates compilation error for file timerbench.c

uClinux distro version: current 2011R1 Head

toolchain: 2011R1-RC4

Platform: TLL6527M

Seems the file needs to be updated for the current kernel. Could you please check into this.

make[6]: Entering directory `/home/ashish/Software/2011R1_sources/uclinux-distro/user/blkfin-test/latency-test'
CFLAGS="" CPPFLAGS="" LDFLAGS="" make ARCH=blackfin CROSS_COMPILE=bfin-uclinux- -C /home/ashish/Software/2011R1_sources/uclinux-distro/linux-2.6.x SUBDIRS=$PWD modules
make[7]: Entering directory `/home/ashish/Software/2011R1_sources/uclinux-distro/linux-2.6.x'
CC [M] /home/ashish/Software/2011R1_sources/uclinux-distro/user/blkfin-test/latency-test/timerbench.o
/home/ashish/Software/2011R1_sources/uclinux-distro/user/blkfin-test/latency-test/timerbench.c: In function ‘tb_open’:
/home/ashish/Software/2011R1_sources/uclinux-distro/user/blkfin-test/latency-test/timerbench.c:221: error: implicit declaration of function ‘init_MUTEX’
/home/ashish/Software/2011R1_sources/uclinux-distro/user/blkfin-test/latency-test/timerbench.c: In function ‘tb_ioctl’:
/home/ashish/Software/2011R1_sources/uclinux-distro/user/blkfin-test/latency-test/timerbench.c:310: error: implicit declaration of function ‘kmalloc’
/home/ashish/Software/2011R1_sources/uclinux-distro/user/blkfin-test/latency-test/timerbench.c:310: warning: assignment makes pointer from integer without a cast
/home/ashish/Software/2011R1_sources/uclinux-distro/user/blkfin-test/latency-test/timerbench.c: At top level:
/home/ashish/Software/2011R1_sources/uclinux-distro/user/blkfin-test/latency-test/timerbench.c:495: error: unknown field ‘ioctl’ specified in initializer
/home/ashish/Software/2011R1_sources/uclinux-distro/user/blkfin-test/latency-test/timerbench.c:495: warning: initialization from incompatible pointer type
make[8]: *** [/home/ashish/Software/2011R1_sources/uclinux-distro/user/blkfin-test/latency-test/timerbench.o] Error 1
make[7]: *** [_module_/home/ashish/Software/2011R1_sources/uclinux-distro/user/blkfin-test/latency-test] Error 2
make[7]: Leaving directory `/home/ashish/Software/2011R1_sources/uclinux-distro/linux-2.6.x'
make[6]: *** [module] Error 2
make[6]: Leaving directory `/home/ashish/Software/2011R1_sources/uclinux-distro/user/blkfin-test/latency-test'
make[5]: *** [all] Error 2
make[5]: Leaving directory `/home/ashish/Software/2011R1_sources/uclinux-distro/user/blkfin-test'
make[4]: *** [blkfin-test] Error 2
make[4]: Leaving directory `/home/ashish/Software/2011R1_sources/uclinux-distro/user'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/home/ashish/Software/2011R1_sources/uclinux-distro/user'
make[2]: *** [subdirs] Error 1
make[2]: Leaving directory `/home/ashish/Software/2011R1_sources/uclinux-distro'
make[1]: *** [single_] Error 2
make[1]: Leaving directory `/home/ashish/Software/2011R1_sources/uclinux-distro'
make: *** [single] Error 2

Best regards,

Ashish

Adding support for TLL6527M to Blackfin LTP port

analogvm-admin@analog-vm.hosted.jivesoftware.com — Fri, 08 Jun 2012 09:34:33 GMT

Hi,

We want to add support for our custom ADSP-BF527 based platform in the Blackfin LTP port so that we can do an exhaustive testing of our custom kernels and also validate HW builds. Since most of the aspects are similar to the BF527-EZKIT, we should be able to start off the settings / configuration for the EZKIT.

We are referring the page http://docs.blackfin.uclinux.org/doku.php?id=linux-kernel:testing&s[]=ltp for details. There is a section that talks about

downloading the latest version of the ltp source code and then building it. But the release distribution already contains the unit test scripts under test suite and other higher level scripts.

We need your suggestions on what our starting point should be. Based on our reading following is the set of steps we think we should follow

1. Update the high level scripts part of uclinux-dist/testsuites/ltp to add cases for our platform where-ever necessary

2. Add support for TLL6527M in the configuration scripts present in the uclinux-dist/testsuites/test_scripts

3. make sure the mechanism to reset the board works fine by updating the reset_board.exp script and other scripts in the uclinux-dist/testsuites

4. Then go through all the unit tests and ascertain the relevant ones for our platform, add support if needed and finally,

5. Follow the steps given here to run the tests.

http://docs.blackfin.uclinux.org/doku.php?id=linux-kernel:testing&s[]=ltp#linux_kernel_test_steps

Please confirm if above approach makes sense and indicate any key dependency that needs porting.

We're using uclinux-dist version 2011R1-RC3 & toolchain is 2011R1-RC4.

Best regards,

Ashish Gupta

NDSO-IIO compile failure & crash

analogvm-admin@analog-vm.hosted.jivesoftware.com — Wed, 06 Jun 2012 09:41:54 GMT

We’re currently validating the IIO framework for ADSP-BF527 based TLL6527M platform. We’re using the AD7606 ADC connected to the SPI port of Blackfin. We were able to successfully capture the samples from the ADC using sysfs trigger. Next we want to use the ndso application for shipping the samples over the Ethernet interface. But compilation failed when trying to build the ndso application. See the log below:

Blackfin uClinux distro version: 2011R1-RC3

NDSO compilation failure log:

make[5]: Entering directory `/home/ashish/Software/2011R1_sources/working-uclinux/blackfin-linux-dist_RC3/user/blkfin-apps/ndso'

for i in thttpd src_ndso_iio ; do make -C $i romfs || exit $? ; done

make[6]: Entering directory `/home/ashish/Software/2011R1_sources/working-uclinux/blackfin-linux-dist_RC3/user/blkfin-apps/ndso/thttpd'

romfs-inst.sh /bin/ndso

romfs-inst.sh -e CONFIG_USER_PPIFPGACGI -a "t_httpd &" /etc/rc

make[6]: Leaving directory `/home/ashish/Software/2011R1_sources/working-uclinux/blackfin-linux-dist_RC3/user/blkfin-apps/ndso/thttpd'

make[6]: Entering directory `/home/ashish/Software/2011R1_sources/working-uclinux/blackfin-linux-dist_RC3/user/blkfin-apps/ndso/src_ndso_iio'

romfs-inst.sh ndso /home/httpd/cgi-bin/ndso.cgi

cp: cannot create regular file `/home/ashish/Software/2011R1_sources/working-uclinux/blackfin-linux-dist_RC3/romfs/home/httpd/cgi-bin/ndso.cgi': No such file or directory

make[6]: *** [romfs] Error 1

make[6]: Leaving directory `/home/ashish/Software/2011R1_sources/working-uclinux/blackfin-linux-dist_RC3/user/blkfin-apps/ndso/src_ndso_iio'

To rectify the error, /home/httpd/cgi-bin/ folder was created. After this the image was built successfully. We modified the makefile (blackfin-linux-dist_RC3/user/blkfin-apps/ndso/src_ndso_iio/Makefile) as follows to create the missing directory:

romfs:

$(ROMFSINST) -d $(EXEC) /home/httpd/cgi-bin/ndso.cgi

The -d option creates directories of its not already present.

Now it compiled fine, so we booted the kernel and ran ndso, but as we try to open the website, it crashes

root:/> ndso &

[1] 486 ndso

root:/> NULL pointer access

Deferred Exception context

CURRENT PROCESS:

COMM=ndso PID=486 CPU=0

TEXT = 0x02d50000-0x02d59ba0 DATA = 0x02bd2ba0-0x02bd39b0

BSS = 0x02bd39b0-0x02d80000 USER-STACK = 0x02d9fec0

return address: [0x02d51f82]; contents of:

0x02d51f60: 6007 912c e51a 0021 9115 e12a 1138 5b11

0x02d51f70: 320e 9062 5c92 3042 4f18 5005 3228 e409

0x02d51f80: 0489 [a168] 67f8 b168 a128 5081 a0e8 cc04

0x02d51f90: 4220 b12a 0000 e120 012b 0901 1c10 b9fb

ADSP-BF527-0.2 500(MHz CCLK) 100(MHz SCLK) (mpu off)

Linux version 3.0.8-ADI-2011R1RC3_DEV_0_5_AG (ashish@ashish.tll) (gcc version 42

SEQUENCER STATUS: Not tainted

SEQSTAT: 00002027 IPEND: 0008 IMASK: ffff SYSCFG: 0006

EXCAUSE : 0x27

physical IVG3 asserted : <0xffa00710> { _trap + 0x0 }

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

RETN: <0x02090000> /* kernel dynamic memory */

RETX: <0x00000480> /* Maybe fixed code section */

RETS: <0x02d51f52> [ /bin/ndso + 0x1f52 ]

PC : <0x02d51f82> [ /bin/ndso + 0x1f82 ]

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

ICPLB_FAULT_ADDR: <0x02d51f82> [ /bin/ndso + 0x1f82 ]

PROCESSOR STATE:

R0 : 00000000 R1 : 00000000 R2 : 00000355 R3 : 0000ecac

R4 : 01dba716 R5 : 00000000 R6 : 02d60004 R7 : 00000000

P0 : 00000006 P1 : 02d60004 P2 : 00000000 P3 : 02bd3400

P4 : 02d61140 P5 : 00000000 FP : 02d9bff0 SP : 0208ff24

LB0: 02aec59f LT0: 02aec59e LC0: 00000000

LB1: 02b9e137 LT1: 02b9e136 LC1: 00000000

B0 : 00000137 L0 : 00000000 M0 : fffffffc I0 : 02d9bbec

B1 : 000000c0 L1 : 00000000 M1 : 00000001 I1 : 02da0d54

B2 : 7ffff000 L2 : 00000000 M2 : 00001802 I2 : 00000003

B3 : 00000000 L3 : 00000000 M3 : 0000005b I3 : 00000007

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

USP : 02d9bfe0 ASTAT: 02002001

Hardware Trace:

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

Source : <0xffa006a4> { _exception_to_level5 + 0xa4 } JUMP.L

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

Source : <0xffa004b4> { _bfin_return_from_exception + 0x18 } RTX

2 Target : <0xffa0049c> { _bfin_return_from_exception + 0x0 }

Source : <0xffa00558> { _ex_trap_c + 0x74 } JUMP.S

3 Target : <0xffa004e4> { _ex_trap_c + 0x0 }

Source : <0xffa0076a> { _trap + 0x5a } JUMP (P4)

4 Target : <0xffa00710> { _trap + 0x0 }

FAULT : <0x02d51f82> [ /bin/ndso + 0x1f82 ] P0 = W[P5 + 5]

Source : <0x02d51f7e> [ /bin/ndso + 0x1f7e ] R1 = [P1 + 0x24]

5 Target : <0x02d51f52> [ /bin/ndso + 0x1f52 ]

Source : <0x02d558b2> [ /bin/ndso + 0x58b2 ] RTS

6 Target : <0x02d558a6> [ /bin/ndso + 0x58a6 ]

Source : <0x02b8ecd4> [ /lib/libc.so.0 + 0xecd4 ] RTS

7 Target : <0x02b8eccc> [ /lib/libc.so.0 + 0xeccc ]

Source : <0x02b8ecbe> [ /lib/libc.so.0 + 0xecbe ] IF CC JUMP pcrel (BP)

8 Target : <0x02b8ecb6> [ /lib/libc.so.0 + 0xecb6 ]

Source : <0xffa00c58> { __common_int_entry + 0xcc } RTI

9 Target : <0xffa00bf6> { __common_int_entry + 0x6a }

Source : <0xffa00fb0> { _evt_system_call + 0x64 } JUMP.S

10 Target : <0xffa00fb0> { _evt_system_call + 0x64 }

Source : <0xffa008f6> { _system_call + 0xbe } RTS

11 Target : <0xffa008f2> { _system_call + 0xba }

Source : <0xffa008e2> { _system_call + 0xaa } IF !CC JUMP pcrel

12 Target : <0xffa008d8> { _system_call + 0xa0 }

Source : <0xffa008c8> { _system_call + 0x90 } IF !CC JUMP pcrel

13 Target : <0xffa008a2> { _system_call + 0x6a }

Source : <0x00048678> { _sys_close + 0x28 } RTS

14 Target : <0x00048670> { _sys_close + 0x20 }

Source : <0x000486dc> { _sys_close + 0x8c } IF !CC JUMP pcrel (BP)

15 Target : <0x000486c2> { _sys_close + 0x72 }

Source : <0x00048638> { _filp_close + 0x44 } RTS

Userspace Stack

Stack info:

SP: [0x02d9bfe0] <0x02d9bfe0> [ ndso + 0x1bfe0 ]

Memory from 0x02d9bfe0 to 02d9c000

02d9bfe0:[02d9bffc] 02d52024 0000122c 02bd3400 02d9fde0 02d52ffe 02d60004

Return addresses in stack:

A. Could you please look into this issue and suggest resolution

B. We are using the latest release distro 2011R1-RC3, should we move to the current 2011R1 head, has been any patches to fix ndso?

Regards,

Ashish

Re: mplayer crashed in 2011R1 in second run

analogvm-admin@analog-vm.hosted.jivesoftware.com — Tue, 05 Jun 2012 20:36:49 GMT

Dear Sonic

Thanks for updating the 2011 HEAD by restoring the drop page cache patch for NOMMU. We've updated the current 2011R1 head and recompiled the kernel. Next we ran the mplayer multiple times. We found that still mplayer crashes with page allocation failure. However now the crashes are not that deterministic as in the previous situation (where every alternative run used to crash) but are random.

We've systematically gone through our experiments by capturing the state of memory (cat /proc/meminfo) at every step. Here is a summary of what we did:

a. Recompiled Blackfin uClinux – 2011R1 after updating to current HEAD with NOMMU patch for drop page cache restored.

b. Booted the new kernel on our ADSP-BF527 based TLL6527M platform.

MemTotal: 60968 kB

MemFree: 36136 kB

c. Transferred the test video file (tom & jerry video from mplayer test suite) - approx 7.1 MB

MemTotal: 60968 kB

MemFree: 28968 kB

d. Ran mplayer multiple times while checking meminfo at every stage

When Mplayer works fine following is the state of active and inactive memory

Active(file): 14500 kB

Inactive(file): 11296 kB

Unevictable: 0 kB

And when it crashes due to page allocation failure, active and inactive memory goes to 0 and all of it shows up under unevictable

Active(file): 0 kB

Inactive(file): 4 kB

Unevictable: 25740 kB

You can find the detailed log attached herewith - "EN_MplayerCrash_20120606_AG.doc"

Could you think of any reasons why the entire available active+inactive memory shows up under Unevictable? How can we resolve this issue?

Your help in this regard is deeply appreciated, being able to reliably run media player for video playback on a multimedia centric processor such as Blackfin is a highly expected feature for not just our customers but anyone in general.

regards,

Ashish

Using ADP5520 for driving SHARP LCD backlight

analogvm-admin@analog-vm.hosted.jivesoftware.com — Mon, 09 Apr 2012 11:27:57 GMT

Hi,

We are planning to use the ADP5520 Backlight driving chip for our LCD panel - SHARP - LQ043T3DG01. Datasheet can be downloaded from here:

http://www.google.co.in/url?sa=t&rct=j&q=sharp%20lq043t3dg01&source=web&cd=1&ved=0CDAQFjAA&url=http%3A%2F%2Fwww.sharpsme.com%2Fdownload%2FLQ043T3DG01-SPpdf&ei=5caCT6WoCpHMrQfvksHeBQ&usg=AFQjCNE8xPyTp0LW6AXB_0xxWSb0adR61Q&cad=rja

Could someone please confirm if ADP5520 can drive the backlight for the above display. The chip datasheet mentions the right voltage range needed but it also says it can support only upto 6 LEDs while this SHARP display has 9 LEDs. Should it make the difference as long as the voltage is within range?

Best regards,

Ashish

Re: U-Boot

analogvm-admin@analog-vm.hosted.jivesoftware.com — Fri, 23 Mar 2012 11:35:02 GMT

Hi,

I am defining the BOOT_MODE in the new config file thus created for TLL527M i.e. tll6527m.h attached above.

#define CONFIG_BFIN_BOOT_MODE BFIN_BOOT_SPI_MASTER

Regards,

Ashish

Re: U-Boot

analogvm-admin@analog-vm.hosted.jivesoftware.com — Fri, 23 Mar 2012 08:11:50 GMT

Hi,

Yeah, since the portF pins are muxed with PPI and SPORT (critically needed for accessing display modules and ADCs), we use UART1 PortG for console on TLL6527M.

I have some important observations to share:

1. U-Boot compiled with changes as described in my previous message, boots fine when launched (init.elf and u-boot elf file) using gdb over gnICE in BMODE 0. It uses console on UART1 PortG and seems to work perfectly. Then I used the sf functions to write the ldr file of this U-Boot image to SPI FLASH address 0x0

2. Same image as compiled above does not show any console messages when booted in BMODE 3. The U-Boot ldr file was flashed in step1 above. Also I had disabled early debug messages on serial this time.

3. Next I again loaded the U-Boot using gdb in BMODE 0 and then used the sf read command to read the u-boot.ldr image (saved to SPI FLASH in step 1) to SDRAM. Then launched it with bootldr command. It ran fine with console messages on UART1 PortG

Now, it seems that U-Boot is not booting from SPI FLASH or its booting fine but something disrupts the console telemetry.

Ashish

Re: U-Boot

analogvm-admin@analog-vm.hosted.jivesoftware.com — Wed, 21 Mar 2012 06:45:02 GMT

Hi Aaron,

I modified the arch/blackfin/cpu/serial.h to allow using UART1 PortG depending upon the MACRO CONFIG_BF527_UART1_PORTG as below, but for some reason when I reset the system and boot over SPI FLASH, I don't see console messages, instead I see some non standard ASCII characters on minicom terminal (the kind you generally see when baud rates are mis-match).

#elif defined(__ADSPBF52x__)

# define DO_MUX(port, mux, func, tx, rx) \

bfin_write_PORT##port##_MUX((bfin_read_PORT##port##_MUX() & ~PORT_x_MUX_##mux##_MASK) | PORT_x_MUX_##mux##_FUNC_##func); \

bfin_write_PORT##port##_FER(bfin_read_PORT##port##_FER() | P##port##tx | P##port##rx);

switch (CONFIG_UART_CONSOLE) {

case 0: DO_MUX(G, 2, 3, 7, 8); break; /* Port G; mux 2; 3rd function; PG2 and PG8 */

case 1:

#ifndef CONFIG_BF527_UART1_PORTG

DO_MUX(F, 5, 3, 14, 15); break; /* Port F; mux 5; 3rd function; PF14 and PF15 */

#else

DO_MUX(G, 5, 2, 12, 13); break; /* Port G; mux 5; 2nd function; PG12 and P13 */

#endif

I've attached the modified serial.h and tll6527m.h config file. Any ideas on what could be wrong?

Regards,

Ashish

Re: Framebuffer showing previous applications last frame when starting another application

analogvm-admin@analog-vm.hosted.jivesoftware.com — Tue, 13 Mar 2012 05:09:25 GMT

Dear Aaron,

Thanks for the suggestion, we'll try the patch and report resuults, sorry for missing the important piece of information:

The LCD we're using is SHARP LQ035Q1DH02 mounted on the ADI EZ LCD expander. And we're using the standard driver that comes with the distribution as you seemed to have guessed correctly "bfin-lq035q1-fb.c".

Regards,

Ashish

U-Boot

analogvm-admin@analog-vm.hosted.jivesoftware.com — Tue, 13 Mar 2012 05:00:33 GMT

Hi,

While porting U-Boot for TLL6527M (which uses UART1 Port G for console), I found that the UART port for console telemetry seems to be hardwired to use only UART1 portF and no option to use UART1 portG is apparent, as can be seen from the following code snippet from serial.h: -

http://blackfin.uclinux.org/git/?p=u-boot;a=blob;f=arch/blackfin/cpu/serial.h;h=8a076ddc924d7348a1c9062df658eb88c0151a01;hb=77cd82ac8e23fd743914fe97c94b535cdfe14ca8

136 #elif defined(__ADSPBF52x__)

137 # define DO_MUX(port, mux, tx, rx) \

138 bfin_write_PORT##port##_MUX((bfin_read_PORT##port##_MUX() & ~PORT_x_MUX_##mux##_MASK) | PORT_x_MUX_##mux##_FUNC_3); \

139 bfin_write_PORT##port##_FER(bfin_read_PORT##port##_FER() | P##port##tx | P##port##rx);

140 switch (CONFIG_UART_CONSOLE) {

141 case 0: DO_MUX(G, 2, 7, 8); break; /* Port G; mux 2; PG2 and PG8 */

142 case 1: DO_MUX(F, 5, 14, 15); break; /* Port F; mux 5; PF14 and PF15 */

143 }

Ideally P_UART1_TX & P_UART1_RX should be used here since the following file already correctly defines which UART1 to use based on the macro "CONFIG_BF527_UART1_PORTG"

http://blackfin.uclinux.org/git/?p=u-boot;a=blob;f=arch/blackfin/include/asm/mach-bf527/portmux.h;h=aa165581d8c08f284dcad5cc408ad123b4cefcdc;hb=77cd82ac8e23fd743914fe97c94b535cdfe14ca8

Please confirm if my observation is correct or am I missing some macro.

Best regards,

Ashish