[Bug 1001219] Ethernet driver for STM32 connectivity line with port on MMstm32f107 board.

[bugzilla-daemon@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

--- Comment #21 from Ilija Kocho <ilijak@siva.com.mk> 2011-10-24 16:54:17 BST ---
(In reply to comment #20)

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

Pining, in general is something that can change when new chips introduced.

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

The idea is that, since there are many pins, a loop might slightly reduce the 
size, although I might be wrong.

> 
> > 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)? 

I would like to avoid references to architecture. If this Ethernet controller
has some name it would be suitable.

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

You may introduce some reasonable boundaries anyway. Also, usually there is a
minimal number of buffers (1 or 2) necessary for the driver to work.

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

Than, is there possibility for configuring the number of TX buffer descriptors?

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

IMO it should be used if possible. The gain is considerable according to:
http://sourceware.org/ml/ecos-discuss/2011-06/msg00029.html

You can put some CDL that enables checksum by HW if lwIP is included and then
HW checksum should be the default.

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.