GeSys on Virtex BSP

[pierre kestener]

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.


Pierre Kestener.


Till Straumann a écrit :
> 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.
>>
>>
>>   
>