From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29069 invoked by alias); 3 Apr 2012 12:54:19 -0000 Received: (qmail 29059 invoked by uid 22791); 3 Apr 2012 12:54:18 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED 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; Tue, 03 Apr 2012 12:54:05 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id EFBA52F78014 for ; Tue, 3 Apr 2012 13:54:03 +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 qqki9wuoOGLB; Tue, 3 Apr 2012 13:54:01 +0100 (BST) From: bugzilla-daemon@bugs.ecos.sourceware.org To: ecos-patches@ecos.sourceware.org Subject: [Bug 1001550] STM32 F2 and STM3220G-EVAL / STM3240G-EVAL contribution from eCosCentric 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: jifl@ecoscentric.com X-Bugzilla-Status: REOPENED X-Bugzilla-Priority: low X-Bugzilla-Assigned-To: jifl@ecoscentric.com 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: Tue, 03 Apr 2012 12:54:00 -0000 Message-Id: <20120403125401.A84092F78010@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: 2012-04/txt/msg00020.txt.bz2 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 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.