GeSys on Virtex BSP
pierre.kestener at cea.fr
Thu Aug 7 13:13:18 UTC 2008
Thanks again for your valuable help.
I was able to compile and run Gesys/rtems.exe on target.
I have now another problem that i will try to investigate.
At GeSys boot, network initialization fails with:
Can't get network cluster memory.
that is inside bsd_init().
In addition, the network demo runs fine.
Till Straumann a écrit :
> pierre kestener wrote:
>> 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
> 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
> soon after 4.9 has been cut.
> -- 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
> 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
> by the application 'malloc' will eventually call 'sbrk' and the
> '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
> currently under test.
> d) compile all modules with -mlongcall. Note however, that this gcc
> may disappear (be ignored) in the future [gcc manual says so].
>> Thank for your help.
>> Pierre Kestener.
More information about the users