public inbox for ecos-patches@sourceware.org
 help / color / mirror / Atom feed
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: ecos-patches@ecos.sourceware.org
Subject: [Bug 1001219] Ethernet driver for STM32 connectivity line with port on MMstm32f107 board.
Date: Sun, 23 Oct 2011 21:27:00 -0000	[thread overview]
Message-ID: <20111023212629.163382F78003@mail.ecoscentric.com> (raw)
In-Reply-To: <bug-1001219-104@http.bugs.ecos.sourceware.org/>

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

Jerzy Dyrda <jerzdy@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         OS/Version|Cortex-M                    |ARM

--- Comment #20 from Jerzy Dyrda <jerzdy@gmail.com> 2011-10-23 22:26:20 BST ---
Hello Ilja,

(In reply to comment #19)
> (In reply to comment #5)
> > Created an attachment (id=1394)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1394) [details]
[details]
> > Ethernet driver for STM32 CL
> > 
> > Ethernet driver for STM32 Connectivity Line
> 
> Some comments on Ethernet driver:
> 
> MII and RMII interfaces are mutually exclusive and CDL should reflect this. A
> cdl_option with legal values "RMII" "MII" would provide it and in addition 
> make it visible in configtool.
> 
> "Remap pins" could be also visible if it were cdl_option.
OK.  


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

> On the other hand, the pin functions - once assigned to Ethernet 
> (although pins are provided provided by HAL) belong to Ethernet 
> so their naming should reflect this Here is a plf_io.h snuppet:
> 
> plf_io.h snippet --------------------------------
> 
> #define CYGHWR_IO_ETH_STM32MAC_MII_COL \
>         CYGHWR_HAL_STM32_GPIO(A, 3,  IN , FLOATING)
> ...
> -------------------------------------------------
OK.


> Also if_stm32.c
> Could CYGHWR_HAL_STM32_GPIO_SET(CYGHWR_...); lines be replaced by a loop?
Could you explain me what you mean?

> And in order to avoid specifying HAL specific macros in a device driver, a new
> macro can be defined CYGHWR_IO_ETH_STM32MAC_PIN(...).
> 
> Note: In macro names above I arbitrarily put "STM32MAC" segment. 
> Probably there is a more appropriate name for this Ethernet controller.
Maybe just CYGHWR_IO_ETH_STM32_MII_(pin_name)? 

> CYGNUM_DEVS_ETH_CORTEXM_STM32_RX_BUFS: Is there a range of legal values?
Amount of available RAM ;)

> BTW other Ethernet devices that I have seen also provide configuration option
> for TX_BUFFS.Is this fixed on STM32 Ethernet controller?
Driver based on size of SG list : 
#define TDES_NUM (CYGNUM_IO_ETH_DRIVERS_SG_LIST_SIZE >> 1)

Instead of copying data buffer driver uses it - just attach buffer to TX
descriptor list.

> 
> TCP/IP Checksum generation and check.
> FYI lwIP is aware of such hardware features
> http://sourceware.org/ml/ecos-discuss/2011-07/msg00017.html
> and it would be good if they are implemented.
I know. Driver provides such functionality :
CYGNUM_DEVS_ETH_CORTEXM_STM32_TX_CHECKSUM_GEN
CYGNUM_DEVS_ETH_CORTEXM_STM32_RX_CHECKSUM_VER
but without splitting it in IP checksum and UDP/TCP/ICMP checksum (MAC can't
calculates checksum only for UDP or TCP).

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.

  parent reply	other threads:[~2011-10-23 21:27 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-03 22:11 [Bug 1001219] New: " bugzilla-daemon
2011-05-04  7:41 ` [Bug 1001219] " bugzilla-daemon
2011-05-12  9:18 ` bugzilla-daemon
2011-10-08 14:02 ` bugzilla-daemon
2011-10-08 14:27 ` bugzilla-daemon
2011-10-10 20:51 ` bugzilla-daemon
2011-10-10 20:54 ` bugzilla-daemon
2011-10-10 20:56 ` bugzilla-daemon
2011-10-10 21:13 ` bugzilla-daemon
2011-10-10 21:50 ` bugzilla-daemon
2011-10-11 19:53 ` bugzilla-daemon
2011-10-11 20:39 ` bugzilla-daemon
2011-10-11 21:08 ` bugzilla-daemon
2011-10-11 21:45 ` bugzilla-daemon
2011-10-12 11:25 ` bugzilla-daemon
2011-10-12 20:34 ` bugzilla-daemon
2011-10-12 21:15 ` bugzilla-daemon
2011-10-16 14:12 ` bugzilla-daemon
2011-10-16 14:12 ` bugzilla-daemon
2011-10-22 12:22 ` bugzilla-daemon
2011-10-23 21:27 ` bugzilla-daemon [this message]
2011-10-24 15:55 ` bugzilla-daemon
2011-12-04 21:22 ` bugzilla-daemon
2011-12-04 21:23 ` bugzilla-daemon
2011-12-04 21:24 ` bugzilla-daemon
2011-12-04 21:25 ` bugzilla-daemon
2011-12-04 21:35 ` bugzilla-daemon
2011-12-21  9:33 ` bugzilla-daemon
2011-12-26 21:47 ` bugzilla-daemon
2012-01-02  0:35 ` bugzilla-daemon
2012-01-06 23:53 ` bugzilla-daemon
2012-01-06 23:56 ` bugzilla-daemon
2012-01-06 23:57 ` bugzilla-daemon
2012-01-06 23:57 ` bugzilla-daemon
2012-01-07  0:02 ` bugzilla-daemon
2012-01-07 22:31 ` bugzilla-daemon
2012-01-09 14:19 ` bugzilla-daemon
2012-02-02 21:44 ` bugzilla-daemon
2012-02-03 13:20 ` bugzilla-daemon
2012-12-10 22:33 ` bugzilla-daemon
2012-12-21 20:02 ` bugzilla-daemon
2012-12-24 17:31 ` bugzilla-daemon
2012-12-24 21:46 ` bugzilla-daemon
2012-12-25 11:34 ` bugzilla-daemon
2012-12-27 17:45 ` bugzilla-daemon
2012-12-28 14:15 ` bugzilla-daemon
2013-01-01 21:09 ` bugzilla-daemon
2013-01-01 21:10 ` bugzilla-daemon
2013-01-01 21:11 ` bugzilla-daemon
2013-01-01 21:17 ` bugzilla-daemon
2013-01-01 21:22 ` bugzilla-daemon
2013-01-15 21:26 ` bugzilla-daemon
2013-01-15 21:27 ` bugzilla-daemon
2013-01-15 21:29 ` bugzilla-daemon
2013-01-20 21:47 ` bugzilla-daemon
2013-02-07 15:06 ` bugzilla-daemon
2013-02-07 18:05 ` bugzilla-daemon
2013-02-16 21:55 ` bugzilla-daemon
2013-04-01 17:28 ` bugzilla-daemon
2013-04-01 18:25 ` bugzilla-daemon
2013-04-06 22:43 ` bugzilla-daemon
2013-04-08 18:48 ` bugzilla-daemon
2013-04-09 11:03 ` bugzilla-daemon
2013-04-09 12:14 ` bugzilla-daemon
2013-04-12 11:12 ` bugzilla-daemon
2013-04-14 23:40 ` bugzilla-daemon
2013-04-17 21:34 ` bugzilla-daemon
2013-04-17 21:48 ` bugzilla-daemon
2017-02-15  7:40 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111023212629.163382F78003@mail.ecoscentric.com \
    --to=bugzilla-daemon@bugs.ecos.sourceware.org \
    --cc=ecos-patches@ecos.sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).