On Tue, Apr 17, 2012 at 10:40 AM, Stefan Kristiansson <[email protected]> wrote: > On Tue, Apr 17, 2012 at 10:27:12AM +0100, Julius Baxter wrote: >> On Mon, Apr 16, 2012 at 12:46 PM, Stefan Kristiansson >> <[email protected]> wrote: >> > On Mon, Apr 16, 2012 at 01:58:01PM +0300, Stefan Kristiansson wrote: >> >> On Sun, Apr 08, 2012 at 06:33:53AM +0100, Julius Baxter wrote: >> >> > diff --git a/arch/openrisc/cpu/cpu.c b/arch/openrisc/cpu/cpu.c >> >> > index 25cd624..fa43bf5 100644 >> >> > --- a/arch/openrisc/cpu/cpu.c >> >> > +++ b/arch/openrisc/cpu/cpu.c >> >> > @@ -151,7 +151,9 @@ extern void __reset(void); >> >> > int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) >> >> > { >> >> > disable_interrupts(); >> >> > - __reset(); >> >> > + __asm__("l.movhi r1,hi(__reset); \ >> >> > + l.ori r1,r1,lo(__reset); \ >> >> > + l.jr r1"); >> >> >> >> Isn't this jump generated by the compiler? >> >> I assume we can count on that doing the right thing? >> >> >> > >> > To clarify, the compiler can of course not know where __reset is, >> > but I would have for some reason expected it to emmit a l.jr sequence... >> > Checking is knowing, it does not. >> > I guess the real issue here is that the current toolchain doesn't complain >> > about it. >> > >> > But I still would like to get that __asm__ statement hidden away somewhere, >> > perhaps in a openrisc_jr inline function? >> > And/or a comment above it why we are doing it. >> >> I'm still a bit confused why we got this (a link-time failure due to >> the C-compiler emitting a "l.j __reset") and the only way I could fix >> it was by putting in an absolute jump. Maybe some C attribute or >> something could force the jump to be absolute (put in a register and >> then use l.jr) >> > > Googling a bit I find the -mlong-calls/mmno-long-calls option > (which can be turned on and off with #pragma long_calls and > #pragma long_calls_off) > > I don't know if our gcc port supports them. > > I presume compiling with -mlong-calls will turn all out of > file-scope calls into loadreg->l.jr calls, which perhaps is a bit overboard. > The pragmas are even more undesired, so I'm more and more inclined to > go with what you suggested in the patch. >
This is the error message when I have just __reset(): arch/openrisc/cpu/libor1200.o: In function `do_reset': /localhome/jules/git/u-boot/arch/openrisc/cpu/cpu.c:159:(.text+0x864): relocation truncated to fit: R_OR1K_INSN_REL_26 against symbol `__reset' defined in .vectors section in arch/openrisc/cpu/start.o Adding a #pragma long_calls before it did nothing (perhaps we don't support it in or1k?) -mlong-calls gives me: or1k-elf-ld: unrecognised emulation mode: long-calls Supported emulations: elf32or1k So perhaps my forced long call is the best option. Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
