[Bug 1001561] New: Internal flash driver for Freescale TWR-K60N512 board

classic Classic list List threaded Threaded
69 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

[Bug 1001561] Internal flash driver for Freescale TWR-K60N512 board

bugzilla-daemon
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001561

--- Comment #17 from Ilija Kocho <[hidden email]> 2012-05-15 09:42:15 BST ---
(In reply to comment #16)
[snip]
>
> I just receive an email from the FSF stating that my assignment is complete. Do
> I need to do anything now ?
>
> Nicolas

Thank you for information Nicolas. Nothing else is required from you regarding
assignment. We are now expecting information from FSF...

Ilija

--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug 1001561] Internal flash driver for Freescale TWR-K60N512 board

bugzilla-daemon
In reply to this post by bugzilla-daemon
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001561

Jonathan Larmour <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1723|                            |assignment+
               Flag|                            |

--- Comment #18 from Jonathan Larmour <[hidden email]> 2012-05-15 13:09:07 BST ---
(From update of attachment 1723)
I can confirm the assignment is now in place, dated yesterday.

--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug 1001561] Internal flash driver for Freescale TWR-K60N512 board

bugzilla-daemon
In reply to this post by bugzilla-daemon
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001561

--- Comment #19 from Ilija Kocho <[hidden email]> 2012-05-21 16:00:48 BST ---
Hi Nicolas

I'm trying to test the flash driver with Redboot but it seem there's some
problem. Instead of Redboot prompt I get some (probably) GDB stuff - I had to
apply the variant patch manually.

It may be due to configuration or because of recent Kinetis HAL upgrade.
Therefore I would ask you to sync the driver with current CVS and provide ECM
file(s) of your test configuration(s).

Regarding the code I have one remark. You already have a doubt where to put
CYG_FLASH_DRIVER, I would suggest a new file kinetis_flash.c in the same
directory with kinetis_misc.c (provided that it will be universal for all
Kinetis platforms).

Ilija.

--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug 1001561] Internal flash driver for Freescale TWR-K60N512 board

bugzilla-daemon
In reply to this post by bugzilla-daemon
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001561

--- Comment #20 from Nicolas Aujoux <[hidden email]> 2012-05-29 07:53:11 BST ---
Hi Ilija,

I have made some tests and in order for the driver to work, I desactivated the
"Redboot FIS support" (in Redboot ROM monitor -> Allow RedBoot tu support FLASH
programming) and desactivated the "Keep Redboot configuration data in flash"
option.
When this options are enabled, Redboot try to read a portion of flash  (with a
memcpy) which leads to a problem.

I also try to move the CYG_FLASH_DRIVER into a new kinetis_flash.c file and add
it to the file to be compile in the .cdl file. Redboot builds fine with it but
when I launch it, it seems that there is no flash init done. I'll keep working
on that but if you have any idea of what I am missing ...

Nicolas

(In reply to comment #19)

> Hi Nicolas
>
> I'm trying to test the flash driver with Redboot but it seem there's some
> problem. Instead of Redboot prompt I get some (probably) GDB stuff - I had to
> apply the variant patch manually.
>
> It may be due to configuration or because of recent Kinetis HAL upgrade.
> Therefore I would ask you to sync the driver with current CVS and provide ECM
> file(s) of your test configuration(s).
>
> Regarding the code I have one remark. You already have a doubt where to put
> CYG_FLASH_DRIVER, I would suggest a new file kinetis_flash.c in the same
> directory with kinetis_misc.c (provided that it will be universal for all
> Kinetis platforms).
>
> Ilija.

--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug 1001561] Internal flash driver for Freescale TWR-K60N512 board

bugzilla-daemon
In reply to this post by bugzilla-daemon
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001561

--- Comment #21 from Ilija Kocho <[hidden email]> 2012-06-20 08:48:42 BST ---
Hi Nicolas

I'm sorry for late reply, but I was busy. I tried to disable keeping Redboot
configuration data in FLASH bit it still raises exception. Can you post your
ECM file?

(In reply to comment #20)
> Hi Ilija,
>
> I have made some tests and in order for the driver to work, I desactivated the
> "Redboot FIS support" (in Redboot ROM monitor -> Allow RedBoot tu support FLASH
> programming) and desactivated the "Keep Redboot configuration data in flash"
> option.
> When this options are enabled, Redboot try to read a portion of flash  (with a
> memcpy) which leads to a problem.

Have you tried with cyg_flash_read()? It is recommended in manual and I would
recommend too.

>
> I also try to move the CYG_FLASH_DRIVER into a new kinetis_flash.c file and add
> it to the file to be compile in the .cdl file. Redboot builds fine with it but
> when I launch it, it seems that there is no flash init done. I'll keep working
> on that but if you have any idea of what I am missing ...

Probably the object file containing CYG_FLASH_DRIVER has been discarded by the
linker since effectively there aren't references to it.
If the driver is general for all Kinetis devices you can leave it in
kinetis_misc.c or put it in kinetis_flash.inl and include in kinetis_misc.c.
Otherwise you can put copies in platforms (see STM32 for example). However
driver inclusion for compilation should be conditional with some #ifdef.

Ilija

--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug 1001561] Internal flash driver for Freescale TWR-K60N512 board

bugzilla-daemon
In reply to this post by bugzilla-daemon
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001561

--- Comment #22 from Nicolas Aujoux <[hidden email]> 2012-06-20 15:11:16 BST ---
Created an attachment (id=1799)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1799)
Configuration file for a Redboot with flash working

--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug 1001561] Internal flash driver for Freescale TWR-K60N512 board

bugzilla-daemon
In reply to this post by bugzilla-daemon
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001561

Ilija Kocho <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1799|application/octet-stream    |text/plain
          mime type|                            |

--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug 1001561] Internal flash driver for Freescale TWR-K60N512 board

bugzilla-daemon
In reply to this post by bugzilla-daemon
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001561

--- Comment #23 from Nicolas Aujoux <[hidden email]> 2012-06-21 08:00:56 BST ---
(In reply to comment #21)
> Hi Nicolas
>
> I'm sorry for late reply, but I was busy. I tried to disable keeping Redboot
> configuration data in FLASH bit it still raises exception. Can you post your
> ECM file?

No problem. I posted a working for me configuration. I hope this works for you
as well.

>
> (In reply to comment #20)
> > Hi Ilija,
> >
> > I have made some tests and in order for the driver to work, I desactivated the
> > "Redboot FIS support" (in Redboot ROM monitor -> Allow RedBoot tu support FLASH
> > programming) and desactivated the "Keep Redboot configuration data in flash"
> > option.
> > When this options are enabled, Redboot try to read a portion of flash  (with a
> > memcpy) which leads to a problem.
>
> Have you tried with cyg_flash_read()? It is recommended in manual and I would
> recommend too.

I found out something about that : it seems to come from th "Flash block
containing the directory" option which has the value "-1". This value should
correspond to the last block of flash but when I put the value to 2, I get a
prompt and the fis command (even if it still crash when I do a fis init).

>
> >
> > I also try to move the CYG_FLASH_DRIVER into a new kinetis_flash.c file and add
> > it to the file to be compile in the .cdl file. Redboot builds fine with it but
> > when I launch it, it seems that there is no flash init done. I'll keep working
> > on that but if you have any idea of what I am missing ...
>
> Probably the object file containing CYG_FLASH_DRIVER has been discarded by the
> linker since effectively there aren't references to it.
> If the driver is general for all Kinetis devices you can leave it in
> kinetis_misc.c or put it in kinetis_flash.inl and include in kinetis_misc.c.
> Otherwise you can put copies in platforms (see STM32 for example). However
> driver inclusion for compilation should be conditional with some #ifdef.

So I let it where it is for the moment. Thanks

>
> Ilija

--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug 1001561] Internal flash driver for Freescale TWR-K60N512 board

bugzilla-daemon
In reply to this post by bugzilla-daemon
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001561

--- Comment #24 from Ilija Kocho <[hidden email]> 2012-06-23 17:38:52 BST ---
(In reply to comment #23)
> (In reply to comment #21)
> > Hi Nicolas
> >
> > I'm sorry for late reply, but I was busy. I tried to disable keeping Redboot
> > configuration data in FLASH bit it still raises exception. Can you post your
> > ECM file?
>
> No problem. I posted a working for me configuration. I hope this works for you
> as well.

Thanks. I did some testing.

>
> >
> > (In reply to comment #20)
> > > Hi Ilija,
> > >
> > > I have made some tests and in order for the driver to work, I desactivated the
> > > "Redboot FIS support" (in Redboot ROM monitor -> Allow RedBoot tu support FLASH
> > > programming) and desactivated the "Keep Redboot configuration data in flash"
> > > option.
> > > When this options are enabled, Redboot try to read a portion of flash  (with a
> > > memcpy) which leads to a problem.
> >

The end address in CYG_FLASH_DRIVER is 1 byte too high and it triggers
exception when you FIS directory and fconfig are at end of the FLASH.
It should be

(CYGMEM_REGION_flash + CYGMEM_REGION_flash_SIZE - 1)


Also I think that for the time being we should protect Redboot from overwriting
itself (and prevent writing to FLASH security area (0x400..0x40f).
Note this can be the reason for your system freeze when you put FIS directory
at beginning of FLASH. Something like this:

#define REDBOOT_IMAGE_SIZE CYGBLD_REDBOOT_MIN_IMAGE_SIZE

cyg_kinetis_flash_dev hal_kinetis_flash_priv;
static const cyg_flash_block_info_t cyg_flash_kinetis_block_info[1] = {
    { KINETIS_FLASH_BLOCK_SIZE, (CYGMEM_REGION_flash_SIZE -
REDBOOT_IMAGE_SIZE)/
        KINETIS_FLASH_BLOCK_SIZE }};

CYG_FLASH_DRIVER(hal_kinetis_flash,
                 &cyg_kinetis_flash_funs,
                 0,
                 CYGMEM_REGION_flash + REDBOOT_IMAGE_SIZE,
                 (CYGMEM_REGION_flash + CYGMEM_REGION_flash_SIZE - 1),
                 1, //number of block info
                 cyg_flash_kinetis_block_info,
                 &hal_kinetis_flash_priv);

With this configuration it works with default configuration. But I have tried
fconfig -i and fis init and it fails to write. Here is the "fconfig -i" minicom
output:

RedBoot> fconfig -i
Initialize non-volatile configuration - continue (y/n)? y
Run script at boot: false
Use BOOTP for network configuration: false
Gateway IP address: 192.168.209.1
Local IP address: 192.168.209.77
Local IP address mask: 255.255.255.0
Default server IP address: 192.168.209.7
Console baud rate: 38400
GDB connection port: 9000
Force console for special debug messages: false
Network debug at boot time: false
Update RedBoot non-volatile configuration - continue (y/n)? y
... Erase from 0x0007e000-0x0007efff: ..
... Program from 0x2000d800-0x2000e800 to 0x0007e000: V
Error writing config data at 0x0007e000: Data verify failed after operation


>
> I found out something about that : it seems to come from th "Flash block
> containing the directory" option which has the value "-1". This value should
> correspond to the last block of flash but when I put the value to 2, I get a
> prompt and the fis command (even if it still crash when I do a fis init).
>
> >
> > >
> > > I also try to move the CYG_FLASH_DRIVER into a new kinetis_flash.c file and add
> > > it to the file to be compile in the .cdl file. Redboot builds fine with it but
> > > when I launch it, it seems that there is no flash init done. I'll keep working
> > > on that but if you have any idea of what I am missing ...
> >
> > Probably the object file containing CYG_FLASH_DRIVER has been discarded by the
> > linker since effectively there aren't references to it.
> > If the driver is general for all Kinetis devices you can leave it in
> > kinetis_misc.c or put it in kinetis_flash.inl and include in kinetis_misc.c.
> > Otherwise you can put copies in platforms (see STM32 for example). However
> > driver inclusion for compilation should be conditional with some #ifdef.
>
> So I let it where it is for the moment. Thanks

For the time being you could leave it, but for the permanent


>
> >
> > Ilija

--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug 1001561] Internal flash driver for Freescale TWR-K60N512 board

bugzilla-daemon
In reply to this post by bugzilla-daemon
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001561

--- Comment #25 from Nicolas Aujoux <[hidden email]> 2012-06-26 10:31:10 BST ---
(In reply to comment #21)
> Hi Nicolas
>
> I'm sorry for late reply, but I was busy. I tried to disable keeping Redboot
> configuration data in FLASH bit it still raises exception. Can you post your
> ECM file?

No problem. I posted a working for me configuration. I hope this works for you
as well.

>
> (In reply to comment #20)
> > Hi Ilija,
> >
> > I have made some tests and in order for the driver to work, I desactivated the
> > "Redboot FIS support" (in Redboot ROM monitor -> Allow RedBoot tu support FLASH
> > programming) and desactivated the "Keep Redboot configuration data in flash"
> > option.
> > When this options are enabled, Redboot try to read a portion of flash  (with a
> > memcpy) which leads to a problem.
>
> Have you tried with cyg_flash_read()? It is recommended in manual and I would
> recommend too.

I found out something about that : it seems to come from th "Flash block
containing the directory" option which has the value "-1". This value should
correspond to the last block of flash but when I put the value to 2, I get a
prompt and the fis command (even if it still crash when I do a fis init).

>
> >
> > I also try to move the CYG_FLASH_DRIVER into a new kinetis_flash.c file and add
> > it to the file to be compile in the .cdl file. Redboot builds fine with it but
> > when I launch it, it seems that there is no flash init done. I'll keep working
> > on that but if you have any idea of what I am missing ...
>
> Probably the object file containing CYG_FLASH_DRIVER has been discarded by the
> linker since effectively there aren't references to it.
> If the driver is general for all Kinetis devices you can leave it in
> kinetis_misc.c or put it in kinetis_flash.inl and include in kinetis_misc.c.
> Otherwise you can put copies in platforms (see STM32 for example). However
> driver inclusion for compilation should be conditional with some #ifdef.

So I let it where it is for the moment. Thanks

>
> Ilija

(In reply to comment #24)

> (In reply to comment #23)
> > (In reply to comment #21)
> > > Hi Nicolas
> > >
> > > I'm sorry for late reply, but I was busy. I tried to disable keeping Redboot
> > > configuration data in FLASH bit it still raises exception. Can you post your
> > > ECM file?
> >
> > No problem. I posted a working for me configuration. I hope this works for you
> > as well.
>
> Thanks. I did some testing.
>
> >
> > >
> > > (In reply to comment #20)
> > > > Hi Ilija,
> > > >
> > > > I have made some tests and in order for the driver to work, I desactivated the
> > > > "Redboot FIS support" (in Redboot ROM monitor -> Allow RedBoot tu support FLASH
> > > > programming) and desactivated the "Keep Redboot configuration data in flash"
> > > > option.
> > > > When this options are enabled, Redboot try to read a portion of flash  (with a
> > > > memcpy) which leads to a problem.
> > >
>
> The end address in CYG_FLASH_DRIVER is 1 byte too high and it triggers
> exception when you FIS directory and fconfig are at end of the FLASH.
> It should be
>
> (CYGMEM_REGION_flash + CYGMEM_REGION_flash_SIZE - 1)

Thanks for pointing that out.

>
>
> Also I think that for the time being we should protect Redboot from overwriting
> itself (and prevent writing to FLASH security area (0x400..0x40f).
> Note this can be the reason for your system freeze when you put FIS directory
> at beginning of FLASH. Something like this:
>
> #define REDBOOT_IMAGE_SIZE CYGBLD_REDBOOT_MIN_IMAGE_SIZE
>
> cyg_kinetis_flash_dev hal_kinetis_flash_priv;
> static const cyg_flash_block_info_t cyg_flash_kinetis_block_info[1] = {
>     { KINETIS_FLASH_BLOCK_SIZE, (CYGMEM_REGION_flash_SIZE -
> REDBOOT_IMAGE_SIZE)/
>         KINETIS_FLASH_BLOCK_SIZE }};
>
> CYG_FLASH_DRIVER(hal_kinetis_flash,
>                  &cyg_kinetis_flash_funs,
>                  0,
>                  CYGMEM_REGION_flash + REDBOOT_IMAGE_SIZE,
>                  (CYGMEM_REGION_flash + CYGMEM_REGION_flash_SIZE - 1),
>                  1, //number of block info
>                  cyg_flash_kinetis_block_info,
>                  &hal_kinetis_flash_priv);
>
> With this configuration it works with default configuration. But I have tried
> fconfig -i and fis init and it fails to write. Here is the "fconfig -i" minicom
> output:
>
> RedBoot> fconfig -i
> Initialize non-volatile configuration - continue (y/n)? y
> Run script at boot: false
> Use BOOTP for network configuration: false
> Gateway IP address: 192.168.209.1
> Local IP address: 192.168.209.77
> Local IP address mask: 255.255.255.0
> Default server IP address: 192.168.209.7
> Console baud rate: 38400
> GDB connection port: 9000
> Force console for special debug messages: false
> Network debug at boot time: false
> Update RedBoot non-volatile configuration - continue (y/n)? y
> ... Erase from 0x0007e000-0x0007efff: ..
> ... Program from 0x2000d800-0x2000e800 to 0x0007e000: V
> Error writing config data at 0x0007e000: Data verify failed after operation
>

The problem here is that in my driver, I expect a relative address in flash so
I substract the flash base to the address and thus the program command actually
programs the address minus 0x20000. Anyway, my bad, I will post a patch to
correct this.

>
> >
> > I found out something about that : it seems to come from th "Flash block
> > containing the directory" option which has the value "-1". This value should
> > correspond to the last block of flash but when I put the value to 2, I get a
> > prompt and the fis command (even if it still crash when I do a fis init).
> >
> > >
> > > >
> > > > I also try to move the CYG_FLASH_DRIVER into a new kinetis_flash.c file and add
> > > > it to the file to be compile in the .cdl file. Redboot builds fine with it but
> > > > when I launch it, it seems that there is no flash init done. I'll keep working
> > > > on that but if you have any idea of what I am missing ...
> > >
> > > Probably the object file containing CYG_FLASH_DRIVER has been discarded by the
> > > linker since effectively there aren't references to it.
> > > If the driver is general for all Kinetis devices you can leave it in
> > > kinetis_misc.c or put it in kinetis_flash.inl and include in kinetis_misc.c.
> > > Otherwise you can put copies in platforms (see STM32 for example). However
> > > driver inclusion for compilation should be conditional with some #ifdef.
> >
> > So I let it where it is for the moment. Thanks
>
> For the time being you could leave it, but for the permanent
>
>
> >
> > >
> > > Ilija

--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug 1001561] Internal flash driver for Freescale TWR-K60N512 board

bugzilla-daemon
In reply to this post by bugzilla-daemon
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001561

Nicolas Aujoux <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1723|0                           |1
        is obsolete|                            |

--- Comment #26 from Nicolas Aujoux <[hidden email]> 2012-06-28 08:56:07 BST ---
Created an attachment (id=1806)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1806)
Devs part of the patch

--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug 1001561] Internal flash driver for Freescale TWR-K60N512 board

bugzilla-daemon
In reply to this post by bugzilla-daemon
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001561

Nicolas Aujoux <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1724|0                           |1
        is obsolete|                            |

--- Comment #27 from Nicolas Aujoux <[hidden email]> 2012-06-28 08:56:45 BST ---
Created an attachment (id=1807)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1807)
Hal part of the patch

--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug 1001561] Internal flash driver for Freescale TWR-K60N512 board

bugzilla-daemon
In reply to this post by bugzilla-daemon
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001561

--- Comment #28 from Ilija Kocho <[hidden email]> 2012-07-10 10:02:21 BST ---
Created an attachment (id=1819)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1819)
K60 Redboot-Flash ECM file

Hi Nicolas

(In reply to comment #27)
> Created an attachment (id=1807)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1807) [details]
> Hal part of the patch

I have tested it at seems to work. With attached ECM applied I could use "fis
init" and "fconfig -f".

There's, however, one limitation - we can't write to the flash bank that
contains Redboot itself. This is easily achieved by placing
flashCommandSequence() in RAM (only one function goes to RAM - good software
design :) ).

eCos has provision for this with ".2ram" memory section(s). You just need to
add the __attribute__ to the function declaration:

-- Code snippet ---
static int flashCommandSequence(cyg_uint8, cyg_uint8*) __attribute__((section
(".2ram.flashCommandSequence")));

-- snippet end ---

Now that we have it working, you can remove REDBOOT_IMAGE_SIZE macro as fis
will recognize and reserve the Redboot area.
Note: Flash configuration record 0x400-0x40f still must be protected from
accidental writing.

-- Code snippet ---

CYG_FLASH_DRIVER(hal_kinetis_flash,
                 &cyg_kinetis_flash_funs,
                 0,
                 CYGMEM_REGION_flash,
                 (CYGMEM_REGION_flash + CYGMEM_REGION_flash_SIZE - 1),
                 1,        //number of block info
                 cyg_flash_kinetis_block_info,
                 &hal_kinetis_flash_priv);

-- snippet end

Next things we should address are support for other parts: K40, K70 and
automatic Flash type/size recognition.

Ilija

--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug 1001561] Internal flash driver for Freescale TWR-K60N512 board

bugzilla-daemon
In reply to this post by bugzilla-daemon
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001561

Nicolas Aujoux <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1806|0                           |1
        is obsolete|                            |

--- Comment #29 from Nicolas Aujoux <[hidden email]> 2012-07-10 14:20:44 BST ---
Created an attachment (id=1820)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1820)
Devs part of the patch

--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug 1001561] Internal flash driver for Freescale TWR-K60N512 board

bugzilla-daemon
In reply to this post by bugzilla-daemon
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001561

Nicolas Aujoux <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1807|0                           |1
        is obsolete|                            |

--- Comment #30 from Nicolas Aujoux <[hidden email]> 2012-07-10 14:21:17 BST ---
Created an attachment (id=1821)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1821)
Hal part of the patch

--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug 1001561] Internal flash driver for Freescale TWR-K60N512 board

bugzilla-daemon
In reply to this post by bugzilla-daemon
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001561

--- Comment #31 from Nicolas Aujoux <[hidden email]> 2012-07-10 14:24:46 BST ---
Hi Ilija,

Thank you for your help. I move the function into RAM as you mentionned and it
works well.
I added the patches that implement this functionnality and remove the flash
limitation.

Nicolas

(In reply to comment #28)
> Created an attachment (id=1819)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1819) [details]
> K60 Redboot-Flash ECM file
>
> Hi Nicolas
>
> (In reply to comment #27)
> > Created an attachment (id=1807)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1807) [details]
[details]

> > Hal part of the patch
>
> I have tested it at seems to work. With attached ECM applied I could use "fis
> init" and "fconfig -f".
>
> There's, however, one limitation - we can't write to the flash bank that
> contains Redboot itself. This is easily achieved by placing
> flashCommandSequence() in RAM (only one function goes to RAM - good software
> design :) ).
>
> eCos has provision for this with ".2ram" memory section(s). You just need to
> add the __attribute__ to the function declaration:
>
> -- Code snippet ---
> static int flashCommandSequence(cyg_uint8, cyg_uint8*) __attribute__((section
> (".2ram.flashCommandSequence")));
>
> -- snippet end ---
>
> Now that we have it working, you can remove REDBOOT_IMAGE_SIZE macro as fis
> will recognize and reserve the Redboot area.
> Note: Flash configuration record 0x400-0x40f still must be protected from
> accidental writing.
>
> -- Code snippet ---
>
> CYG_FLASH_DRIVER(hal_kinetis_flash,
>                  &cyg_kinetis_flash_funs,
>                  0,
>                  CYGMEM_REGION_flash,
>                  (CYGMEM_REGION_flash + CYGMEM_REGION_flash_SIZE - 1),
>                  1,        //number of block info
>                  cyg_flash_kinetis_block_info,
>                  &hal_kinetis_flash_priv);
>
> -- snippet end
>
> Next things we should address are support for other parts: K40, K70 and
> automatic Flash type/size recognition.
>
> Ilija

--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug 1001561] Internal flash driver for Freescale TWR-K60N512 board

bugzilla-daemon
In reply to this post by bugzilla-daemon
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001561

--- Comment #32 from Ilija Kocho <[hidden email]> 2012-07-10 16:47:11 BST ---
Hi Nicolas

(In reply to comment #31)
> Hi Ilija,
>
> Thank you for your help. I move the function into RAM as you mentionned and it
> works well.
> I added the patches that implement this functionnality and remove the flash
> limitation.
>

Thank you for update.

Now that we have it working, let's prepare it for commit:

1. We don't want CYGNUM_DEVS_KINETIS_FLASH_LOGIC_ERROR_BUG work-around to ruin
the FLASH performance in normal operation, therefore it should be applied only
during the critical sections (write, erase, etc.). You can write inline
functions/macros that enable/disable it and call them where necessary.

2. Some protection of flash configuration area 0x400-0x40f. Let's think about
it.

3. Automatic block size determination. The default value should be derived from
the part type if possible. Also, the flash init function should check this
value against the real silicon (based on part Id, etc).

Should you may additional questions/comments esp. on 2. and 3. feel free to
ask.

Ilija

--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug 1001561] Internal flash driver for Freescale TWR-K60N512 board

bugzilla-daemon
In reply to this post by bugzilla-daemon
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001561

--- Comment #33 from Jonathan Larmour <[hidden email]> 2012-07-11 06:13:40 BST ---
Hi Nicolas,

As well as Ilija's comments, I also have a few comments too before this is
committed:

- The Flash package needs a ChangeLog file

- The whitespace could be tidied a little in the CDL file. Just line things up
and so on.

- There's an unnecessary couple of blank lines added in var_io.h just at the
end of the FMC definitions.

- Do not include pkgconf/redboot.h. RedBoot is not the only thing that can use
the flash driver.

- I don't think the flash driver should be instantiated in kinetis_misc.c. It
should either go in kinetis_flash.c along with everything else, or go in
individual platform HALs, to allow them the ability to override or disable
(like the STM32 does with its internal flash driver).

- The cyg_kinetis_flash_dev structure can be completely empty. Its contents are
not needed unless you are dynamically working out the sizes like the STM32 does
(see below).

- There's no need to re-declare hal_kinetis_flash_conf_p in kinetis_flash.c.
Just include var_io.h.

- kinetis_flashEraseAllBlocks and kinetis_flashEraseBlock are not used. They
should be either removed or put in #if 0 to silence warnings.

Although if you do want to keep flashEraseBlock, then I suggest checking the
requested address is block aligned first.

- I know you copied kinetis_flash_query() from somewhere else (STM32), but
nevertheless the query string can be 'const' (which the STM32 driver should
have as well). And add the 'e' onto 'Freescal'. Or better still, just use
something shorter like "Internal" or "On-chip", to save a little flash.
Also it would seem better to change this:
    memcpy( data, query, sizeof(query));
to:
    if ( sizeof(query) < len )
        len = sizeof(query);
    memcpy( data, query, len );

- In flashCommandSequence(), please either add a comment on the empty while
loops, or use CYG_EMPTY_STATEMENT; instead.

- In response to Ilija's comments, for his point (2) I don't think there's
anything that can sensibly be done. All flash drivers run the risk of messing
things up so you can't boot the board. And for his point (3), I agree it would
be better to make it more like the STM32 driver, and work things out from the
part. Although I disagree with Ilija and wouldn't say to check it against the
hardware (unless CYGPKG_INFRA_DEBUG is defined maybe).

Thanks for working through this and contributing Nicolas!

Jifl

--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug 1001561] Internal flash driver for Freescale TWR-K60N512 board

bugzilla-daemon
In reply to this post by bugzilla-daemon
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001561

--- Comment #34 from Ilija Kocho <[hidden email]> 2012-07-11 08:12:14 BST ---
Hi Jifl

Thanks for comments.

(In reply to comment #33)
> Hi Nicolas,
>
> As well as Ilija's comments, I also have a few comments too before this is
> committed:
>

[snip]
.
>
> - I don't think the flash driver should be instantiated in kinetis_misc.c. It
> should either go in kinetis_flash.c along with everything else, or go in
> individual platform HALs, to allow them the ability to override or disable
> (like the STM32 does with its internal flash driver).
>

FAOD I guess you are referring to devs/____/kinetis_flash.c . (Because there
was a version with another kinetis_flash.c in HAL that contained only the flash
driver entry. It was abandoned for reasons stated in comment #21).
I vote for putting the driver entry with driver code since I don't see a need
for different instances.

Ilija

--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug 1001561] Internal flash driver for Freescale TWR-K60N512 board

bugzilla-daemon
In reply to this post by bugzilla-daemon
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001561

--- Comment #35 from Ilija Kocho <[hidden email]> 2012-07-11 12:42:07 BST ---
(In reply to comment #33)
>
> - In response to Ilija's comments, for his point (2) I don't think there's
> anything that can sensibly be done. All flash drivers run the risk of messing
> things up so you can't boot the board.

On Kinetis writing the flash configuration record can be really devastating. It
is possible to lock the flash permanently. I think we can add a CDL option so
the user will have to explicitly enable writing to this record (either always,
or in case if the bit-string is "dangerous").


> And for his point (3), I agree it would
> be better to make it more like the STM32 driver, and work things out from the
> part. Although I disagree with Ilija and wouldn't say to check it against the
> hardware (unless CYGPKG_INFRA_DEBUG is defined maybe).

It could also be a user option.

Ilija

--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
1234