Help needed for Blackfin eZKit533 BSP

[Allan Hessenflow]

Florian Kandzia wrote:
> A student doing her diploma thesis and I have been trying to build RTEMS for 
> the Blackfin BF533. We have an ADZS-BF533-EZLITE board and want to use the 
> "eZKit533" BSP.
> 
> What I did:
> - Setup MinGW/MSYS environment
> - Install precompiled bfin-rtems tools 
> (http://www.rtems.org/ftp/pub/rtems/mingw32/4.9/)
> - Compiled rtems-4.9.2 (from 
> http://www.rtems.org/ftp/pub/rtems/4.9.2/rtems-4.9.2.tar.bz2)
> 
> RTEMS and the extra examples 
> (http://www.rtems.org/ftp/pub/rtems/4.9.2/examples-4.9.2.tar.bz2) compile 
> well, but I have had no success executing the hello world executable in 
> skyeye or the real hardware.
> 
> Skyeye just exits with a segmentation fault. For the real hardware I use a 
> Wiggler cable and gdbproxy + gdb. This combination works perfectly for 
> loading and executing non-rtems elf files produced with bfin-elf toolchain. 
> I had no success executing any of the rtems executables that way.

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