From thierrymaldague at hotmail.com  Mon Jul  6 13:55:19 2009
From: thierrymaldague at hotmail.com (thierry maldague)
Date: Mon, 6 Jul 2009 15:55:19 +0200
Subject: MCF51QE128 flash protection
Message-ID: <BAY123-DAV127843AD8D7E9050244AFBB42B0@phx.gbl>

Hello

I use Codesourcery Lite for Coldfire with a demo board MCF51QE128
When building an executable (elf) and programming it in Flash with P&E progcfv1_16K, it appears that the Flash is secured (bits SEC of NVOPT set to 10)

Is it any option to set these bits to 00 to leave the flash unsecured ?
Thx,

thierry maldague
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/coldfire-gnu-discuss/attachments/20090706/6a508ddf/attachment.html>

From maxim at codesourcery.com  Tue Jul  7 05:09:39 2009
From: maxim at codesourcery.com (Maxim Kuvyrkov)
Date: Tue, 07 Jul 2009 09:09:39 +0400
Subject: [coldfire-gnu-discuss] MCF51QE128 flash protection
In-Reply-To: <BAY123-DAV127843AD8D7E9050244AFBB42B0@phx.gbl>
References: <BAY123-DAV127843AD8D7E9050244AFBB42B0@phx.gbl>
Message-ID: <4A52D893.5030600@codesourcery.com>

thierry maldague wrote:
> Hello
>  
> I use Codesourcery Lite for Coldfire with a demo board MCF51QE128
> When building an executable (elf) and programming it in Flash with P&E 
> progcfv1_16K, it appears that the Flash is secured (bits SEC of NVOPT 
> set to 10)
> Is it any option to set these bits to 00 to leave the flash unsecured ?

Hi Thierry,

As far as I remember, there was a bug in the linker script in the last 
release of ColdFire ELF Lite toolchain.  This will be fixed in the next 
release.

--
Maxim K.
CodeSourcery


From list-bastian.schick at sciopta.com  Tue Jul  7 15:57:33 2009
From: list-bastian.schick at sciopta.com (42Bastian)
Date: Tue, 07 Jul 2009 17:57:33 +0200
Subject: Optimizer problem
Message-ID: <4A53706D.3000007@sciopta.com>

Hi,

following code:

typedef volatile unsigned long __vu32;
void bs()
{

  {
    extern void irq_handler(void);
    int i;
    __vu32 *tbl = (__vu32 *)0xffffff00;
    for(i = 0; i < 64; ++i){
      *tbl++ = (__vu32)irq_handler;
    }
  }
}

compiles to an endless loop if -Os is given:

        .type   bs, @function
bs:
        move.w #-256,%a0
        link.w %fp,#0
.L2:
        move.l #irq_handler,(%a0)+
        jra .L2
        .size   bs, .-bs
        .ident  "GCC: (Sourcery G++ Lite 4.3-54) 4.3.2"

Replacing __vu32 with unsigned long gives correct code.
(BTW: Test with ARM, same effect).

Am I doing something wrong here ??

-- 
42Bastian


From thierrymaldague at hotmail.com  Tue Jul  7 11:07:23 2009
From: thierrymaldague at hotmail.com (thierry maldague)
Date: Tue, 7 Jul 2009 13:07:23 +0200
Subject: [coldfire-gnu-discuss] MCF51QE128 flash protection
References: <BAY123-DAV127843AD8D7E9050244AFBB42B0@phx.gbl> <4A52D893.5030600@codesourcery.com>
Message-ID: <BAY123-DAV1243C642098CCA972F0F57B4280@phx.gbl>

Thank you, Maxim
I'm anxiously awaiting the next release, because debug of MCF51 in flash is 
impossible as the memory is locked.

Thierry

----- Original Message ----- 
From: "Maxim Kuvyrkov" <maxim at codesourcery.com>
To: "thierry maldague" <thierrymaldague at hotmail.com>
Cc: <coldfire-gnu-discuss at codesourcery.com>
Sent: Tuesday, July 07, 2009 7:09 AM
Subject: Re: [coldfire-gnu-discuss] MCF51QE128 flash protection


> thierry maldague wrote:
>> Hello
>>  I use Codesourcery Lite for Coldfire with a demo board MCF51QE128
>> When building an executable (elf) and programming it in Flash with P&E 
>> progcfv1_16K, it appears that the Flash is secured (bits SEC of NVOPT set 
>> to 10)
>> Is it any option to set these bits to 00 to leave the flash unsecured ?
>
> Hi Thierry,
>
> As far as I remember, there was a bug in the linker script in the last 
> release of ColdFire ELF Lite toolchain.  This will be fixed in the next 
> release.
>
> --
> Maxim K.
> CodeSourcery
> 



From syakovlev at thinksrs.com  Tue Jul  7 20:16:57 2009
From: syakovlev at thinksrs.com (Sergei)
Date: Tue, 07 Jul 2009 13:16:57 -0700
Subject: [coldfire-gnu-discuss] MCF51QE128 flash protection
In-Reply-To: <BAY123-DAV1243C642098CCA972F0F57B4280@phx.gbl>
References: <BAY123-DAV127843AD8D7E9050244AFBB42B0@phx.gbl> <4A52D893.5030600@codesourcery.com> <BAY123-DAV1243C642098CCA972F0F57B4280@phx.gbl>
Message-ID: <4A53AD39.8010004@thinksrs.com>

Hi Thierry,

You might not need to wait for new release.
Try to modify linker file to reserve 24 bytes right after end of vector 
table (addr 0x400).
To do this I use following (for MCF52235):
    LONG (0x01234567)
    LONG (0x89abcdef)
    LONG (0xffffffff)
    LONG (0x00000000)
    LONG (0x00000000)
    LONG (0xffffffff)

Best regards,
Sergei.



thierry maldague wrote:
> Thank you, Maxim
> I'm anxiously awaiting the next release, because debug of MCF51 in 
> flash is impossible as the memory is locked.
>
> Thierry
>
> ----- Original Message ----- From: "Maxim Kuvyrkov" 
> <maxim at codesourcery.com>
> To: "thierry maldague" <thierrymaldague at hotmail.com>
> Cc: <coldfire-gnu-discuss at codesourcery.com>
> Sent: Tuesday, July 07, 2009 7:09 AM
> Subject: Re: [coldfire-gnu-discuss] MCF51QE128 flash protection
>
>
>> thierry maldague wrote:
>>> Hello
>>>  I use Codesourcery Lite for Coldfire with a demo board MCF51QE128
>>> When building an executable (elf) and programming it in Flash with 
>>> P&E progcfv1_16K, it appears that the Flash is secured (bits SEC of 
>>> NVOPT set to 10)
>>> Is it any option to set these bits to 00 to leave the flash unsecured ?
>>
>> Hi Thierry,
>>
>> As far as I remember, there was a bug in the linker script in the 
>> last release of ColdFire ELF Lite toolchain.  This will be fixed in 
>> the next release.
>>
>> -- 
>> Maxim K.
>> CodeSourcery
>>
>
>
> __________ Information from ESET Smart Security, version of virus 
> signature database 4222 (20090707) __________
>
> The message was checked by ESET Smart Security.
>
> http://www.eset.com
>
>
>
>



__________ Information from ESET Smart Security, version of virus signature database 4222 (20090707) __________

The message was checked by ESET Smart Security.

http://www.eset.com




From thierrymaldague at hotmail.com  Wed Jul  8 09:20:25 2009
From: thierrymaldague at hotmail.com (thierry maldague)
Date: Wed, 8 Jul 2009 11:20:25 +0200
Subject: [coldfire-gnu-discuss] MCF51QE128 flash protection
References: <BAY123-DAV127843AD8D7E9050244AFBB42B0@phx.gbl> <4A52D893.5030600@codesourcery.com> <BAY123-DAV1243C642098CCA972F0F57B4280@phx.gbl> <4A53AD39.8010004@thinksrs.com>
Message-ID: <BAY123-DAV11FF141508B8C1B2673473B4290@phx.gbl>

Thank You very much, Sergei

Now, it works fine

Thierry

----- Original Message ----- 
From: "Sergei" <syakovlev at thinksrs.com>
To: "thierry maldague" <thierrymaldague at hotmail.com>
Cc: <coldfire-gnu-discuss at codesourcery.com>
Sent: Tuesday, July 07, 2009 10:16 PM
Subject: Re: [coldfire-gnu-discuss] MCF51QE128 flash protection


> Hi Thierry,
>
> You might not need to wait for new release.
> Try to modify linker file to reserve 24 bytes right after end of vector 
> table (addr 0x400).
> To do this I use following (for MCF52235):
>    LONG (0x01234567)
>    LONG (0x89abcdef)
>    LONG (0xffffffff)
>    LONG (0x00000000)
>    LONG (0x00000000)
>    LONG (0xffffffff)
>
> Best regards,
> Sergei.
>
>
>
> thierry maldague wrote:
>> Thank you, Maxim
>> I'm anxiously awaiting the next release, because debug of MCF51 in flash 
>> is impossible as the memory is locked.
>>
>> Thierry
>>
>> ----- Original Message ----- From: "Maxim Kuvyrkov" 
>> <maxim at codesourcery.com>
>> To: "thierry maldague" <thierrymaldague at hotmail.com>
>> Cc: <coldfire-gnu-discuss at codesourcery.com>
>> Sent: Tuesday, July 07, 2009 7:09 AM
>> Subject: Re: [coldfire-gnu-discuss] MCF51QE128 flash protection
>>
>>
>>> thierry maldague wrote:
>>>> Hello
>>>>  I use Codesourcery Lite for Coldfire with a demo board MCF51QE128
>>>> When building an executable (elf) and programming it in Flash with P&E 
>>>> progcfv1_16K, it appears that the Flash is secured (bits SEC of NVOPT 
>>>> set to 10)
>>>> Is it any option to set these bits to 00 to leave the flash unsecured ?
>>>
>>> Hi Thierry,
>>>
>>> As far as I remember, there was a bug in the linker script in the last 
>>> release of ColdFire ELF Lite toolchain.  This will be fixed in the next 
>>> release.
>>>
>>> -- 
>>> Maxim K.
>>> CodeSourcery
>>>
>>
>>
>> __________ Information from ESET Smart Security, version of virus 
>> signature database 4222 (20090707) __________
>>
>> The message was checked by ESET Smart Security.
>>
>> http://www.eset.com
>>
>>
>>
>>
>
>
>
> __________ Information from ESET Smart Security, version of virus 
> signature database 4222 (20090707) __________
>
> The message was checked by ESET Smart Security.
>
> http://www.eset.com
>
>
> 



From maxim at codesourcery.com  Wed Jul  8 16:32:10 2009
From: maxim at codesourcery.com (Maxim Kuvyrkov)
Date: Wed, 08 Jul 2009 20:32:10 +0400
Subject: [coldfire-gnu-discuss] MCF51QE128 flash protection
In-Reply-To: <4A53AD39.8010004@thinksrs.com>
References: <BAY123-DAV127843AD8D7E9050244AFBB42B0@phx.gbl> <4A52D893.5030600@codesourcery.com> <BAY123-DAV1243C642098CCA972F0F57B4280@phx.gbl> <4A53AD39.8010004@thinksrs.com>
Message-ID: <4A54CA0A.40108@codesourcery.com>

Sergei wrote:
> Hi Thierry,
> 
> You might not need to wait for new release.
> Try to modify linker file to reserve 24 bytes right after end of vector 
> table (addr 0x400).
> To do this I use following (for MCF52235):
>    LONG (0x01234567)
>    LONG (0x89abcdef)
>    LONG (0xffffffff)
>    LONG (0x00000000)
>    LONG (0x00000000)
>    LONG (0xffffffff)

Note, ColdFire V1 microcontrollers use different layout of CFM keys from 
the V2 devices.  You need to check the reference manual for the proper 
values.

--
Maxim


From list-bastian.schick at sciopta.com  Wed Jul  8 16:39:27 2009
From: list-bastian.schick at sciopta.com (42Bastian)
Date: Wed, 08 Jul 2009 18:39:27 +0200
Subject: [coldfire-gnu-discuss] Optimizer problem
In-Reply-To: <4A53706D.3000007@sciopta.com>
References: <4A53706D.3000007@sciopta.com>
Message-ID: <4A54CBBF.6020905@sciopta.com>

Hi

FYI: Entered as Bug 40679 in http://gcc.gnu.org/bugzilla/

-- 
42Bastian


From mark at codesourcery.com  Sun Jul 12 17:56:47 2009
From: mark at codesourcery.com (Mark Mitchell)
Date: Sun, 12 Jul 2009 10:56:47 -0700
Subject: New Release Available
Message-ID: <4A5A23DF.3060204@codesourcery.com>

CodeSourcery is pleased to announce the availability of the "Spring
2009" (*) Sourcery G++ Lite Edition release for ColdFire processors.
This is available for download from:

    http://www.codesourcery.com/gnu_toolchains/coldfire

New features in this release include:

    * Support for OSDBM debug hardware.

    * Support for new V1 CPUs: MCF51EM, MCF51CN, and MCF51AC.

    * Support for new V2 CPUs: M52259 (and MCF52259EVB evaluation board)
and other MCF5225x CPUs.

    * Support for new V3 CPUs: MCF53015EVB (and MCF5301EVB evaluation
board) and other MCF5301x CPUs.

    * GCC upgraded to 4.3.3; various other components upgraded.

Enjoy!

(*) We've been waiting for some paperwork to get this release done.

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




From m8847 at abc.se  Sun Jul 12 21:08:22 2009
From: m8847 at abc.se (Micael)
Date: Sun, 12 Jul 2009 23:08:22 +0200
Subject: [coldfire-gnu-discuss] New Release Available
In-Reply-To: <4A5A23DF.3060204@codesourcery.com>
References: <4A5A23DF.3060204@codesourcery.com>
Message-ID: <200907122308.22402.m8847@abc.se>


Excellent! 

Have been looking forward to this release ('259 support), thank you very much!

 Micael


On Sunday 12 July 2009 19.56.47 Mark Mitchell wrote:
> CodeSourcery is pleased to announce the availability of the "Spring
> 2009" (*) Sourcery G++ Lite Edition release for ColdFire processors.
> This is available for download from:
> 
>     http://www.codesourcery.com/gnu_toolchains/coldfire
> 
> New features in this release include:
> 
>     * Support for OSDBM debug hardware.
> 
>     * Support for new V1 CPUs: MCF51EM, MCF51CN, and MCF51AC.
> 
>     * Support for new V2 CPUs: M52259 (and MCF52259EVB evaluation board)
> and other MCF5225x CPUs.
> 
>     * Support for new V3 CPUs: MCF53015EVB (and MCF5301EVB evaluation
> board) and other MCF5301x CPUs.
> 
>     * GCC upgraded to 4.3.3; various other components upgraded.
> 
> Enjoy!
> 
> (*) We've been waiting for some paperwork to get this release done.
> 
> -- 
> Mark Mitchell
> CodeSourcery
> mark at codesourcery.com
> (650) 331-3385 x713
> 
>


From tarmo.kuuse at proekspert.ee  Tue Jul 14 14:14:22 2009
From: tarmo.kuuse at proekspert.ee (Tarmo Kuuse)
Date: Tue, 14 Jul 2009 17:14:22 +0300
Subject: Sprite's support for ST M29W160EB Flash
Message-ID: <4A5C92BE.6080901@proekspert.ee>

Hi!

We finally received the real boards which replace M5208EVBe as 
development platform. The product board has ST M29W160EB Flash devices.

I'm trying to create a board definition, but cannot find relevant Flash 
device configurations (tab 'Memory map').

The only information regarding flash devices is "Supported flash device 
types include cfm and cfi" (Getting started guide, ch 8.11, p 131). That 
doesn't tell me much. Could you please elaborate - what do 'cfm' and 
'cfi' represent? Which one should I use for my Flash?

A side note - adding more confusion is the screen shot on page 63 where 
Flash Device is surprisingly 'str91xfa'. That wasn't listed above.

The CodeSourcery version is 4.3-164 ColdFire ELF Personal.

--
Kind regards,
Tarmo Kuuse


From dan at codesourcery.com  Wed Jul 15 14:57:57 2009
From: dan at codesourcery.com (Daniel Jacobowitz)
Date: Wed, 15 Jul 2009 10:57:57 -0400
Subject: [coldfire-gnu-discuss] Sprite's support for ST M29W160EB Flash
In-Reply-To: <4A5C92BE.6080901@proekspert.ee>
References: <4A5C92BE.6080901@proekspert.ee>
Message-ID: <20090715145756.GG32508@caradoc.them.org>

On Tue, Jul 14, 2009 at 05:14:22PM +0300, Tarmo Kuuse wrote:
> Hi!
> 
> We finally received the real boards which replace M5208EVBe as
> development platform. The product board has ST M29W160EB Flash
> devices.
> 
> I'm trying to create a board definition, but cannot find relevant
> Flash device configurations (tab 'Memory map').
> 
> The only information regarding flash devices is "Supported flash
> device types include cfm and cfi" (Getting started guide, ch 8.11, p
> 131). That doesn't tell me much. Could you please elaborate - what do
> 'cfm' and 'cfi' represent? Which one should I use for my Flash?

CFM is the integrated boot flash in some ColdFire chips.  An ST part
is not going to be a CFM flash.  CFI is the Common Flash Interface; if
the chip supports CFI, the Sourcery G++ Sprite will be able to probe
for it and select the correct programming algorithm.

If the chip is not CFI-compliant, or uses an unknown programming
algorithm, then you have a couple of options; you can use an external
tool to program the flash (mark it as "ROM" in the Board Builder
instead of flash), or else contact CodeSourcery sales about adding
support for the chip.

Hope that helps!

-- 
Daniel Jacobowitz
CodeSourcery


From tarmo.kuuse at proekspert.ee  Thu Jul 16 10:41:46 2009
From: tarmo.kuuse at proekspert.ee (Tarmo Kuuse)
Date: Thu, 16 Jul 2009 13:41:46 +0300
Subject: [coldfire-gnu-discuss] Sprite's support for ST M29W160EB Flash
In-Reply-To: <20090715145756.GG32508@caradoc.them.org>
References: <4A5C92BE.6080901@proekspert.ee> <20090715145756.GG32508@caradoc.them.org>
Message-ID: <4A5F03EA.60800@proekspert.ee>

Daniel Jacobowitz wrote:
> On Tue, Jul 14, 2009 at 05:14:22PM +0300, Tarmo Kuuse wrote:
>> We finally received the real boards which replace M5208EVBe as
>> development platform. The product board has ST M29W160EB Flash
>> devices.
>>
>> I'm trying to create a board definition, but cannot find relevant
>> Flash device configurations (tab 'Memory map').
>>
>> The only information regarding flash devices is "Supported flash
>> device types include cfm and cfi" (Getting started guide, ch 8.11, p
>> 131). That doesn't tell me much. Could you please elaborate - what do
>> 'cfm' and 'cfi' represent? Which one should I use for my Flash?
> 
> CFM is the integrated boot flash in some ColdFire chips.  An ST part
> is not going to be a CFM flash.  CFI is the Common Flash Interface; if
> the chip supports CFI, the Sourcery G++ Sprite will be able to probe
> for it and select the correct programming algorithm.
> 
> If the chip is not CFI-compliant, or uses an unknown programming
> algorithm, then you have a couple of options; you can use an external
> tool to program the flash (mark it as "ROM" in the Board Builder
> instead of flash), or else contact CodeSourcery sales about adding
> support for the chip.

Thank you for the reply. Mystery solved.

Fortunately the Flash chip's spec claims that CFI is supported.

--
Kind regards,
Tarmo Kuuse