From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16593 invoked by alias); 24 Oct 2011 15:55:07 -0000 Received: (qmail 16580 invoked by uid 22791); 24 Oct 2011 15:55:05 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 24 Oct 2011 15:54:28 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id C81492F78010 for ; Mon, 24 Oct 2011 16:54:27 +0100 (BST) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFd3POU1MoEF; Mon, 24 Oct 2011 16:54:26 +0100 (BST) 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. X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: eCos X-Bugzilla-Component: Patches and contributions X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: ilijak@siva.com.mk X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: low X-Bugzilla-Assigned-To: ilijak@siva.com.mk X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: In-Reply-To: References: X-Bugzilla-URL: http://bugs.ecos.sourceware.org/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Mon, 24 Oct 2011 15:55:00 -0000 Message-Id: <20111024155426.212A02F78005@mail.ecoscentric.com> Mailing-List: contact ecos-patches-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-patches-owner@ecos.sourceware.org X-SW-Source: 2011-10/txt/msg00051.txt.bz2 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 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.