[Bug 1001550] New: STM32 F2 and STM3220G-EVAL / STM3240G-EVAL contribution from eCosCentric

[Bug 1001550] New: STM32 F2 and STM3220G-EVAL / STM3240G-EVAL contribution from eCosCentric

[bugzilla-daemon]

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

           Summary: STM32 F2 and STM3220G-EVAL / STM3240G-EVAL
                    contribution from eCosCentric
           Product: eCos
           Version: CVS
          Platform: Custom (Customer specific)
        OS/Version: Cortex-M
            Status: NEW
          Severity: enhancement
          Priority: low
         Component: Patches and contributions
        AssignedTo: unassigned@bugs.ecos.sourceware.org
        ReportedBy: jifl@ecoscentric.com
                CC: ecos-patches@ecos.sourceware.org
             Class: Advice Request


Created an attachment (id=1677)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1677)
Cortex-M arch VSR init fix

eCosCentric are contributing variant and processor support for the STM32 F2 and
F4 Cortex-M processors and STM3220G-EVAL and STM3240G-EVAL board support.
Updated drivers are also included for serial, flash, and SPI.

There are many changes here, but we thought it was good for the community to
benefit from them, and so that our essential infrastructure (particularly the
many APIs provided by the STM32 variant HAL) is aligned with public eCos's.
Although these enhancements are way beyond just what would be needed for just
the basic infrastructure.

Documentation is not included, but is available to view online from
eCosCentric's website:
http://www.ecoscentric.com/ecospro/doc/html/ref/arch-hal-cortexm-part.html
although some of that applies to eCosCentric only extensions and drivers.

The STM3210e port has had a number of updates applied too, to reflect changes
in the processor variant HAL, along with some minor improvements to bring it
more into line with eCosCentric's sources (although again, not everything of
eCosCentric's STM3210e improvements are included here).

I am committing this, but let me know in this bug about any issues in any of
the patches, and I'll deal with them.

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.

[Bug 1001550] STM32 F2 and STM3220G-EVAL / STM3240G-EVAL contribution from eCosCentric

[bugzilla-daemon]

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

Jonathan Larmour <jifl@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1677|application/octet-stream    |text/plain
          mime type|                            |
   Attachment #1677|0                           |1
           is 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.

[Bug 1001550] STM32 F2 and STM3220G-EVAL / STM3240G-EVAL contribution from eCosCentric

[bugzilla-daemon]

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

Jonathan Larmour <jifl@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned@bugs.ecos.source |jifl@ecoscentric.com
                   |ware.org                    |

--- Comment #1 from Jonathan Larmour <jifl@ecoscentric.com> 2012-04-01 02:46:38 BST ---
Created an attachment (id=1678)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1678)
Changes for STM32 processor variant HAL

-- 
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.

[Bug 1001550] STM32 F2 and STM3220G-EVAL / STM3240G-EVAL contribution from eCosCentric

[bugzilla-daemon]

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

--- Comment #2 from Jonathan Larmour <jifl@ecoscentric.com> 2012-04-01 02:47:29 BST ---
Created an attachment (id=1679)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1679)
Flash driver updates for STM32 F2/F4

-- 
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.

[Bug 1001550] STM32 F2 and STM3220G-EVAL / STM3240G-EVAL contribution from eCosCentric

[bugzilla-daemon]

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

--- Comment #3 from Jonathan Larmour <jifl@ecoscentric.com> 2012-04-01 02:48:12 BST ---
Created an attachment (id=1680)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1680)
STM32 serial driver updates for F2 / F4

-- 
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.

[Bug 1001550] STM32 F2 and STM3220G-EVAL / STM3240G-EVAL contribution from eCosCentric

[bugzilla-daemon]

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

--- Comment #4 from Jonathan Larmour <jifl@ecoscentric.com> 2012-04-01 02:48:53 BST ---
Created an attachment (id=1681)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1681)
STM32 SPI driver updates for F2 / F4

-- 
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.

[Bug 1001550] STM32 F2 and STM3220G-EVAL / STM3240G-EVAL contribution from eCosCentric

[bugzilla-daemon]

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

--- Comment #5 from Jonathan Larmour <jifl@ecoscentric.com> 2012-04-01 02:49:24 BST ---
Created an attachment (id=1682)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1682)
RTC/Wallclock updates for STM32 F2/F4

-- 
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.

[Bug 1001550] STM32 F2 and STM3220G-EVAL / STM3240G-EVAL contribution from eCosCentric

[bugzilla-daemon]

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

--- Comment #6 from Jonathan Larmour <jifl@ecoscentric.com> 2012-04-01 02:50:12 BST ---
Created an attachment (id=1683)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1683)
STM3220G / STM3240G -EVAL board platform HAL

-- 
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.

[Bug 1001550] STM32 F2 and STM3220G-EVAL / STM3240G-EVAL contribution from eCosCentric

[bugzilla-daemon]

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

--- Comment #7 from Jonathan Larmour <jifl@ecoscentric.com> 2012-04-01 02:50:55 BST ---
Created an attachment (id=1684)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1684)
Updates needed for STM3210E-EVAL platform HAL for var HAL changes

-- 
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.

[Bug 1001550] STM32 F2 and STM3220G-EVAL / STM3240G-EVAL contribution from eCosCentric

[bugzilla-daemon]

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

Jonathan Larmour <jifl@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |NEXTRELEASE

--- Comment #8 from Jonathan Larmour <jifl@ecoscentric.com> 2012-04-01 02:51:30 BST ---
Marking as resolved, but comments on these patches still welcome.

-- 
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.

[Bug 1001550] STM32 F2 and STM3220G-EVAL / STM3240G-EVAL contribution from eCosCentric

[bugzilla-daemon]

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

John Dallaway <john@dallaway.org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |john@dallaway.org.uk
         Resolution|NEXTRELEASE                 |

--- Comment #9 from John Dallaway <john@dallaway.org.uk> 2012-04-01 20:41:08 BST ---
Jifl, great to see this contribution!

Some initial comments/queries based on a quick scan of the patches:

* An earlier patch to the STM32 serial driver for bug #1001068 appears to have
been reversed by your patch. Can you reinstate this please?

* Some of the changes listed in the STM3210E-EVAL platform HAL ChangeLog do not
appear to be present in the source patch (eg the .ldi file changes). Can you
check that the various ChangeLogs provide an accurate reflection of the changes
committed please? Ref:

http://bugs.ecos.sourceware.org/attachment.cgi?id=1684&action=diff

* The ecos.db patch lists the STM32 ethernet and watchdog packages for the new
targets and some relevant register definitions are provided at the HAL level
but I don't see the packages in the CVS commit. Ref:

http://bugs.ecos.sourceware.org/attachment.cgi?id=1683&action=diff#ecos.db_sec2

* The "set_value" keyword in ecos.db was introduced as a quick hack for use
within the Red Hat test farm and was never intended to be used elsewhere.
set_value will provide a user_value for the specified CDL item which can
therefore be inadvertently changed using the "restore defaults" action in
configtool. I would really like to consider the use of "set_value" to be
deprecated. It should always be possible to use a separate tiny CDL-only
package to achieve the same effect. Are you OK with this?

Finally, are you able to confirm that the code you have checked in has been
tested (eCos and RedBoot run-time) in the context of the eCos CVS HEAD? This is
a substantial patch and I'm just concerned that we don't destabilise the
existing STM32 support.

Thanks

-- 
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.

[Bug 1001550] STM32 F2 and STM3220G-EVAL / STM3240G-EVAL contribution from eCosCentric

[bugzilla-daemon]

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

John Dallaway <john@dallaway.org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ilijak@siva.com.mk,
                   |                            |jerzdy@gmail.com

--- Comment #10 from John Dallaway <john@dallaway.org.uk> 2012-04-02 08:22:07 BST ---
Hi Jifl, can you integrate this contribution with the existing STM32
contribution in bug #1001219 ? It seems that the Jerzy's contribution should
really have been checked in first to avoid conflicts.

-- 
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.

[Bug 1001550] STM32 F2 and STM3220G-EVAL / STM3240G-EVAL contribution from eCosCentric

[bugzilla-daemon]

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

--- Comment #11 from Ilija Kocho <ilijak@siva.com.mk> 2012-04-02 12:42:42 BST ---
(In reply to comment #10)
> Hi Jifl, can you integrate this contribution with the existing STM32
> contribution in bug #1001219 ? It seems that the Jerzy's contribution should
> really have been checked in first to avoid conflicts.

Hi Jifl and John

The main part of Jerzy's contribution is the Ethernet driver so, provided that
ST use same Ethernet controller through all lines (haven't checked) it's
complementary to this one. It is near ready (by my review) I think the only
issue was (removal of) RedBoot ecm file.

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.

[Bug 1001550] STM32 F2 and STM3220G-EVAL / STM3240G-EVAL contribution from eCosCentric

[bugzilla-daemon]

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

--- Comment #12 from Jonathan Larmour <jifl@ecoscentric.com> 2012-04-02 16:08:00 BST ---
(In reply to comment #9)
> Jifl, great to see this contribution!
> 
> Some initial comments/queries based on a quick scan of the patches:
> 
> * An earlier patch to the STM32 serial driver for bug #1001068 appears to have
> been reversed by your patch. Can you reinstate this please?

No it wasn't reversed. It was an alternative implementation to fix the same
problem. The logic is identical. But it's true that checking it in was
unnecessary, so I will revert the change anyway, to avoid pointless unnecessary
code changes. Plus the previous version was slightly clearer (evidently given
you misread it!).

> * Some of the changes listed in the STM3210E-EVAL platform HAL ChangeLog do not
> appear to be present in the source patch (eg the .ldi file changes). Can you
> check that the various ChangeLogs provide an accurate reflection of the changes
> committed please? Ref:
> 
> http://bugs.ecos.sourceware.org/attachment.cgi?id=1684&action=diff

It's the other way round - that was a ChangeLog entry that was missed earlier.
As you know, the STM3210e port was developed in eCosCentric, and the ChangeLog
should reflect the train of development (even if superseded by subsequent
events), and I noticed this ChangeLog entry was missing. It would have been
rather pointless to commit it separately.

> * The ecos.db patch lists the STM32 ethernet and watchdog packages for the new
> targets and some relevant register definitions are provided at the HAL level
> but I don't see the packages in the CVS commit. Ref:
> 
> http://bugs.ecos.sourceware.org/attachment.cgi?id=1683&action=diff#ecos.db_sec2

The ecos.db that was committed is correct. I had changed it following my
testing but evidently forgot to regenerate the patch, that's all. You can just
ignore those lines.

> * The "set_value" keyword in ecos.db was introduced as a quick hack for use
> within the Red Hat test farm and was never intended to be used elsewhere.
> set_value will provide a user_value for the specified CDL item which can
> therefore be inadvertently changed using the "restore defaults" action in
> configtool. I would really like to consider the use of "set_value" to be
> deprecated. It should always be possible to use a separate tiny CDL-only
> package to achieve the same effect. Are you OK with this?

Not really, no. Firstly, other targets use it. Secondly, the design intention
for CDL is that targets should be defined by platform packages, albeit with
"requires" rather than "set_value". As such this is much closer to the way
things are intended to be. Yes it originated as a solution to a specific
problem, but then so is ecos.db, which shouldn't exist at all. What we can do
at the moment is make the transition to a future improved world easier, so that
makes this approach better.

I would also be quite against a proliferation of pointless tiny packages across
the repository, cluttering things up. If that has already happened anywhere,
then that's a shame. Specifically, I think these considerations override a
particular facet of behaviour of an obscure config tool property. I don't
really care enough since it's obscure, but it seems more likely to me that it
is the config tool which needs a fix in that case. We should not have to change
target-side stuff to accommodate peculiarities of the config tool.

> Finally, are you able to confirm that the code you have checked in has been
> tested (eCos and RedBoot run-time) in the context of the eCos CVS HEAD? This is
> a substantial patch and I'm just concerned that we don't destabilise the
> existing STM32 support.

The only existing STM32 support is the STM3210e, which also came from
eCosCentric. But yes both eCos and RedBoot have been tested, albeit not to the
level of eCosCentric's own ports. But since the point is that the code is now
more similar to eCosCentric's sources, you can expect it to be high quality.

I will also update the website now.

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.

[Bug 1001550] STM32 F2 and STM3220G-EVAL / STM3240G-EVAL contribution from eCosCentric

[bugzilla-daemon]

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

--- Comment #13 from Jonathan Larmour <jifl@ecoscentric.com> 2012-04-02 16:55:32 BST ---
(In reply to comment #10)
> Hi Jifl, can you integrate this contribution with the existing STM32
> contribution in bug #1001219 ? It seems that the Jerzy's contribution should
> really have been checked in first to avoid conflicts.

As far as I knew, that change was still work in progress, whereas this
contribution was complete and finished. Were it otherwise, then I would expect
Jerzy's contribution to have been committed, and at that point yes merging may
have had to be considered for some portions. However looking at Jerzy's
contribution, the STM32 variant changes in the eCosCentric contribution
completely subsume and obsolete what Jerzy did, given this needs to provide
both connectivity line *and* F2/F4 processor support, which changes clocking
and pin mapping properties significantly, so the result would still have been
something that looks identical or near-identical to this contribution.

As for the Ethernet, it's up to Jerzy if he wants to use the definitions
provided, or provide his own alternative in var_io_eth.h - at least a separate
file keeps it all self-contained (var_io.h was getting too big to be
navigable). All I would say is that eCosCentric's driver has undergone
extensive testing using these definitions, so they are "known good", and has
been used on multiple boards, and include necessary changed definitions for the
F2/F4 which Jerzy's obviously wouldn't. And he will probably find the majority
correspond exactly to what he's already got anyway since both the names and
values essentially come from ST anyway.

But yes, since an ethernet driver is not included in this contribution, Jerzy
is free to use or ignore these definitions. They're there to be helpful, not to
be an obstacle.

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.

[Bug 1001550] STM32 F2 and STM3220G-EVAL / STM3240G-EVAL contribution from eCosCentric

[bugzilla-daemon]

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

--- Comment #14 from Jerzy Dyrda <jerzdy@gmail.com> 2012-04-03 12:44:58 BST ---
Hello all,

I think that it's high time to add my remarks.

(In reply to comment #13)
> (In reply to comment #10)
> > Hi Jifl, can you integrate this contribution with the existing STM32
> > contribution in bug #1001219 ? It seems that the Jerzy's contribution should
> > really have been checked in first to avoid conflicts.
> 
(...)
> However looking at Jerzy's contribution, the STM32 variant changes in the eCosCentric contribution
> completely subsume and obsolete what Jerzy did, given this needs to provide
> both connectivity line *and* F2/F4 processor support, which changes clocking
> and pin mapping properties significantly, so the result would still have been
> something that looks identical or near-identical to this contribution.
That's right the eCosCentric contribution provide much more and this work
should have 
priority against my. I don't see any problem to modify ethernet driver to
comply to the eCosCentric contribution.

> But yes, since an ethernet driver is not included in this contribution, 
 (...)
@Jonathan Larmour
Before I'm starting work I think that status of eCosCentric ethernet driver
have to be clarify.
1. If I can ask - why the ethernet driver isn't provided in this contribution?
2. Is it any plan to push ethernet driver in near future?

> As for the Ethernet, it's up to Jerzy if he wants to use the definitions
> provided, or provide his own alternative in var_io_eth.h - at least a separate
> file keeps it all self-contained (var_io.h was getting too big to be
> navigable). All I would say is that eCosCentric's driver has undergone
> extensive testing using these definitions, so they are "known good", and has
> been used on multiple boards, and include necessary changed definitions for the
> F2/F4 which Jerzy's obviously wouldn't. 

> And he will probably find the majority
> correspond exactly to what he's already got anyway since both the names and
> values essentially come from ST anyway.
Exactly - looking on  var_io_eth.h macros are very similar :)
Diffs are:
1. Instead of macros like that CYGHWR_HAL_STM32_ETH_MACCR I tend to "increase
readability"
by separating ethernet module e.g. MAC from its register e.g. CR i.e.
CYGHWR_HAL_STM32_ETH_MAC_CR
2. Tx/Rx DMA descriptors definitions are moved to ethernet driver
3. Pins mapping is moved to plf_io.h header according to Ilija hint :
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001219#c19
> "> Regarding pins, some addition to my statement in Comment #11. Since pins are
> > being provided by HAL, they should be defined in HAL (unlike other Ethernet
> > definitions such as registers, etc.). Preferable place is plf_io.h rather than
> > var_io.h. because other chips (present or future) may have different pin
> > mapping.
> Yes you are right. Despite of promised pin compatibility by ST pins assignment
> between F105/7 CL and F2xx family differs."

Summarizing:
I open to modify driver and if anyone is still interesting in my implementation
of ethernet driver for STM32 I can do that.
IMO The fastest and simplest way to push driver is using contributing eval
board STM322/40G but I don't have any possibility to achieve it.


Best regards,
jerzy

-- 
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.

[Bug 1001550] STM32 F2 and STM3220G-EVAL / STM3240G-EVAL contribution from eCosCentric

[bugzilla-daemon]

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

--- Comment #15 from Jonathan Larmour <jifl@ecoscentric.com> 2012-04-03 13:53:57 BST ---
(In reply to comment #14)
> > But yes, since an ethernet driver is not included in this contribution, 
>  (...)
> @Jonathan Larmour
> Before I'm starting work I think that status of eCosCentric ethernet driver
> have to be clarify.
> 1. If I can ask - why the ethernet driver isn't provided in this contribution?

Our ethernet driver is specific to our own port of the lwIP stack. Our lwIP
stack has modifications to make it "single-copy", but these changes have not
been released, and would not apply to public eCos's completely different lwIP
port. As a result of this, it provides a wholly different interface between
ethernet drivers and the lwIP stack. As such it is not usable with the BSD
stack - that was a deliberate choice for us due to the STM's focus on low
memory targets which makes use of the BSD stack unlikely, in which case having
a single-copy interface is also a useful memory saver compared to the standard
ethernet driver model.

> 2. Is it any plan to push ethernet driver in near future?

There isn't. You wouldn't be able to use it in any case, and to understand it
properly, you would need information on our single-copy driver interface which
is something which is being kept in-house for the foreseeable future. If you're
having specific problems with, say, driver initialisation, I could cut'n'paste
some snippets, but it wouldn't be the whole driver.

> > And he will probably find the majority
> > correspond exactly to what he's already got anyway since both the names and
> > values essentially come from ST anyway.
> Exactly - looking on  var_io_eth.h macros are very similar :)
> Diffs are:
> 1. Instead of macros like that CYGHWR_HAL_STM32_ETH_MACCR I tend to "increase
> readability"
> by separating ethernet module e.g. MAC from its register e.g. CR i.e.
> CYGHWR_HAL_STM32_ETH_MAC_CR

We just used the names exactly as ST document them, which doesn't have the
underscore, so you can search for the definition based on the exact documented
register name. It's not a big thing, but that was the reason it is like it is.


> 2. Tx/Rx DMA descriptors definitions are moved to ethernet driver

We just wanted to keep definitions laid down in the hardware documentation all
in one place. If there were two ethernet drivers (say, BSD and lwIP-specific,
like we sometimes have in eCosCentric), then you would want them to share these
definitions rather than duplicate them, so they are better off being in a
common place since they never change. Even if you don't use our definitions, I
would recommend you follow the same principle.


> 3. Pins mapping is moved to plf_io.h header according to Ilija hint :
> http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001219#c19

If you look more closely, you will see that only _some_ of the pins are defined
there. These are the pins that cannot be remapped, even on F2/F4, and thus do
not change so they should be common.

For the pins which can be remapped, they are indeed to be defined in plf_io.h.


> Summarizing:
> I open to modify driver and if anyone is still interesting in my implementation
> of ethernet driver for STM32 I can do that.

I'm sure people are. Don't underestimate the many people who will use stuff if
it's there and if it isn't just walk away :).

> IMO The fastest and simplest way to push driver is using contributing eval
> board STM322/40G but I don't have any possibility to achieve it.

I'm afraid we have no spare hardware. We only have one of each board and they
are needed for customer support. Once you're confident it /ought/ to work, I
could try out code on one though. But be warned I have a very high workload at
the moment.

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.

[Bug 1001550] STM32 F2 and STM3220G-EVAL / STM3240G-EVAL contribution from eCosCentric

[bugzilla-daemon]

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

--- Comment #16 from Ilija Kocho <ilijak@siva.com.mk> 2012-04-03 14:31:55 BST ---
Hi Yerzi

(In reply to comment #15)
> (In reply to comment #14)
> > > But yes, since an ethernet driver is not included in this contribution, 
> >  (...)
> > @Jonathan Larmour
> > Before I'm starting work I think that status of eCosCentric ethernet driver
> > have to be clarify.

[snip]

> > 2. Is it any plan to push ethernet driver in near future?
> 
> There isn't. You wouldn't be able to use it in any case, and to understand it
> properly, you would need information on our single-copy driver interface which
> is something which is being kept in-house for the foreseeable future. If you're
> having specific problems with, say, driver initialisation, I could cut'n'paste
> some snippets, but it wouldn't be the whole driver.

[snip]

> 
> > Summarizing:
> > I open to modify driver and if anyone is still interesting in my implementation
> > of ethernet driver for STM32 I can do that.
> 
> I'm sure people are. Don't underestimate the many people who will use stuff if
> it's there and if it isn't just walk away :).

Bug #1001219 is still actual, you can just continue there.

> 
> > IMO The fastest and simplest way to push driver is using contributing eval
> > board STM322/40G but I don't have any possibility to achieve it.
> 

To begin with, you can continue with your Propox board, anyway the Ethernet
driver should fit all variants. Your CL variant port may be redundant but you
could synchronize Propox platform port to current CVS. For STMF4 you could
consider Discovery board.

For the details we can continue in Bug #1001219

CU

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.

[Bug 1001550] STM32 F2 and STM3220G-EVAL / STM3240G-EVAL contribution from eCosCentric

[bugzilla-daemon]

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

--- Comment #17 from Jerzy Dyrda <jerzdy@gmail.com> 2012-04-03 18:16:44 BST ---
Hello Ilija,

(In reply to comment #16)
> (In reply to comment #15)
> > (In reply to comment #14)
> > > > But yes, since an ethernet driver is not included in this contribution, 
> > >  (...)
> > > @Jonathan Larmour
> > > Before I'm starting work I think that status of eCosCentric ethernet driver
> > > have to be clarify.
> 
 [snip]
@Jonathan thank you for clarification.

> > > Summarizing:
> > > I open to modify driver and if anyone is still interesting in my implementation
> > > of ethernet driver for STM32 I can do that.
> > 
> > I'm sure people are. Don't underestimate the many people who will use stuff if
> > it's there and if it isn't just walk away :).
> 
True missing drivers especially ethernet driver -> "useless" OS

> > 
> > > IMO The fastest and simplest way to push driver is using contributing eval
> > > board STM322/40G but I don't have any possibility to achieve it.
> > 
> 
> To begin with, you can continue with your Propox board, anyway the Ethernet
> driver should fit all variants. Your CL variant port may be redundant but you
> could synchronize Propox platform port to current CVS. For STMF4 you could
> consider Discovery board.
OK it's good choose to use much chipper board especially that goal is only
ethernet driver.

> For the details we can continue in Bug #1001219
OK I'll rewrite driver according to var_io_eth.h and when I have hardware I
port it to STM32F4.

Best regards,
jerzy

-- 
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.

[Bug 1001550] STM32 F2 and STM3220G-EVAL / STM3240G-EVAL contribution from eCosCentric

[bugzilla-daemon]

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

Christophe Coutand <ecos@hotmail.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ecos@hotmail.co.uk

--- Comment #18 from Christophe Coutand <ecos@hotmail.co.uk> 2012-04-03 19:06:46 BST ---
Hi Jonathan,

Could you check STM32 USB driver -> CYGHWR_HAL_STM32_RCC_APB1ENR_CAN

Christophe

-- 
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.

[Bug 1001550] STM32 F2 and STM3220G-EVAL / STM3240G-EVAL contribution from eCosCentric

[bugzilla-daemon]

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

--- Comment #19 from Jonathan Larmour <jifl@ecoscentric.com> 2012-04-03 19:46:08 BST ---
(In reply to comment #18)
> Hi Jonathan,
> 
> Could you check STM32 USB driver -> CYGHWR_HAL_STM32_RCC_APB1ENR_CAN

Hoho, I wouldn't have expected to find a CAN-related define in the USB driver!

Trivially fixed with CYGHWR_HAL_STM32_RCC_APB1ENR_CAN ->
CYGHWR_HAL_STM32_RCC_APB1ENR_CAN1 which I'll commit now.

Arguably, someone with a better ability to test USB may want to consider using
the clock descriptors and CYGHWR_HAL_STM32_CLOCK_ENABLE/DISABLE macros,
possibly as well as the new superior GPIO pin interface (even though the old
interface remains).

Although on the other hand, it looks like this form of USB device is a dead-end
- as far as I can tell, ST have moved towards a completely different OTG
peripheral instead with totally different interface, not just on F2/F4, but
also on F1 connectivity line parts.

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.

RE: [Bug 1001550] STM32 F2 and STM3220G-EVAL / STM3240G-EVAL contribution from eCosCentric

[Christophe Coutand]

Thanks,

Also STM32 variant has redefined the CYGHWR_HAL_STM32_RCC_APBxENx definitions from bit position to index so additional changes to the USB driver or other STM32 drivers might be required.

Christophe

-----Original Message-----
From: ecos-patches-owner@ecos.sourceware.org [mailto:ecos-patches-owner@ecos.sourceware.org] On Behalf Of bugzilla-daemon@bugs.ecos.sourceware.org
Sent: 3. april 2012 20:46
To: ecos-patches@ecos.sourceware.org
Subject: [Bug 1001550] STM32 F2 and STM3220G-EVAL / STM3240G-EVAL contribution from eCosCentric

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

--- Comment #19 from Jonathan Larmour <jifl@ecoscentric.com> 2012-04-03 19:46:08 BST ---
(In reply to comment #18)
> Hi Jonathan,
> 
> Could you check STM32 USB driver -> CYGHWR_HAL_STM32_RCC_APB1ENR_CAN

Hoho, I wouldn't have expected to find a CAN-related define in the USB driver!

Trivially fixed with CYGHWR_HAL_STM32_RCC_APB1ENR_CAN ->
CYGHWR_HAL_STM32_RCC_APB1ENR_CAN1 which I'll commit now.

Arguably, someone with a better ability to test USB may want to consider using
the clock descriptors and CYGHWR_HAL_STM32_CLOCK_ENABLE/DISABLE macros,
possibly as well as the new superior GPIO pin interface (even though the old
interface remains).

Although on the other hand, it looks like this form of USB device is a dead-end
- as far as I can tell, ST have moved towards a completely different OTG
peripheral instead with totally different interface, not just on F2/F4, but
also on F1 connectivity line parts.

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.

[Bug 1001550] STM32 F2 and STM3220G-EVAL / STM3240G-EVAL contribution from eCosCentric

[bugzilla-daemon]

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

--- Comment #20 from Ilija Kocho <ilijak@siva.com.mk> 2012-04-05 09:35:37 BST ---
(In reply to comment #12)
> (In reply to comment #9)

[snip]

> > * The "set_value" keyword in ecos.db was introduced as a quick hack for use
> > within the Red Hat test farm and was never intended to be used elsewhere.
> > set_value will provide a user_value for the specified CDL item which can
> > therefore be inadvertently changed using the "restore defaults" action in
> > configtool. I would really like to consider the use of "set_value" to be
> > deprecated. It should always be possible to use a separate tiny CDL-only
> > package to achieve the same effect. Are you OK with this?
> 
> Not really, no. Firstly, other targets use it. Secondly, the design intention
> for CDL is that targets should be defined by platform packages, albeit with
> "requires" rather than "set_value". As such this is much closer to the way
> things are intended to be. Yes it originated as a solution to a specific
> problem, but then so is ecos.db, which shouldn't exist at all. What we can do
> at the moment is make the transition to a future improved world easier, so that
> makes this approach better.

Why isn't this available in CDL? I always wanted some kind of soft "requires",
that will set/change default value but not hinder user override. My proposed
name was supposed to be "recommends" but "set_value" is perhaps better. 

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.

[Bug 1001550] STM32 F2 and STM3220G-EVAL / STM3240G-EVAL contribution from eCosCentric

[bugzilla-daemon]

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

--- Comment #21 from Jonathan Larmour <jifl@ecoscentric.com> 2012-04-05 16:42:25 BST ---
(In reply to comment #20)
> Why isn't this available in CDL?

It isn't available in CDL because, as Bart would tell you, he's never been
given time to develop it. Although Bart did take a sabbatical year and
host-side CDL and configuration improvements was something he was going to be
working on in that time, I think in practice he found it difficult to make good
progress on it. I'm afraid I don't know what the status is or what the plans
are at the moment - it may be nearly complete, or he may not be developing it
much at the moment.

> I always wanted some kind of soft "requires",
> that will set/change default value but not hinder user override. My proposed
> name was supposed to be "recommends" but "set_value" is perhaps better. 

This is a slightly different issue than the provision of targets by packages.
Yes what you ask for is indeed something which we have known for quite a while
is desirable, although wasn't in the original design. Bart did propose two
additions to CDL for this at some point in the past "default_value -weak" and
"override_default", but again these have not yet been implemented.

In the meantime, the workaround is to have two CDL values if this is needed.
Once is the option itself, and it has a default_value of the other option
(which will have the same name suffixed with _DEFAULT). Packages which need to
change the default do the "requires" on the _DEFAULT option, not the real one.

Anyway, this is getting a bit off-topic in the context of this STM32 patch. If
there are no objections, I'll close this 'bug' shortly (it can still be
reopened again).

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.

[Bug 1001550] STM32 F2 and STM3220G-EVAL / STM3240G-EVAL contribution from eCosCentric

[bugzilla-daemon]

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

--- Comment #22 from Christophe Coutand <ecos@hotmail.co.uk> 2012-04-13 18:49:32 BST ---
Created an attachment (id=1698)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1698)
Varian HAL: Added some clock definitions

-- 
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.

[Bug 1001550] STM32 F2 and STM3220G-EVAL / STM3240G-EVAL contribution from eCosCentric

[bugzilla-daemon]

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

--- Comment #24 from Christophe Coutand <ecos@hotmail.co.uk> 2012-04-13 18:51:19 BST ---
Created an attachment (id=1700)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1700)
STM32 ADC: Correct peripheral clock

-- 
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.

[Bug 1001550] STM32 F2 and STM3220G-EVAL / STM3240G-EVAL contribution from eCosCentric

[bugzilla-daemon]

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

--- Comment #23 from Christophe Coutand <ecos@hotmail.co.uk> 2012-04-13 18:50:41 BST ---
Created an attachment (id=1699)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1699)
STM32 USB: Correct peripheral clock

-- 
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.

[Bug 1001550] STM32 F2 and STM3220G-EVAL / STM3240G-EVAL contribution from eCosCentric

[bugzilla-daemon]

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

Jonathan Larmour <jifl@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1698|                            |assignment+, review+
               Flag|                            |

--- Comment #26 from Jonathan Larmour <jifl@ecoscentric.com> 2012-04-13 18:57:07 BST ---
(From update of attachment 1698)
Committed.

-- 
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.

[Bug 1001550] STM32 F2 and STM3220G-EVAL / STM3240G-EVAL contribution from eCosCentric

[bugzilla-daemon]

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

--- Comment #25 from Christophe Coutand <ecos@hotmail.co.uk> 2012-04-13 18:56:46 BST ---
Hi,

Updating CYGHWR_HAL_STM32_RCC_APB1ENR_CAN to
CYGHWR_HAL_STM32_RCC_APB1ENR_CAN1 is not enough,
BIT_(CYGHWR_HAL_STM32_RCC_APB1ENR_CAN1) is required. 

Instead ADC and USB drivers are updated to use the clock API:
CYGHWR_HAL_STM32_CLOCK_DISABLE / CYGHWR_HAL_STM32_CLOCK_ENABLE

ADC driver is missing a cleanup to use the new STM32 DMA API.

Christophe

-- 
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.

[Bug 1001550] STM32 F2 and STM3220G-EVAL / STM3240G-EVAL contribution from eCosCentric

[bugzilla-daemon]

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

Jonathan Larmour <jifl@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1699|                            |assignment+, review+
               Flag|                            |

--- Comment #27 from Jonathan Larmour <jifl@ecoscentric.com> 2012-04-13 18:57:48 BST ---
(From update of attachment 1699)
Committed.

-- 
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.

[Bug 1001550] STM32 F2 and STM3220G-EVAL / STM3240G-EVAL contribution from eCosCentric

[bugzilla-daemon]

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

Jonathan Larmour <jifl@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1700|                            |assignment+, review+
               Flag|                            |

--- Comment #28 from Jonathan Larmour <jifl@ecoscentric.com> 2012-04-13 18:58:18 BST ---
(From update of attachment 1700)
Committed. Thanks Christophe.

-- 
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.

[Bug 1001550] STM32 F2 and STM3220G-EVAL / STM3240G-EVAL contribution from eCosCentric

[bugzilla-daemon]

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

Jonathan Larmour <jifl@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |NEXTRELEASE

--- Comment #29 from Jonathan Larmour <jifl@ecoscentric.com> 2012-04-13 19:00:59 BST ---
I think it's time to mark this as resolved (again). Any new patches can go in
their own bugs.

-- 
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.

[Bug 1001550] STM32 F2 and STM3220G-EVAL / STM3240G-EVAL contribution from eCosCentric

[bugzilla-daemon]

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

--- Comment #30 from John Dallaway <john@dallaway.org.uk> 2012-04-15 20:27:08 BST ---
(In reply to comment #0)

> I am committing this, but let me know in this bug about any issues in any of
> the patches, and I'll deal with them.

Jifl, as a general point, can you give the other eCos maintainers an
opportunity to comment on patches of this size/significance before check-in
please?

Thank you, once again, for the contribution.

-- 
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.

[Bug 1001550] STM32 F2 and STM3220G-EVAL / STM3240G-EVAL contribution from eCosCentric

[bugzilla-daemon]

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

--- Comment #31 from Jonathan Larmour <jifl@ecoscentric.com> 2012-04-16 15:28:17 BST ---
(In reply to comment #30)
> (In reply to comment #0)
> 
> > I am committing this, but let me know in this bug about any issues in any of
> > the patches, and I'll deal with them.
> 
> Jifl, as a general point, can you give the other eCos maintainers an
> opportunity to comment on patches of this size/significance before check-in
> please?
> 
> Thank you, once again, for the contribution.

-- 
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.

[Bug 1001550] STM32 F2 and STM3220G-EVAL / STM3240G-EVAL contribution from eCosCentric

[bugzilla-daemon]

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

--- Comment #32 from Jonathan Larmour <jifl@ecoscentric.com> 2012-04-16 15:42:05 BST ---
[Ignore comment #31 which got submitted prematurely]

(In reply to comment #30)
> (In reply to comment #0)
> 
> > I am committing this, but let me know in this bug about any issues in any of
> > the patches, and I'll deal with them.
> 
> Jifl, as a general point, can you give the other eCos maintainers an
> opportunity to comment on patches of this size/significance before check-in
> please?

That isn't the way we've operated before, nor is it the way other FSF projects
operate including GDB and GCC. Unless of course the changes are controversial
or the maintainer has some uncertainty about them, or they extensively change
core code. Not when the changes are within the maintainer's own area of
competence anyway... for example, if I wanted to make non-trivial changes to
the configtool, I would expect to put them through review certainly.

Also with many substantial patches, it is sometimes much clearer to see what is
going on by actually looking at the end result, not the diff, and IME having to
apply (fixing up any bit-rot causing failed patches) and then revert all the
patches locally is a pain and impedes review.

The onus is naturally on the maintainer responsible to fix up any issues
resulting responsively, which absolutely could result in the patch being
reverted if needed. And that's the thing: we can always revert a patch if it
turns out to be more controversial than intended.

But in general I don't think we should be putting extra barriers in the way of
improvements from any maintainers, and that applies to everyone, not just me.

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.