[#6763] Different L1 size for the same code between SVN5455 and SVN5013
Submitted By: Aaron Wu
2011-08-25 22:44:11 Close Date
EZ-Kit Lite Silicon Revision:
Fixed Fixed In Release:
Host Operating System:
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