[#6763] Different L1 size for the same code between SVN5455 and SVN5013

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

[#6763] Different L1 size for the same code between SVN5455 and SVN5013

Submitted By: Aaron Wu

Open Date

2011-08-25 22:44:11     Close Date

2011-09-19 03:08:08


Medium     Assignee:

Stuart Henderson


EZ-Kit Lite     Silicon Revision:


Fixed     Fixed In Release:




Host Operating System:

toolchain rev.:

SVN5455     kernel rev.:

uClinux 2010R1 dist


Closed     Found In Release:


Is this bug repeatable?:


Summary: Different L1 size for the same code between SVN5455 and SVN5013



When build the lib/libbfgdots/g729/test/g729ab_test.c as FDPIC code in uClinux 2010 release with 2011 July 25 toolchain SVN version 5455 we find the generated code is trying to alloc a L1 instruction size up to 0xc3a4 during run time, which is more than the available size on Blackfin CPU (test on a 537 board, total L1 inst size is 48K, 47K free), while the same code built with toolchain 2010 Dec 09 SVN 5013 requires only 0x8f54 which works fine.


This issue is found during investigation for bug 6700 "g729 test fail on performance machine built with latest toolchain"




--- Stuart Henderson                                         2011-08-26 12:38:44

Could you give me the command line you are using to compile g729ab_test.c and

tell me where exactly you are seeing the over-sized alloc?

and to confirm, you are using the 2010R1-RC5 release of uclinux?


Currently my tests have shown that this test has always failed for fdpic (going

back to 09r1.1), although not with the error message mentioned in bug 6700.  i'd

like to reproduce the difference you are seeing between the two revisions.




--- Aaron Wu                                                 2011-08-27 10:07:14

Yes we are using the 2010R1-RC5 uClinux release, we are using scripts under

testsuites/g729 to config the kernel, build the package/app and do the auto test

on a target board, as lots of steps are involved in the scripts, for details you

may check these scripts,README.txt in folder uclinuxdist/lib/libbfgdots/g729

will also help.


During run time the L1 code section allocation is done by code in

arch/blackfin/mm/sram_alloc.c so by print the size we found it's trying to alloc

a size larger than the processor can afford.


As the g729 replication is complicated I will try to check out if I can

replicate this L1 issue with a simple test case like using the existing L1 test

program and be back to you with this simple replicate method


--- Aaron Wu                                                 2011-09-05 04:03:09

With the l1 test app in testsuites/l1_app in 2010R1 uCLinux release, I did a

similar test and saw they are trying try to alloc different L1 SRAM size for the

two versions of toolchaian mentioned above. Here is some tips:

1)The newer toolchain would not support --sep-code option, so I disable this

option to pass the compile for the newer toolchain. I will input another item to

track this issue

2)apply the $(FLAGS) option to build the test_helloworld

3)print the size parameter passed in in kernel code l1_inst_sram_alloc.

4)copy the test_helloworld and libhelloworld.so to a bf537 board for test

5)result is like this:

  for old toolchain:


     li_inst_sram_alloc, size = 1164

     li_inst_sram_alloc, size = 36

     li_inst_sram_alloc, size = 712



  for newer one:


    li_inst_sram_alloc, size = 3016

    li_inst_sram_alloc, size = 36


Please let me know if you need more details


--- Stuart Henderson                                         2011-09-16 11:12:47

are you sure this isn't just the difference in -sep-code vs !-sep-code?  i get

the same behaviour with old and new toolchains now that binutils-2.21 supports



could you confirm?


--- Aaron Wu                                                 2011-09-19 02:50:46

Vivi just confirmed that on the toolchain trunk the G729 bug fixed, bug 6700,

which lead to this "difference size bug", so probably you are right,

this should be just the difference between -sep-code option enabled or not.  












File Name     File Type     File Size     Posted By

No Files Were Found