uClinux microblaze port

Alejandro Cabrera | 6 Oct 2011 16:13

Re: [microblaze-linux] About toolchain built against 2.6.33 or greater kernel headers

Hi John

Indeed, I'm using the Petalinux SDK donation v1.3 (2.6.31) with the 
toolchain inside it. I was working with kernel version 2.6.35 and did 
all posix named semaphore (PNS) tests against it. After your comments I 
rollback the kernel version to the 2.6.31 (sdk v1.3) and after config 
the kernel and mount the filesystem (/dev/shm, as Edgar said)  the 
problem still happen.

I'm linking a sem_test application with pthread library that contains 
(at least it must) the posix named semaphore implementation. I 
disassamble this library with objdump and look for sem_open code and it 
has only 21 instructions, for example the x86 sem_open implementation 
has 241 instructions. The rest of PNS functions (sem_close), sem_unlik 
have a code very similar to sem_open. Another clue that tell me that the 
libpthread.so doesn't contain a functional sem_open implementation is 
the fact that the __sem_search function is not implemented, this 
function is called from sem_open to obtain the mount point of shm 
filesystem (mounted in /dev/shm as default).

What I can do ?
Can I know the kernel version against the toolchain was built ?

Best regards and thanks for your attention
Alejandro

On 10/5/2011 8:14 PM, John Williams wrote:
> Hi Alejandro,
>
> You are using a PetaLinux SDK donation, correct?  SysV IPC works, but

(Continue reading)

headers

John Williams | 7 Oct 2011 01:45

Re: [microblaze-linux] About toolchain built against 2.6.33 or greater kernel headers

Hi Alejandro,

The toolchain is built always against the same kernel that we ship in
the PetaLinux release.  I'd have to check but it may be that the IPC
support was not enabled back around the 1.3 release, but it is
definitely working in 2.1

Please contact us directly and we'll send you the latest release for you to try.

Regards,

John

On Fri, Oct 7, 2011 at 12:13 AM, Alejandro Cabrera
<acabrera@...> wrote:
> Hi John
>
> Indeed, I'm using the Petalinux SDK donation v1.3 (2.6.31) with the
> toolchain inside it. I was working with kernel version 2.6.35 and did all
> posix named semaphore (PNS) tests against it. After your comments I rollback
> the kernel version to the 2.6.31 (sdk v1.3) and after config the kernel and
> mount the filesystem (/dev/shm, as Edgar said)  the problem still happen.
>
> I'm linking a sem_test application with pthread library that contains (at
> least it must) the posix named semaphore implementation. I disassamble this
> library with objdump and look for sem_open code and it has only 21
> instructions, for example the x86 sem_open implementation has 241
> instructions. The rest of PNS functions (sem_close), sem_unlik have a code
> very similar to sem_open. Another clue that tell me that the libpthread.so
> doesn't contain a functional sem_open implementation is the fact that the

(Continue reading)

headers

Alejandro Cabrera | 2 Nov 2011 17:52

Re: [microblaze-linux] About toolchain built against 2.6.33 or greater kernel headers

Hi John,

I receive successfully the sdk 2.1 and after enabling the parameters in 
kernel config:

CONFIG_SYSVIPC=y
CONFIG_SHMEM=y
CONFIG_TMPFS=y

And mount tmpfs at /dev/shm as Edgar said.
When test the functionality with a test application it returns the same error "Function not implemented".
I'm trying to use the function sem_open and it return ENOSYS in errno.

I'm building the test application with -lpthread and it work fine in a host Ubuntu PC.

I used "microblaze-unknown-linux-gnu-objdump -d" against libpthread (static and shared version) to
see the sem_open asm code, and it looks similar to that I saw in libpthread asm code at version 1.3. I attach
you the test application if you want to test it, to be sure.

Best Regards
Alejandro

On 10/6/2011 7:45 PM, John Williams wrote:
> Hi Alejandro,
>
> The toolchain is built always against the same kernel that we ship in
> the PetaLinux release.  I'd have to check but it may be that the IPC
> support was not enabled back around the 1.3 release, but it is
> definitely working in 2.1
>

(Continue reading)