Messages in this thread | | | Date | Fri, 24 Apr 2015 16:20:37 +0800 | Subject | Re: [PATCH] blackfin: Makefile: Skip reloc overflow issue when COMPILE_TEST enabled | From | Steven Miao <> |
| |
On Thu, Apr 23, 2015 at 10:30 PM, Chen Gang <xili_gchen_5257@hotmail.com> wrote: > On 4/23/15 10:51, Steven Miao wrote: >> On Wed, Apr 22, 2015 at 10:32 PM, Chen Gang <xili_gchen_5257@hotmail.com> wrote: >>> On 4/22/15 17:00, Steven Miao wrote: >>>> Hi, >>>> >>>> On Thu, Apr 9, 2015 at 5:03 AM, Chen Gang <xili_gchen_5257@hotmail.com> wrote: >>>>> l1_text is at L1_CODE_START (e.g. for bf533, 0xff800000). If the kernel >>>>> is too big, it may be overwritten, the related issue: >>>>> >>>>> LD init/built-in.o >>>>> init/built-in.o: In function `do_early_param': >>>>> init/main.c:(.init.text+0xe0): relocation truncated to fit: R_BFIN_PCREL24 against symbol `strcmp' defined in .l1.text section in arch/blackfin/lib/lib.a(strcmp.o) >>>>> init/main.c:(.init.text+0x10e): relocation truncated to fit: R_BFIN_PCREL24 against symbol `strcmp' defined in .l1.text section in arch/blackfin/lib/lib.a(strcmp.o) >>>> blackfin toolchain generate 24 bit pc-relative calls by default, with >>>> a range of –16,777,216 through 16,777,214 (0xFF00 0000 to 0x00FF FFFE) >>>> is available. >>>> So call to l1_text should be ok. What do you mean the kernel is too big? >>>> http://docs.blackfin.uclinux.org/doku.php?id=ism:call >>>> >>>> >>> >>> Excuse me, I am not quite familiar with what you said above, can we >>> also treat 24-bit as 16MB size limitation for kernel size? I am not >>> quite sure, could you provide more information about it?. >>> >>> And I checked "arch/blackfin/kernel/vmlinux.lds.S", for me, in current >>> case: >> The memory address on blackfin usually starts from 0, if pc = 0, the >> pc relative call range is [0xFF00 0000 - 0xFFFFFFFF, 0 - 0x00FF >> FFFE], it covers L1 space. >> If the kernel is big than 16M, eg. pc = 0x100 0000, the pc relative >> call range accordingly is [0x1 - 0x100 0000, 0x100 0000 - 0x 1FF FFFE >> ], it cann't call to L1 space. > > OK, thanks. I guess your meaning is: > > - If the kernel is too big, it may let the pc which wants to call L1 > space fail. > > - So the kernel is too big to cause this issue, but it is nothing with > 'overwritten' in my original patch comments. > Yes, it is. > - We can treat it as environments limitation, then can use COMPILE_TEST > for it. So this patch is still OK, except the related comments need > be improved (at least need to remove 'overwritten'). > If pc-relative CALL will fail, there will be "relocation truncated to fit: R_BFIN_PCREL24" warnings. >>> >>> - init section is the last section of kernel, l1.text is within init >>> section, and it is in the fixed address. The other contents before >>> l1.text are dynamic (depend on kernel size). >>> > > I guess, what I said above is meaningless (although it is correct). > >>> - if kernel is too big, the contents before l1.text (the other contents >>> in .init.text) will override it, so ld reports issues. > Actually the kernel which is large the 16M could not happen, large size kernel image is not sugguested on a embedded system.
> I guess, what I said above is incorrect. > > > Are all of I guesses correct? > > > Thanks. > -- > Chen Gang > > Open, share, and attitude like air, water, and life which God blessed
-steven
| |