From maxim at codesourcery.com Fri Oct 1 05:44:40 2010 From: maxim at codesourcery.com (Maxim Kuvyrkov) Date: Fri, 01 Oct 2010 09:44:40 +0400 Subject: [coldfire-gnu-discuss] CodeSourcery sprite + usbdevfs In-Reply-To: <0AEC8DCA-D7C6-46C6-9C42-BF468FEA73B4@idirect.net> References: <0AEC8DCA-D7C6-46C6-9C42-BF468FEA73B4@idirect.net> Message-ID: <4CA57548.9010204@codesourcery.com> On 9/29/10 6:03 PM, Matt Wilbur wrote: > I'm trying to use the CodeSourcery G++ Lite with a Freescale > MCF51CN128 tower kit. Right now, the m68k-elf-sprite segfaults, > thought I'm note quite sure why. However, what I can say for sure is > that it's obviously using the old usbdevfs to access the devices > files. I see, with strace, that sprite doesn't find what it needs > from the device that I know is for the OSBDM because the ioctl > fails. > > I'll see if there's an option to support usbdevfs it in the 2.6.32 > kernel configuration, but is there a plan to phase this out? The sprite uses libosbdmJM.so to communicate with the OSBDM probe, it does not use USB interface directly. AFAIK, the OSBDM driver uses libusb for low-level USB interface, so, possibly, this segfault is due to mismatch between the kernel and libusb versions. -- Maxim Kuvyrkov CodeSourcery maxim at codesourcery.com (650) 331-3385 x724 From maxim at codesourcery.com Sun Oct 3 16:18:23 2010 From: maxim at codesourcery.com (Maxim Kuvyrkov) Date: Sun, 03 Oct 2010 20:18:23 +0400 Subject: [coldfire-gnu-discuss] CodeSourcery sprite + usbdevfs In-Reply-To: References: <0AEC8DCA-D7C6-46C6-9C42-BF468FEA73B4@idirect.net> <4CA57548.9010204@codesourcery.com> Message-ID: <4CA8ACCF.8090507@codesourcery.com> On 10/3/10 7:36 PM, Wilbur, Matt wrote: >> The sprite uses libosbdmJM.so to communicate with the OSBDM probe, >> it does not use USB interface directly. AFAIK, the OSBDM driver >> uses libusb for low-level USB interface, so, possibly, this >> segfault is due to mismatch between the kernel and libusb >> versions. > > Can you either point to or provide sources for the linux version of > libosbdm you are using? As far as I can tell, Freescale supplies > Windows DLL code and others have made necessary patches to compile > under linux. I don't have libosbdm for Linux; I assumed Freescale might have released OSBDM driver for Linux and you were using it. > My suspicion about usbfs may have been a red herring, > as adding some printfs to the linux port of libosbdm finds the > device, so queries for the VID/PID seem to be fine. See printf > output below. > > Not sure I can research much more without violating the EULA. IIRC, libosbdm is under LGPL, so you can add debug output to it without violating EULA. We would only welcome efforts to get Linux OSBDM driver into usable state. BTW, adding '-vvv' to sprite command line will increase verbosity of sprite output. Regards, -- Maxim Kuvyrkov CodeSourcery maxim at codesourcery.com (650) 331-3385 x724 From maxim at codesourcery.com Sun Oct 3 17:03:37 2010 From: maxim at codesourcery.com (Maxim Kuvyrkov) Date: Sun, 03 Oct 2010 21:03:37 +0400 Subject: [coldfire-gnu-discuss] CodeSourcery sprite + usbdevfs In-Reply-To: References: <0AEC8DCA-D7C6-46C6-9C42-BF468FEA73B4@idirect.net> <4CA57548.9010204@codesourcery.com> <4CA8ACCF.8090507@codesourcery.com> Message-ID: <4CA8B769.8040105@codesourcery.com> On 10/3/10 8:56 PM, Wilbur, Matt wrote: > I had to specify 0 explicitly. I was previously invoke sprite as > > $ m68k-elf-sprite osbdm: twr-mcf51cn > > which segfaults. > > whereas > > $ m68k-elf-sprite osbdm://0 twr-mcf51cn > > works. > > Looks like perhaps a null-pointer was used somewhere when parsing the command line. At any rate, I think you'll agree that's a bug. Hm, I'm pretty sure I tested this scenario when working on OSBDM support, but, again, that was on Windows. I'll check what may be going wrong. Can you provide the libosbdm binary? Thanks, -- Maxim Kuvyrkov CodeSourcery maxim at codesourcery.com (650) 331-3385 x724 From mwilbur at idirect.net Sun Oct 3 15:36:10 2010 From: mwilbur at idirect.net (Wilbur, Matt) Date: Sun, 3 Oct 2010 11:36:10 -0400 Subject: [coldfire-gnu-discuss] CodeSourcery sprite + usbdevfs References: <0AEC8DCA-D7C6-46C6-9C42-BF468FEA73B4@idirect.net> <4CA57548.9010204@codesourcery.com> Message-ID: > The sprite uses libosbdmJM.so to communicate with the OSBDM probe, it > does not use USB interface directly. AFAIK, the OSBDM driver uses > libusb for low-level USB interface, so, possibly, this segfault is due > to mismatch between the kernel and libusb versions. Can you either point to or provide sources for the linux version of libosbdm you are using? As far as I can tell, Freescale supplies Windows DLL code and others have made necessary patches to compile under linux. My suspicion about usbfs may have been a red herring, as adding some printfs to the linux port of libosbdm finds the device, so queries for the VID/PID seem to be fine. See printf output below. Not sure I can research much more without violating the EULA. Matt m68k-elf-sprite: CodeSourcery ColdFire Debug Sprite (Sourcery G++ Lite 4.4-215) m68k-elf-sprite: Doing I/O to stdin/stdout m68k-elf-sprite: Memory [0x0,+0x20000) flash (cfm) m68k-elf-sprite: Memory [0x800000,+0x6000) ram osbdm_INIT: Usb initialised, found 1 device(s) Segmentation fault
_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________ 



From mwilbur at idirect.net  Sun Oct  3 16:49:28 2010
From: mwilbur at idirect.net (Wilbur, Matt)
Date: Sun, 3 Oct 2010 12:49:28 -0400
Subject: [coldfire-gnu-discuss] CodeSourcery sprite + usbdevfs
References: <0AEC8DCA-D7C6-46C6-9C42-BF468FEA73B4@idirect.net> <4CA57548.9010204@codesourcery.com>  <4CA8ACCF.8090507@codesourcery.com>
Message-ID: 


> I don't have libosbdm for Linux; I assumed Freescale might have released 
> OSBDM driver for Linux and you were using it.

You'd think so, wouldn't you.  But it looks like only the Windows CW tools support OSBDM.  Eclipse-based stuff for linux doesn't seem to.

> IIRC, libosbdm is under LGPL, so you can add debug output to it without 
> violating EULA.  We would only welcome efforts to get Linux OSBDM driver 
> into usable state.  BTW, adding '-vvv' to sprite command line will 
> increase verbosity of sprite output.

I'm quite certain now the segfault is caused by sprite itself.  To probe further, I'd have to step back into the sprite code, which I believe the license doesn't allow.

m68k-elf-sprite: CodeSourcery ColdFire Debug Sprite (Sourcery G++ Lite 4.4-215)
m68k-elf-sprite: Doing I/O to stdin/stdout
m68k-elf-sprite: Memory [0x0,+0x20000) flash (cfm)
m68k-elf-sprite: Memory [0x800000,+0x6000) ram
m68k-elf-sprite: debug target:Loaded OSBDM library 'libosbdmJM60.so'
osbdm_INIT: Usb initialised, found 1 device(s)
Segmentation fault

Matt

_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________ 



From mwilbur at idirect.net  Sun Oct  3 16:56:42 2010
From: mwilbur at idirect.net (Wilbur, Matt)
Date: Sun, 3 Oct 2010 12:56:42 -0400
Subject: [coldfire-gnu-discuss] CodeSourcery sprite + usbdevfs
References: <0AEC8DCA-D7C6-46C6-9C42-BF468FEA73B4@idirect.net> <4CA57548.9010204@codesourcery.com>  <4CA8ACCF.8090507@codesourcery.com>
Message-ID: 

> IIRC, libosbdm is under LGPL, so you can add debug output to it without 
> violating EULA.  We would only welcome efforts to get Linux OSBDM driver 
> into usable state.  BTW, adding '-vvv' to sprite command line will 
> increase verbosity of sprite output.

I have discovered the problem.  The Getting Started document is incorrect.  Quoting:

--- BEGIN QUOTE ---

5.7. Open Source BDM Devices

Open Source BDM (OSBDM) devices are supported. The OSBDM device type partitions the device-url as follows:
The number indicates the number of the OSBDM interface to connect to, counting from zero upwards. If the number is omitted, the default is to connect to the zeroth interface, which works well if you have only one OSBDM device connected to your computer.

--- END QUOTE ---

I had to specify 0 explicitly.  I was previously invoke sprite as 

$ m68k-elf-sprite osbdm: twr-mcf51cn

which segfaults.

whereas

$ m68k-elf-sprite osbdm://0 twr-mcf51cn

works.

Looks like perhaps a null-pointer was used somewhere when parsing the command line.  At any rate, I think you'll agree that's a bug.

Matt

_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________ 



From m8847 at abc.se  Mon Oct  4 09:03:13 2010
From: m8847 at abc.se (m8847)
Date: Mon, 04 Oct 2010 11:03:13 +0200
Subject: [coldfire-gnu-discuss] How to access =?UTF-8?Q?FLASHBAR=3F?=
In-Reply-To: <4CA4A7A1.20700@codesourcery.com>
References:  <4CA4A7A1.20700@codesourcery.com>
Message-ID: <0b7a9747abab6f5d22a00581104435af@oxygen>


Hi again, had a long (very needed) :) weekend since my question.

On Thu, 30 Sep 2010 16:07:13 +0100, Nathan Sidwell
 wrote:
> On 09/30/10 16:00, m8847 wrote:
>>
>> Hi,
>>
>> I am trying to get my flash programming to work. I have copied the
>> functions to RAM, but I need to clear the WP bit in FLASHBAR in order
to
>> program.
>>
>> I tried something like this from within a C function;
>>      asm( "move.l   #0x21,d0" );
>>      asm( "movec    %d0,0xC04" );
> 
> I think something like
> 
>     __asm__ volatile ("movec %0,FLASHBAR" : : "r"(0x21));
> 
> will do what you want.  You may need %% before FLASHBAR, I'm not sure.


OK, 
     __asm__ volatile ("movec %0,%%FLASHBAR" : : "r"(0x21));

compiles fine, but when I look in the assember window in the debugger, it
comes out as 
    moveq #33,%d0
    movec %d0,%rambar0


RAMBAR0?? Is there some relation here that I don't see? rambar ought to be
C05, flashbar C04.

Looking in the "registers" view, flashbar still says 0x0121, that is with
WP still set, and naturally my software gets a 'access' violation when
trying to write the first longword @ address 0. 


> 
> nathan



From mwilbur at idirect.net  Sun Oct  3 17:25:42 2010
From: mwilbur at idirect.net (Wilbur, Matt)
Date: Sun, 3 Oct 2010 13:25:42 -0400
Subject: [coldfire-gnu-discuss] CodeSourcery sprite + usbdevfs
References: <0AEC8DCA-D7C6-46C6-9C42-BF468FEA73B4@idirect.net> <4CA57548.9010204@codesourcery.com>  <4CA8ACCF.8090507@codesourcery.com>  <4CA8B769.8040105@codesourcery.com>
Message-ID: 



> Can you provide the libosbdm binary?

Attached.  I linked my libusb statically just to make life easier when I was debugging.  It's at 0.12.  Let me know if you want the dynamically liked version.

Matt

_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________ 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libosbdmJM60.so.0.0.1
Type: application/octet-stream
Size: 79146 bytes
Desc: libosbdmJM60.so.0.0.1
URL: 

From micke at beronius.com  Mon Oct  4 09:29:58 2010
From: micke at beronius.com (micke)
Date: Mon, 04 Oct 2010 11:29:58 +0200
Subject: [coldfire-gnu-discuss] How to access =?UTF-8?Q?FLASHBAR=3F?=
In-Reply-To: <0b7a9747abab6f5d22a00581104435af@oxygen>
References:  <4CA4A7A1.20700@codesourcery.com> <0b7a9747abab6f5d22a00581104435af@oxygen>
Message-ID: 

On Mon, 04 Oct 2010 11:03:13 +0200, m8847  wrote:
> 
> On Thu, 30 Sep 2010 16:07:13 +0100, Nathan Sidwell
>  wrote:
>> 
>>     __asm__ volatile ("movec %0,FLASHBAR" : : "r"(0x21));
>> 
>> will do what you want.  You may need %% before FLASHBAR, I'm not sure.


> OK, 
>      __asm__ volatile ("movec %0,%%FLASHBAR" : : "r"(0x21));
> 
> compiles fine, but when I look in the assember window in the debugger,
it
> comes out as 
>     moveq #33,%d0
>     movec %d0,%rambar0
> 
> 
> RAMBAR0?? Is there some relation here that I don't see? rambar ought to
be
> C05, flashbar C04.
> 
> Looking in the "registers" view, flashbar still says 0x0121, that is
with
> WP still set, and naturally my software gets a 'access' violation when
> trying to write the first longword @ address 0. 

OK, doing a memory view gives that the address is actually C04, i.e.
FLASHBAR, so the debugger probably has some old references to another
device (wild guess), which has rambar0 on this adddress.

Now I have to understand why in the world, the FLASHBAR does not get
written as it ought to..


- Micael


From thierrymaldague at gmail.com  Mon Oct  4 20:24:06 2010
From: thierrymaldague at gmail.com (thierry maldague)
Date: Mon, 04 Oct 2010 22:24:06 +0200
Subject: Codesourcery support of usbdm ?
Message-ID: <4CAA37E6.9080800@gmail.com>

  The USBDM (usbdm.sourceforge.net) seems more smart and less expensive 
that the original Fressecale Osbdm-JM60. Does CodeSourcery foresee 
something (sprite) else for this USBDM ??

Best regards

thierry




From maxim at codesourcery.com  Tue Oct  5 10:17:21 2010
From: maxim at codesourcery.com (Maxim Kuvyrkov)
Date: Tue, 05 Oct 2010 14:17:21 +0400
Subject: [coldfire-gnu-discuss] Codesourcery support of usbdm ?
In-Reply-To: <4CAA37E6.9080800@gmail.com>
References: <4CAA37E6.9080800@gmail.com>
Message-ID: <4CAAFB31.9060602@codesourcery.com>

On 10/5/10 12:24 AM, thierry maldague wrote:
> The USBDM (usbdm.sourceforge.net) seems more smart and less expensive
> that the original Fressecale Osbdm-JM60. Does CodeSourcery foresee
> something (sprite) else for this USBDM ??

USBDM looks interesting.  We will consider adding support for it in 
Sourcery G++ sprite when it becomes popular.

Meanwhile, the API of USBDM seems to be a superset of OSBDM API, so it 
may be possible to write a proxy OSBDM driver library that would 
implement OSBDM API requests in terms of USBDM.

Regards,

-- 
Maxim Kuvyrkov
CodeSourcery
maxim at codesourcery.com
(650) 331-3385 x724


From a.wehrmann at centersystems.com  Mon Oct 11 14:14:13 2010
From: a.wehrmann at centersystems.com (Andreas Wehrmann)
Date: Mon, 11 Oct 2010 16:14:13 +0200
Subject: systemcall select() seems to overwrite variables on the stack
Message-ID: <4CB31BB5.30709@centersystems.com>

Hello!

I recently came across a very annoying problem.
All this is happening with the latest version of the toolchain
(freescale-coldfire-m68k-linux-gnu-4.4-217.i686.rpm).

I have a multithreading application in which one thread simply calls 
select() in
a loop for a single descriptor and then updates some pointers in case of 
a successful return.
The problem now is: The first parameter to select seems to get destroyed 
in certain cases.
I have included the problematic code as an attachement.

The following happens: At the beginning of the thread, I declare the 
variable "nfds" and
initialize it with (select_fd + 1). But just after the return of 
select() the variable has some useless value (see output). This "useless 
value" is always the same!
The code produces the following output:

...
ldi_dev.c  before select_fd=67 | nfds = 68
ldi_dev.c  before select_fd=67 | nfds = -2141341700
ldi_dev.c  select(): Invalid argument
ldi_dev.c  exiting mainloop

The problem didn't occur with the old toolchain 
(freescale-coldfire-m68k-linux-gnu-4.2-35.i686.rpm).
The problem doesn't occur when compiling without the optimization flag 
(the problematic code gets compiled with -O2 by default).
The code works when using the poll() systemcall.

Since the variable "nfds" is only visible to this particular thread,
this cannot be a multithreading problem.
See the attached screenshot for ddd output.

Now what makes this even more confusing is, that the code seems to work 
when I uncomment the trace just after the call to select()...
I was assuming it might be a libc problem, because I came across this 
mailinglist entry:
http://sources.redhat.com/ml/libc-alpha/2003-06/msg00030.html

I hope it's not a bug in the compiler. We updated to the latest version 
of the toolchain because we ran across some mutex related problems with 
the old version (it seems that sometimes threads don't get waken up when 
they were waiting for a mutex that was locked the moment they tried to 
acquire the lock).

Best regards,
Andreas Wehrmann

-- 
Dipl.-Ing. (FH) Andreas Wehrmann
Software Development
--------------------------------------------------------------
Center Communication Systems GmbH
A-1210 Wien, Ignaz-K?ck-Stra?e 19
Sitz in Wien
FN 796 88p, Firmenbuchgericht Wien
www.centersystems.com

Tel.: +43 (0) 190 199 - 3616
Mobile: +43 (0) 664 884 75916
Fax: +43 (0) 190 199 - 2110
E-Mail: a.wehrmann at centersystems.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: value_change.jpg
Type: image/jpeg
Size: 171314 bytes
Desc: not available
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ldi_dev.c
Type: text/x-csrc
Size: 1988 bytes
Desc: not available
URL: 

From a.wehrmann at centersystems.com  Mon Oct 11 12:31:20 2010
From: a.wehrmann at centersystems.com (Andreas Wehrmann)
Date: Mon, 11 Oct 2010 14:31:20 +0200
Subject: systemcall select() seems to overwrite variables on the stack
Message-ID: <4CB30398.1060905@centersystems.com>

  Hello!

I recently came across a very annoying problem.
All this is happening with the latest version of the toolchain
(freescale-coldfire-m68k-linux-gnu-4.4-217.i686.rpm).

I have a multithreading application in which one thread simply calls 
select() in
a loop for a single descriptor and then updates some pointers in case of 
a successful return.
The problem now is: The first parameter to select seems to get destroyed 
in certain cases.
I have included the problematic code as an attachement.

The following happens: At the beginning of the thread, I declare the 
variable "nfds" and
initialize it with (select_fd + 1). But just after the return of 
select() the variable has some useless value (see output). This "useless 
value" is always the same!
The code produces the following output:

...
ldi_dev.c  before select_fd=67 | nfds = 68
ldi_dev.c  before select_fd=67 | nfds = -2141341700
ldi_dev.c  select(): Invalid argument
ldi_dev.c  exiting mainloop

The problem didn't occur with the old toolchain 
(freescale-coldfire-m68k-linux-gnu-4.2-35.i686.rpm).
The problem doesn't occur when compiling without the optimization flag 
(the problematic code gets compiled with -O2 by default).
The code works when using the poll() systemcall.

Since the variable "nfds" is only visible to this particular thread,
this cannot be a multithreading problem.
See the attached screenshot for ddd output.

Now what makes this even more confusing is, that the code seems to work 
when I uncomment the trace just after the call to select()...
I was assuming it might be a libc problem, because I came across this 
mailinglist entry:
http://sources.redhat.com/ml/libc-alpha/2003-06/msg00030.html

I hope it's not a bug in the compiler. We updated to the latest version 
of the toolchain because we ran across some mutex related problems with 
the old version (it seems that sometimes threads don't get waken up when 
they were waiting for a mutex that was locked the moment they tried to 
acquire the lock).

Best regards,
Andreas Wehrmann

-- 
Dipl.-Ing. (FH) Andreas Wehrmann
Software Development
--------------------------------------------------------------
Center Communication Systems GmbH
A-1210 Wien, Ignaz-K?ck-Stra?e 19
Sitz in Wien
FN 796 88p, Firmenbuchgericht Wien
www.centersystems.com

Tel.: +43 (0) 190 199 - 3616
Mobile: +43 (0) 664 884 75916
Fax: +43 (0) 190 199 - 2110
E-Mail: a.wehrmann at centersystems.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: value_change.jpg
Type: image/jpeg
Size: 171314 bytes
Desc: not available
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ldi_dev.c
Type: text/x-csrc
Size: 1987 bytes
Desc: not available
URL: 

From thomasaevans at optusnet.com.au  Mon Oct 11 13:47:08 2010
From: thomasaevans at optusnet.com.au (Tom Evans)
Date: Tue, 12 Oct 2010 00:47:08 +1100
Subject: Warning on use of Coldfire PIT (Programmable Interval Timer)
Message-ID: <4CB3155C.3050607@optusnet.com.au>

I follow the Coldfire Forum at Freescale.

I spotted a post on a problem someone was having with the PIT losing 
time, thought about it over the weekend and came up with an explanation.

Which has the consequence that possibly everyone using the Coldfire PITs 
is using them the wrong way, and as a result the PITs are dropping 
counts and giving inaccurate timing. I've found Linux source code that 
looks to be doing the wrong thing.

This is because the Reference Manual doesn't match what the hardware 
does when the PIT PCSR is written to when acknowledging an interrupt. 
The standard Freescale Coldfire PIT header files (that define the chip) 
make life difficult to get this right.

One line summary:

When you write to the PIT PCSR to clear the PIF bit, you have to do it 
with a BYTE WRITE and not a WORD WRITE, as the latter resets the 
prescaler and loses counts.

Details here (link will probably wrap, you may need to paste it into 
your browser in bits):

http://forums.freescale.com/t5/68K-ColdFire-reg-Microprocessors/PIT-hw-boo-boo-Read-if-you-need-accurate-PIT-CF/m-p/60597#M9572

-- 
=========
Tom Evans


From a.wehrmann at centersystems.com  Tue Oct 12 06:33:23 2010
From: a.wehrmann at centersystems.com (Andreas Wehrmann)
Date: Tue, 12 Oct 2010 08:33:23 +0200
Subject: [coldfire-gnu-discuss] systemcall select() seems to overwrite
 variables on the stack
In-Reply-To: <4CB31BB5.30709@centersystems.com>
References: <4CB31BB5.30709@centersystems.com>
Message-ID: <4CB40133.5090305@centersystems.com>

  A colleague and I managed to write a test program that reproduces a 
problem related to calling select(). In the test program, when compiled 
with optimization (-O2), the second call to select() never returns, not 
even after the timeout. This seems to be a very delicate problem, 
because if I change anything in the program it might work again. In this 
special case: when I remove the trace after the call to select(), the 
program works (with and without optimization enabled).
Because of this, I attached the assembler output from the compiler, plus 
a readable form and of course the source code of the test program + the 
makefile used to build the program.
I hope this helps.

Best regards,
Andreas Wehrmann

On 10/11/2010 04:14 PM, Andreas Wehrmann wrote:
> Hello!
>
> I recently came across a very annoying problem.
> All this is happening with the latest version of the toolchain
> (freescale-coldfire-m68k-linux-gnu-4.4-217.i686.rpm).
>
> I have a multithreading application in which one thread simply calls 
> select() in
> a loop for a single descriptor and then updates some pointers in case 
> of a successful return.
> The problem now is: The first parameter to select seems to get 
> destroyed in certain cases.
> I have included the problematic code as an attachement.
>
> The following happens: At the beginning of the thread, I declare the 
> variable "nfds" and
> initialize it with (select_fd + 1). But just after the return of 
> select() the variable has some useless value (see output). This 
> "useless value" is always the same!
> The code produces the following output:
>
> ...
> ldi_dev.c  before select_fd=67 | nfds = 68
> ldi_dev.c  before select_fd=67 | nfds = -2141341700
> ldi_dev.c  select(): Invalid argument
> ldi_dev.c  exiting mainloop
>
> The problem didn't occur with the old toolchain 
> (freescale-coldfire-m68k-linux-gnu-4.2-35.i686.rpm).
> The problem doesn't occur when compiling without the optimization flag 
> (the problematic code gets compiled with -O2 by default).
> The code works when using the poll() systemcall.
>
> Since the variable "nfds" is only visible to this particular thread,
> this cannot be a multithreading problem.
> See the attached screenshot for ddd output.
>
> Now what makes this even more confusing is, that the code seems to 
> work when I uncomment the trace just after the call to select()...
> I was assuming it might be a libc problem, because I came across this 
> mailinglist entry:
> http://sources.redhat.com/ml/libc-alpha/2003-06/msg00030.html
>
> I hope it's not a bug in the compiler. We updated to the latest 
> version of the toolchain because we ran across some mutex related 
> problems with the old version (it seems that sometimes threads don't 
> get waken up when they were waiting for a mutex that was locked the 
> moment they tried to acquire the lock).
>
> Best regards,
> Andreas Wehrmann
>


-- 
Dipl.-Ing. (FH) Andreas Wehrmann
Software Development
--------------------------------------------------------------
Center Communication Systems GmbH
A-1210 Wien, Ignaz-K?ck-Stra?e 19
Sitz in Wien
FN 796 88p, Firmenbuchgericht Wien
www.centersystems.com

Tel.: +43 (0) 190 199 - 3616
Mobile: +43 (0) 664 884 75916
Fax: +43 (0) 190 199 - 2110
E-Mail: a.wehrmann at centersystems.com

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Makefile
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_select.c
Type: text/x-csrc
Size: 1865 bytes
Desc: not available
URL: 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test_select_O2.s
URL: 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test_select_O2_readable.output
URL: 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test_select_unoptimized.s
URL: 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test_select_unoptimized_readable.output
URL: 

From a.wehrmann at centersystems.com  Tue Oct 12 06:40:10 2010
From: a.wehrmann at centersystems.com (Andreas Wehrmann)
Date: Tue, 12 Oct 2010 08:40:10 +0200
Subject: [coldfire-gnu-discuss] systemcall select() seems to overwrite
 variables on the stack
In-Reply-To: <4CB31BB5.30709@centersystems.com>
References: <4CB31BB5.30709@centersystems.com>
Message-ID: <4CB402CA.9090501@centersystems.com>

  Seems like attaching the naked text files was a bad idea, so here the 
zipped version...


On 10/11/2010 04:14 PM, Andreas Wehrmann wrote:
> Hello!
>
> I recently came across a very annoying problem.
> All this is happening with the latest version of the toolchain
> (freescale-coldfire-m68k-linux-gnu-4.4-217.i686.rpm).
>
> I have a multithreading application in which one thread simply calls 
> select() in
> a loop for a single descriptor and then updates some pointers in case 
> of a successful return.
> The problem now is: The first parameter to select seems to get 
> destroyed in certain cases.
> I have included the problematic code as an attachement.
>
> The following happens: At the beginning of the thread, I declare the 
> variable "nfds" and
> initialize it with (select_fd + 1). But just after the return of 
> select() the variable has some useless value (see output). This 
> "useless value" is always the same!
> The code produces the following output:
>
> ...
> ldi_dev.c  before select_fd=67 | nfds = 68
> ldi_dev.c  before select_fd=67 | nfds = -2141341700
> ldi_dev.c  select(): Invalid argument
> ldi_dev.c  exiting mainloop
>
> The problem didn't occur with the old toolchain 
> (freescale-coldfire-m68k-linux-gnu-4.2-35.i686.rpm).
> The problem doesn't occur when compiling without the optimization flag 
> (the problematic code gets compiled with -O2 by default).
> The code works when using the poll() systemcall.
>
> Since the variable "nfds" is only visible to this particular thread,
> this cannot be a multithreading problem.
> See the attached screenshot for ddd output.
>
> Now what makes this even more confusing is, that the code seems to 
> work when I uncomment the trace just after the call to select()...
> I was assuming it might be a libc problem, because I came across this 
> mailinglist entry:
> http://sources.redhat.com/ml/libc-alpha/2003-06/msg00030.html
>
> I hope it's not a bug in the compiler. We updated to the latest 
> version of the toolchain because we ran across some mutex related 
> problems with the old version (it seems that sometimes threads don't 
> get waken up when they were waiting for a mutex that was locked the 
> moment they tried to acquire the lock).
>
> Best regards,
> Andreas Wehrmann
>


-- 
Dipl.-Ing. (FH) Andreas Wehrmann
Software Development
--------------------------------------------------------------
Center Communication Systems GmbH
A-1210 Wien, Ignaz-K?ck-Stra?e 19
Sitz in Wien
FN 796 88p, Firmenbuchgericht Wien
www.centersystems.com

Tel.: +43 (0) 190 199 - 3616
Mobile: +43 (0) 664 884 75916
Fax: +43 (0) 190 199 - 2110
E-Mail: a.wehrmann at centersystems.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_select.zip
Type: application/zip
Size: 18050 bytes
Desc: not available
URL: 

From m8847 at abc.se  Wed Oct 13 15:31:24 2010
From: m8847 at abc.se (m8847)
Date: Wed, 13 Oct 2010 17:31:24 +0200
Subject: Chasing RAM - libc ..
Message-ID: <8923206bf6b93631d427f3ec16d14323@oxygen>

I am a bit short of RAM in my project, so I am trying to free up as much
as
possible, and I have seen that libc uses a lot, which I am unsure about.

I have rolled my own malloc()/free(), and thus should not use any library
version of them. I hope. And I only use C-code, no C++.

These are the worst consuming bits, but maybe these are things that need
to
be around(?) (or can I somehow tweak them away?):

.bss 0x2000fae4 0x194
/home/micke/CodeSourcery/Sourcery_G++/bin/../lib/gcc/m68k-elf/4.4.1/../../../../m68k-elf/lib/m5208/libc.a(lib_a-__atexitg.o)
 0x2000fae4 _cslibc_global__atexit
 0x2000fae8 _cslibc_global__atexit0

 .bss 0x2000fa6c 0x78
/home/micke/CodeSourcery/Sourcery_G++/bin/../lib/gcc/m68k-elf/4.4.1/../../../../m68k-elf/lib/m5208/libc.a(lib_a-stderr.o)
 0x2000fa6c _cslibc_global__stderr
 0x2000fa70 __stderr

 .bss 0x2000fcac 0x34
/home/micke/CodeSourcery/Sourcery_G++/bin/../lib/gcc/m68k-elf/4.4.1/../../../../m68k-elf/lib/m5208/libc.a(lib_a-mallocr.o)
 0x2000fcac __malloc_top_pad
 0x2000fcb0 __malloc_max_sbrked_mem
 0x2000fcb4 __malloc_max_total_mem
 0x2000fcb8 __malloc_current_mallinfo

 .data 0x20000350 0x410
/home/micke/CodeSourcery/Sourcery_G++/bin/../lib/gcc/m68k-elf/4.4.1/../../../../m68k-elf/lib/m5208/libc.a(lib_a-mallocr.o)
 0x20000350 __malloc_av_
 0x20000758 __malloc_trim_threshold
 0x2000075c __malloc_sbrk_base

 .data 0x20000248 0xf0
/home/micke/CodeSourcery/Sourcery_G++/bin/../lib/gcc/m68k-elf/4.4.1/../../../../m68k-elf/lib/m5208/libc.a(lib_a-_new.o)
 0x20000248 _cslibc_global__new



Any views on them are welcome!
 Micael


From dan at codesourcery.com  Wed Oct 13 15:34:34 2010
From: dan at codesourcery.com (Daniel Jacobowitz)
Date: Wed, 13 Oct 2010 11:34:34 -0400
Subject: [coldfire-gnu-discuss] Chasing RAM - libc ..
In-Reply-To: <8923206bf6b93631d427f3ec16d14323@oxygen>
References: <8923206bf6b93631d427f3ec16d14323@oxygen>
Message-ID: <20101013153433.GK8337@caradoc.them.org>

On Wed, Oct 13, 2010 at 05:31:24PM +0200, m8847 wrote:
>  .bss 0x2000fcac 0x34
> /home/micke/CodeSourcery/Sourcery_G++/bin/../lib/gcc/m68k-elf/4.4.1/../../../../m68k-elf/lib/m5208/libc.a(lib_a-mallocr.o)
>  0x2000fcac __malloc_top_pad
>  0x2000fcb0 __malloc_max_sbrked_mem
>  0x2000fcb4 __malloc_max_total_mem
>  0x2000fcb8 __malloc_current_mallinfo
> 
>  .data 0x20000350 0x410
> /home/micke/CodeSourcery/Sourcery_G++/bin/../lib/gcc/m68k-elf/4.4.1/../../../../m68k-elf/lib/m5208/libc.a(lib_a-mallocr.o)
>  0x20000350 __malloc_av_
>  0x20000758 __malloc_trim_threshold
>  0x2000075c __malloc_sbrk_base

Figure out what is bringing these in; you can tell from the -Map
output.  The most likely cause is that you've redefined malloc but not
calloc.

-- 
Daniel Jacobowitz
CodeSourcery


From carlos at codesourcery.com  Wed Oct 13 15:39:13 2010
From: carlos at codesourcery.com (Carlos O'Donell)
Date: Wed, 13 Oct 2010 11:39:13 -0400
Subject: [coldfire-gnu-discuss] Chasing RAM - libc ..
In-Reply-To: <8923206bf6b93631d427f3ec16d14323@oxygen>
References: <8923206bf6b93631d427f3ec16d14323@oxygen>
Message-ID: <4CB5D2A1.8050006@codesourcery.com>

On 10/13/2010 11:31 AM, m8847 wrote:
> I am a bit short of RAM in my project, so I am trying to free up as much
> as
> possible, and I have seen that libc uses a lot, which I am unsure about.
>
> I have rolled my own malloc()/free(), and thus should not use any library
> version of them. I hope. And I only use C-code, no C++.
>
> These are the worst consuming bits, but maybe these are things that need
> to
> be around(?) (or can I somehow tweak them away?):

Link with -Wl,-Map,linkermap.txt to generate a linker map. The start 
of the linker map shows *why* each object file was pulled into the 
executable e.g. a call to foo requires symbol bar pulling in bar.o.

 From the list of required symbols and dependencies you can track down 
why this data and zero-initialized data is required.

Cheers,
CArlos.
--
Carlos O'Donell
CodeSourcery
carlos at codesourcery.com
(650) 331-3385 x716


From m8847 at abc.se  Wed Oct 13 17:00:58 2010
From: m8847 at abc.se (m8847)
Date: Wed, 13 Oct 2010 19:00:58 +0200
Subject: [coldfire-gnu-discuss] Chasing RAM - libc ..
In-Reply-To: <4CB5D2A1.8050006@codesourcery.com>
References: <8923206bf6b93631d427f3ec16d14323@oxygen> <4CB5D2A1.8050006@codesourcery.com>
Message-ID: <8af149772818e74156a9bf08fcf6c3fa@oxygen>

On Wed, 13 Oct 2010 11:39:13 -0400, "Carlos O'Donell"
 wrote:
> On 10/13/2010 11:31 AM, m8847 wrote:
>> I am a bit short of RAM in my project, so I am trying to free up as
much
>> as
>> possible, and I have seen that libc uses a lot, which I am unsure
about.

> Link with -Wl,-Map,linkermap.txt to generate a linker map. The start 
> of the linker map shows *why* each object file was pulled into the 
> executable e.g. a call to foo requires symbol bar pulling in bar.o.
> 
>  From the list of required symbols and dependencies you can track down 
> why this data and zero-initialized data is required.


I don't dare to include the full output of the this onto this list, but
how would I back track from _cslibc_global__atexit below?

is it pulled from lib_a-_new.o, which is pulled from lib_a-cleanupg.o,
which is pulled from lib_a-dtoa.o and so on?


/home/micke/CodeSourcery/Sourcery_G++/bin/../lib/gcc/m68k-elf/4.4.1/../../../../m68k-elf/lib/m5208/libc.a(lib_a-vsprintf.o)
                              ./link/bin/ardebug.o (vsprintf)
/home/micke/CodeSourcery/Sourcery_G++/bin/../lib/gcc/m68k-elf/4.4.1/../../../../m68k-elf/lib/m5208/libc.a(lib_a-__atexitg.o)
                             
/home/micke/CodeSourcery/Sourcery_G++/bin/../lib/gcc/m68k-elf/4.4.1/../../../../m68k-elf/lib/m5208/libc.a(lib_a-reent.o)
(_cslibc_global__atexit)
/home/micke/CodeSourcery/Sourcery_G++/bin/../lib/gcc/m68k-elf/4.4.1/../../../../m68k-elf/lib/m5208/libc.a(lib_a-_new.o)
                             
/home/micke/CodeSourcery/Sourcery_G++/bin/../lib/gcc/m68k-elf/4.4.1/../../../../m68k-elf/lib/m5208/libc.a(lib_a-strtok.o)
(_cslibc_global__new)
/home/micke/CodeSourcery/Sourcery_G++/bin/../lib/gcc/m68k-elf/4.4.1/../../../../m68k-elf/lib/m5208/libc.a(lib_a-cleanupg.o)
                             
/home/micke/CodeSourcery/Sourcery_G++/bin/../lib/gcc/m68k-elf/4.4.1/../../../../m68k-elf/lib/m5208/libc.a(lib_a-reent.o)
(_cslibc_global___sdidinit)
/home/micke/CodeSourcery/Sourcery_G++/bin/../lib/gcc/m68k-elf/4.4.1/../../../../m68k-elf/lib/m5208/libc.a(lib_a-dtoa.o)
                             
/home/micke/CodeSourcery/Sourcery_G++/bin/../lib/gcc/m68k-elf/4.4.1/../../../../m68k-elf/lib/m5208/libc.a(lib_a-svfprintf.o)
(dtoa)


Thanks,
 Micael


From tarmo.kuuse at proekspert.ee  Thu Oct 14 16:41:52 2010
From: tarmo.kuuse at proekspert.ee (Tarmo Kuuse)
Date: Thu, 14 Oct 2010 19:41:52 +0300
Subject: Debugging code in Flash with SG++ Lite
Message-ID: <4CB732D0.20805@proekspert.ee>

Hi,

I wish to debug a trivial program (attached) running in MCF52223. 
Executing and debugging from internal RAM works flawlessly, 
unfortunately that is not the way forward (32 KiB is not meant to hold 
code). Code is supposed to execute from internal Flash and this is a 
problem for gdb:

Program received signal SIGTRAP, Trace/breakpoint trap.
0x0000000a in __cs3_interrupt_vector_coldfire ()

This is what I do:

1. Compile the program and export a binary

$ m68k-elf-gcc -g -mcpu=52223 -Tm52223evb-80-rom.ld main.c -o main.elf
$ m68k-elf-objcopy main.elf -O symbolsrec main.s19

2. Flash the binary using CFFlasher. Peek at binary in Flash - it looks 
like valid machine code.

3. Connect with GDB and try to run it:

$ m68k-elf-gdb main.elf
(gdb) target remote | m68k-elf-sprite pe: m52223evb-80
Remote debugging using | m68k-elf-sprite pe: m52223evb-80
m68k-elf-sprite: Opening P&E USBMultilink port 1 (USB1 : USB-ML-CF Rev C 
(PE6015852))
m68k-elf-sprite: Target reset
0x00000000 in __cs3_interrupt_vector_coldfire ()
(gdb) hbreak main.c:6
Hardware assisted breakpoint 1 at 0x59a: file main.c, line 6.
(gdb) continue
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x0000000a in __cs3_interrupt_vector_coldfire ()

I'm confused. The 52223 is not supposed to execute anything on address 
0xa. On reset, ColdFire loads the stack pointer from address 0x0 
(=0x20008000), then the program counter from address 0x4 (=0x00000418) 
and finally executes the instruction at PC. Address 0xa is not in the 
menu, so why does it generate a SIGTRAP? Debugging from Flash should not 
be so complicated - am I missing something?

Hardware is standard: M52223EVB and P&E Multilink. Toolchain is Sourcery 
G++ Lite 4.4-215 on Windows XP (using cygwin).

-- 
Kind regards,
Tarmo Kuuse
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: main.c
URL: 

From mark at codesourcery.com  Thu Oct 14 19:27:26 2010
From: mark at codesourcery.com (Mark Mitchell)
Date: Thu, 14 Oct 2010 12:27:26 -0700
Subject: [coldfire-gnu-discuss] Debugging code in Flash with SG++ Lite
In-Reply-To: <4CB732D0.20805@proekspert.ee>
References: <4CB732D0.20805@proekspert.ee>
Message-ID: <4CB7599E.5070000@codesourcery.com>

On 10/14/2010 9:41 AM, Tarmo Kuuse wrote:

> I'm confused. The 52223 is not supposed to execute anything on address
> 0xa. On reset, ColdFire loads the stack pointer from address 0x0
> (=0x20008000), then the program counter from address 0x4 (=0x00000418)
> and finally executes the instruction at PC.

How are you linking the program?  It's possible that something is
pointing at address 0xa, or failing to set up the initialization stuff
at address 0x0/0x4.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark at codesourcery.com
(650) 331-3385 x713


From mark at codesourcery.com  Thu Oct 14 20:04:45 2010
From: mark at codesourcery.com (Mark Mitchell)
Date: Thu, 14 Oct 2010 13:04:45 -0700
Subject: [coldfire-gnu-discuss] Debugging code in Flash with SG++ Lite
In-Reply-To: <4CB75CBB.80605@proekspert.ee>
References: <4CB732D0.20805@proekspert.ee> <4CB7599E.5070000@codesourcery.com> <4CB75CBB.80605@proekspert.ee>
Message-ID: <4CB7625D.2030802@codesourcery.com>

On 10/14/2010 12:40 PM, Tarmo Kuuse wrote:

> With the linker script. I'm only using this all-in-one command adapted
> from "Getting started guide". I assume it compiles and links without
> further instructions:
> 
> m68k-elf-gcc -g -mcpu=52223 -Tm52223evb-80-rom.ld main.c -o main.elf

That looks entirely reasonable.  I'm not sure what the problem might be.
 We'll see if Maxim has any ideas.  You might also want to post main.c
to increase our chances of being able to reproduce the problem.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark at codesourcery.com
(650) 331-3385 x713


From maxim at codesourcery.com  Sun Oct 24 21:03:18 2010
From: maxim at codesourcery.com (Maxim Kuvyrkov)
Date: Sun, 24 Oct 2010 17:03:18 -0400
Subject: [coldfire-gnu-discuss] systemcall select() seems to overwrite
 variables on the stack
In-Reply-To: <4CB40133.5090305@centersystems.com>
References: <4CB31BB5.30709@centersystems.com> <4CB40133.5090305@centersystems.com>
Message-ID: <4CC49F16.503@codesourcery.com>

On 10/12/10 2:33 AM, Andreas Wehrmann wrote:
> A colleague and I managed to write a test program that reproduces a
> problem related to calling select(). In the test program, when compiled
> with optimization (-O2), the second call to select() never returns, not
> even after the timeout.

Andreas,

I cannot reproduce this problem.  On M5485EVB board with 2.6.25 kernel I 
get:

[m5485 tmp]$ ./a.out
before select_fd=67 | nfds=68 | sec = 5 | usec = 0
after select_fd=67 | nfds=68 | sec = 0 | usec = 0 | retval = 0
before select_fd=67 | nfds=68 | sec = 5 | usec = 0
< a minute passes by >
[m5485 tmp]$

Can there be a problem in your kernel?

Regards,

-- 
Maxim Kuvyrkov
CodeSourcery
maxim at codesourcery.com
(650) 331-3385 x724


From thomasaevans at optusnet.com.au  Fri Oct 29 13:11:54 2010
From: thomasaevans at optusnet.com.au (Tom Evans)
Date: Sat, 30 Oct 2010 00:11:54 +1100
Subject: systemcall select() seems to overwrite variables on the stack
Message-ID: <4CCAC81A.3030407@optusnet.com.au>

On 10/12/10 2:33 AM, Andreas Wehrmann wrote:
 > A colleague and I managed to write a test program that reproduces
 > a problem related to calling select().
 > ...
 > ldi_dev.c  before select_fd=67 | nfds = 68
 > ldi_dev.c  before select_fd=67 | nfds = -2141341700

Which is 0x805DB7FC. That may point to the problem.

What does that point to in your map file? You should be able to find 
from the map (or with a bit of debugger help) what data structures are 
there. If that doesn't help, can you set a watchpoint on that in your 
debugger (or gdb) and see what accesses it? Or stop in the debugger and 
dump around that address to see what it looks like.

Less likely:

http://forums.freescale.com/t5/68K-ColdFire-reg-Microprocessors/5208-SDR-SDRAM-MOVEM-L-Instruction-Whacks-Stack-otherwise-SDRAM/m-p/3152

That was caused by setting the SDRAM controller to do an 8-byte burst 
where the hardware only supported 4, and this was only triggered by the 
movem.l. I think I've also heard of a similar problem where the stack 
pointer isn't initialised to a multiple of 4 bytes on some 
architectures. Check the stack pointer value when it fails. It might be 
16-bit-odd.

-- 
=========
Tom Evans