headers
Hu, Boris | 1 Jun 2003 11:21
Picon
Favicon

FW: [PATCH] Native POSIX Thread Library(NPTL) ARM SupportingPatches (1/3)


-----Original Message-----
From: Philip Blundell [mailto:pb <at> nexus.co.uk]
Sent: 2003?5?29? 22:15
To: Hu, Boris
Cc: Libc-Alpha (E-mail); NPTL list (E-mail)
Subject: Re: [PATCH] Native POSIX Thread Library(NPTL) ARM SupportingPatches (1/3)

On Fri, 2003-05-23 at 09:23, Hu, Boris wrote:
> However, TLS is absent in arm toolchain. So here is a work-around way. 
> In the linux kernel, a thread register is simulated by an additional field(pd_addr) 
> to thread_struct and two system calls(sys_get/set_thread_area()).  __thread 
> keyword is disabled in glibc and nptl. Moreover, some code related TLS in nptl 
> is protected by the glibc macro USE_TLS. 

Thanks for working on this.

I wonder what the performance impact is of having a system call in
THREAD_SELF.  If it turns out to be too great, it may be possible to
reduce the overhead by adding some more support to the kernel.  What
I've been thinking of is a way for applications to supply a pointer to
the kernel (via a new system call), and have it store the current thread
ID at that address during context switch.  That way, retrieving the
thread descriptor would be just a regular memory access.  I think it'd
only add a handful of cycles to the context switch path, and that's a
comparatively heavyweight operation already so it would probably
disappear in the noise.

p.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hu, Boris | 1 Jun 2003 11:22
Picon
Favicon

FW: [PATCH] Native POSIX Thread Library(NPTL) ARM SupportingPatches (1/3) 4


-----Original Message-----
From: Hu, Boris 
Sent: 2003?5?30? 16:06
To: 'Philip Blundell'
Cc: Jakub Jelinek; Perez-Gonzalez, Inaky; 'Daniel Jacobowitz'; 'Wolfram Gloger'; Libc-Alpha
(E-mail); NPTL list (E-mail)
Subject: RE: [PATCH] Native POSIX Thread Library(NPTL) ARM SupportingPatches (1/3)

It sounds good. :) 

And we could use the same system sys_set/get_thread_area(). :p

Here is the draft modication. Do I miss or misunderstand sth? If no,
I could update the kernel & glibc patch. thanks. 

glibc&nptl : 
struct pthread * __thread_self; 
#define THREAD_SELF (__thread_self)

arm-kernel: 

pd_addr:  __thread_self
pd_addr_addr: &__thread_self
It is the duty of kernel to update the content of pd_addr_addr. 

struct user_desc {
	void * pd_addr;
	void * pd_addr_addr;
}
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hu, Boris | 1 Jun 2003 11:22
Picon
Favicon

FW: [PATCH] Native POSIX Thread Library(NPTL) ARM Supporting Patches (1/3) 3


-----Original Message-----
From: Philip Blundell [mailto:pb <at> nexus.co.uk]
Sent: 2003?5?29? 22:29
To: Jakub Jelinek
Cc: Hu, Boris; Libc-Alpha (E-mail); NPTL list (E-mail)
Subject: Re: [PATCH] Native POSIX Thread Library(NPTL) ARM Supporting Patches (1/3)

On Thu, 2003-05-29 at 15:21, Jakub Jelinek wrote:
> If ARMs are never going to be SMP, this seems like good idea
> if there are no spare registers.

Yep, there are indeed no spare registers.  

Right now, there are no SMP ARM systems.  We might see some in the
future, but there is always the option of locking down a line in the
d-cache for use as CPU-local scratchpad memory.  I guess if that's a
possibility, it might be better for the kernel to pick the address of
the thread ID variable.

p.

-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ/Etiquette:       http://www.arm.linux.org.uk/armlinux/mailinglists.php
Permalink | Reply | 0 comments |
headers
Hu, Boris | 1 Jun 2003 11:21
Picon
Favicon

FW: [PATCH] Native POSIX Thread Library(NPTL) ARM Supporting Patches (1/3) 2


-----Original Message-----
From: Jakub Jelinek [mailto:jakub <at> redhat.com]
Sent: 2003?5?29? 22:22
To: Philip Blundell
Cc: Hu, Boris; Libc-Alpha (E-mail); NPTL list (E-mail)
Subject: Re: [PATCH] Native POSIX Thread Library(NPTL) ARM Supporting Patches (1/3)

On Thu, May 29, 2003 at 03:15:23PM +0100, Philip Blundell wrote:
> On Fri, 2003-05-23 at 09:23, Hu, Boris wrote:
> > However, TLS is absent in arm toolchain. So here is a work-around way. 
> > In the linux kernel, a thread register is simulated by an additional field(pd_addr) 
> > to thread_struct and two system calls(sys_get/set_thread_area()).  __thread 
> > keyword is disabled in glibc and nptl. Moreover, some code related TLS in nptl 
> > is protected by the glibc macro USE_TLS. 
> 
> Thanks for working on this.
> 
> I wonder what the performance impact is of having a system call in
> THREAD_SELF.  If it turns out to be too great, it may be possible to
> reduce the overhead by adding some more support to the kernel.  What
> I've been thinking of is a way for applications to supply a pointer to
> the kernel (via a new system call), and have it store the current thread
> ID at that address during context switch.  That way, retrieving the
> thread descriptor would be just a regular memory access.  I think it'd
> only add a handful of cycles to the context switch path, and that's a
> comparatively heavyweight operation already so it would probably
> disappear in the noise.

If ARMs are never going to be SMP, this seems like good idea
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hu, Boris | 1 Jun 2003 11:24
Picon
Favicon

FW: [PATCH] Native POSIX Thread Library(NPTL) ARMSupportingPatches (1/3) 5


Is there any more efficient way to simulate the thread register in ARM? 

thanks. :)

boris

-----Original Message-----
From: Philip Blundell [mailto:pb <at> nexus.co.uk]
Sent: 2003?5?31? 5:42
To: Hu, Boris
Cc: Libc-Alpha (E-mail); NPTL list (E-mail)
Subject: RE: [PATCH] Native POSIX Thread Library(NPTL) ARMSupportingPatches (1/3)

On Fri, 2003-05-30 at 09:05, Hu, Boris wrote:
> Here is the draft modication. Do I miss or misunderstand sth? If no,
> I could update the kernel & glibc patch. thanks. 

Yup, that looks like what I had in mind.  The only thing we need to
decide about is the multiprocessor case that Jakub mentioned.  If we
need to support that, and it has to be done by dcache lockdown, it would
probably be best if the kernel got to choose the location of the thread
variable, rather than the application.

It might be worth asking the good folk on the linux-arm-kernel list for
their views.  I suppose the other thing to do would be to try to collate
some benchmarks to find out how often threaded programs tend to call
THREAD_SELF(), so we can determine how much of a performance issue this
will actually be.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dag Gruneau | 2 Jun 2003 08:44

Development on ixdp425 - question on policy

Hi all,
I am using
2.4.19 , the patch 2.4.19.rmk7 and the patch 2.4.19.rmk7.ds2 plus patches from Intel.

Questions/suggestion to rmk7 and rmk7.ds2 do they both belong to this list?

Intel has propriarity (YUK!) patches to the kernel, were do discussions /questions about them belong?

Do anyone of you if  there is a mailinglist for those using IXP425 and thedevelopment board ixdp425.

/Dag

-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ/Etiquette:       http://www.arm.linux.org.uk/armlinux/mailinglists.php
Permalink | Reply | 2 comments |
headers
Deepak Saxena | 2 Jun 2003 09:04

Re: Development on ixdp425 - question on policy

On Jun 02 2003, at 08:44, Dag Gruneau was caught saying:
> Hi all,
> I am using
> 2.4.19 , the patch 2.4.19.rmk7 and the patch 2.4.19.rmk7.ds2 plus patches from Intel.
> 
> Questions/suggestion to rmk7 and rmk7.ds2 do they both belong to this list?

Yes, all kernel related questions related to any linux ports that are
available to the community belong here. If you have a port from a
specific vendor, please contact that vendor for questions.

> Intel has propriarity (YUK!) patches to the kernel, were do discussions /questions about them belong?

You need to contact your Intel support rep.  There are a few people on
here that might be able to help with some questions on how to get
the environment properly setup, but anything beyond that should go
to Intel.

~Deepak

--

-- 
Deepak Saxena
MontaVista Software - Powering the Embedded Revolution - www.mvista.com

-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ/Etiquette:       http://www.arm.linux.org.uk/armlinux/mailinglists.php
Permalink | Reply | 1 comment |
headers
Dag Gruneau | 2 Jun 2003 10:27

Re: Development on ixdp425 - question on policy

On Monday 02 June 2003 09:04, Deepak Saxena wrote:

> Yes, all kernel related questions related to any linux ports that are
> available to the community belong here. If you have a port from a
> specific vendor, please contact that vendor for questions.
>

Ok, and as usual the problems arise at the boundaries ;-)

Kernel side:

the file /asm-arm/arch-ixp425/ixp425.h is not self contained, some header files need to be imported
before it.

 the lines: 

#ifndef __ASSEMBLY__
extern int (*ixp425_pci_read)(u32 addr, u32 cmd, u32* data);
extern int ixp425_pci_write(u32 addr, u32 cmd, u32 data);
extern void ixp425_pci_init(void *);
#endif

generates an error when compiling the Intel Accessl Libraries, and would generate an error when
included by anyone else if not the correct header files were included before. 

IMHO a better place to declare the prototypes would be  in arch/arm/mach-ixp425/ixp425-pci.h (non existing)

Intel side:
change the Intel code accordingly and include the required header files.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Velyo Chanin | 2 Jun 2003 13:34

trizeps2 mt6n - serial port 1 (UART)

I am running linux-2.4.19-rmk7-pxa1 on MT6N/Trizep II
development platform.

I tried to connect Serial port 1 (UART, RS232, connetor J18) to a PC,
but read/writes have no effect. I am testing with cat
and echo. I examined the pins with osciloscope, and there was no signal.

Serial port 3 is the same and I am using it happily as a
system console.

Maybe the port is not initialized and I don't know how to do it.
Here are the kernel log messages:
...
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with no serial options enabled
ttyS00 at 0x0000 (irq = 15) is a PXA UART     --> system console
ttyS01 at 0x0000 (irq = 14) is a PXA UART
ttyS02 at 0x0000 (irq = 13) is a PXA UART
Real Time Clock Driver v1.10e
...

Any suggestions?
Thanks.

Velyo

-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ/Etiquette:       http://www.arm.linux.org.uk/armlinux/mailinglists.php
(Continue reading)

Permalink | Reply | 1 comment |
headers
De Cock, Luc | 2 Jun 2003 13:53

RE: trizeps2 mt6n - serial port 1 (UART)

> I tried to connect Serial port 1 (UART, RS232, connetor J18) to a PC,
> but read/writes have no effect. I am testing with cat
> and echo. I examined the pins with osciloscope, and there was 
> no signal.
J18 is linked to the COM1 UART op top of the board (DB9 connector).
So it should by device
/dev/ttyS0

Luc

­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­ 
This e­mail and any files transmitted with it are confidential and/or
legally privileged and intended solely for the use of the individual or
entity to whom they are addressed. If you are not the addressee indicated in
this e­mail (or responsible for the delivery of the e­mail to such person)
be advised that you have received this e­mail in error, and that any use,
dissemination, forwarding, printing, or copying of this e­mail is strictly
prohibited. 
If you have received this e­mail in error please notify the sender by reply
e­mail and then immediately permanently delete it and all copies from your
system. 
Whilst we maintain virus checks, we accept no liability for viruses
introduced from this e­mail. 

-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ/Etiquette:       http://www.arm.linux.org.uk/armlinux/mailinglists.php
Permalink | Reply | 1 comment |

Gmane