Help needed for Blackfin eZKit533 BSP

[Florian Kandzia]

Allan,

thanks for your ideas. You prevented me from giving up.

I already knew about the problem with section "l1code" because I read that 
in an earlier post you sent to the mailing list in 2008 I think. I changed 
the section in rtems 4.9.2 and expected that to work with skyeye, which it 
doesn't. It also wouldn't produce any good results on the hardware (at least 
with my setup).

Now I tried the whole thing with rtems 4.8.0. Because it comes with an older 
version of gcc, the executables run well on skyeye. Of course, only after 
changing start.S. The funny thing is, these executables also run on the real 
hardware, when I load them with bfin-elf-gdb + bfin-elf-gdbproxy.

Being happy now, I re-tried the same procedure with rtems 4.9.2 again, and 
that version fails.

For me it's OK that 4.8.0 works, I can stick to that version. Maybe I'll 
also try the current CVS version, but there is no real need for me.
Would it be of any use for you if you knew whether the current CVS code runs 
on my ezkit?

Florian

>
> I don't have an eZKit533 so can't provide a known good image, but I
> can make a wild guess at the problems you're having.  That BSP puts
> its startup code in the section "l1code" (which is setup in the linker
> file to be in on-chip SRAM), which skyeye doesn't load.  CVS head
> includes the following in libbsp/bfin/shared/start/start.S to change
> that so the startup code will end up in a section that will be loaded:
>
> #if (BFIN_ON_SKYEYE)
>    .section .init
> #else
>    .section .l1code
> #endif
>
> I don't know if that change was in time for 4.9.x or not.  Whether or not
> that change is in the version you're using, I'd guess that you might be
> having the same problem when loading it with gdb on the real hardware;
> moving the code in start.S into a section that gets loaded should solve 
> it.
>
> For what its worth, I use the bf537Stamp BSP, and load the executable 
> using
> u-boot.  That BSP does not put its startup code in on-chip SRAM (I don't
> know why the eZKit533 BSP does that; it expects the SDRAM controller to
> have been initialized and the rest of the RTEMS code already loaded into
> SDRAM before control is passed to the code in start.S anyway, so I don't 
> see
> any reason to put that initial code outside of SDRAM).
>
> As for running on skyeye, you may be having the problem above if 4.9.2
> does not include the BFIN_ON_SKYEYE test or you didn't build with that
> option.  You may also be having a problem with the tools compatibility 
> with
> skyeye; recent versions of gcc generate bfin opcodes that skyeye hasn't
> implemented (at least as of several months ago when I last tried any of
> this; it's possible skyeye has been updated to support those opcodes by
> now).
>
> allan
>
> -- 
> Allan N. Hessenflow      allanh at kallisti.com