This is the mail archive of the
ecos-patches@sourceware.org
mailing list for the eCos project.
[Bug 1001219] Ethernet driver for STM32 connectivity line with port on MMstm32f107 board.
- From: bugzilla-daemon at bugs dot ecos dot sourceware dot org
- To: ecos-patches at ecos dot sourceware dot org
- Date: Sun, 23 Oct 2011 22:26:28 +0100
- Subject: [Bug 1001219] Ethernet driver for STM32 connectivity line with port on MMstm32f107 board.
- Auto-submitted: auto-generated
- References: <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.