GeSys on Virtex BSP

[Till Straumann]

pierre kestener wrote:
> Hello,
>
> I am trying to build GeSys for bsp virtex.
> I am using the rtems 4.9 toolchain and cvs sources.
>
> My problem is that when ldep is processing the symbols files, there is 
> an error :
> Unknown symbol type 'N' (line 101)
> Error scanning o-optimize/librtemsbsp.nm
>
> line 101 of that file is : __rtems_entry_point N 00000000
>
> Is this problem related to the specificity of the virtex bsp linker 
> script (compared to other powerpc bsp) ?
>   
Well, I ran into the same issue, actually.

It turns out (a little simplified) that gnu 'nm' marks any symbol that 
is not
in a 'well-known' section as 'N' (debugging symbol) (__rtems_entry_point
is in a '.entry' section which doesn't qualify as 'well-known').

I have modified 'ldep' so that is accepts 'N'-type symbols but this
modification has not been released yet.

As a workaround you can edit the '.nm' file and remove
the __rtems_entry_point line and re-run 'ldep' again.

__rtems_entry_point will not be available in the cexpsh symbol table
but that should be acceptable.

FWIW: I was able to build+run GeSys on virtex/rtems-4.9 but unfortunately,
I didn't have time to release new versions of GeSys or cexp yet and
I'm currently on vacation. I hope to release new versions (at least of 
cexpsh)
soon after 4.9 has been cut.

HTH
-- Till

PS: Depending on your memory configuration you will run into another
problem on the virtex: If you have more than 32MB of memory then
you will sometimes not be able to load object-modules because gcc
normally emits branch instructions which can only reach addresses
within +/- 32MB. If the module is loaded farther from the main
system (which is residing at address 0) or from other modules then
the cexpsh linker produces an error.
There are three solutions to this problem:

  a) reduce available memory to 32MB. Application can create an RTEMS 
'region'
      with the rest of memory and use it via the region manager.
  b) some BSPs implement 'sbrk' and pretend to only have 32MB of memory
      at initialization. Loading modules then works. If more memory is 
needed
      by the application 'malloc' will eventually call 'sbrk' and the 
BSP-provided
      'sbrk' then hands over the full amount of memory to the malloc heap.
      After this, loading more modules may fail.
  c) cexpsh reserves space in the lowest 32MB for modules 'text' segments
      and uses a separate allocator for module text.
      This approach is implemented by the development version of cexpsh and
      currently under test.
 d) compile all modules with -mlongcall. Note however, that this gcc option
      may disappear (be ignored) in the future [gcc manual says so].
> Thank for your help.
>
> Pierre Kestener.
>
>
>