From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31245 invoked by alias); 12 Oct 2011 21:15:34 -0000 Received: (qmail 31084 invoked by uid 22791); 12 Oct 2011 21:15:32 -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; Wed, 12 Oct 2011 21:15:18 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id E6A612F78015 for ; Wed, 12 Oct 2011 22:15:16 +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 HJwfC6oK8YgS; Wed, 12 Oct 2011 22:15:12 +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: UNCONFIRMED X-Bugzilla-Priority: low X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org 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: Wed, 12 Oct 2011 21:15:00 -0000 Message-Id: <20111012211512.5444C2F78010@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/msg00025.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 #16 from Ilija Kocho 2011-10-12 22:15:09 BST --- (In reply to comment #14) > Hello Ilija, > > (In reply to comment #12) > > (In reply to comment #6) > > > Created an attachment (id=1395) --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1395) [details] [details] [details] > > > Platform for Propox MMstm32f107 module > > > > First to remind you to my remark in comment #4 > > > > At present the user will see F103ZE which is unlikely to be the target device. > Please consider that such situation will always happen if further target will > be introduced. > > > Platform may require the "STM variany in use" (CYGHWR_HAL_CORTEXM_STM32) to be > > a specific device, or a set of eligible devices. If you opt for second case > > just make sure that configtool resolves with the one found on Propox board. > IMHO Either platform should provide proper STM32 variant or this option should > be remove - nobody is interested in this option. > > Please review this option considering targets existing STM32F100/1/2/3 further > like my STM32F105/7 and possible STM32F2xx, STM32F4xx and give me "order" how I > should introduce STM32F105/7 family. > I am not in a position to "order" you but I can give you some hints. Here is a hal_cortexm_stm32_mmstm32f107.cdl diff snippet. implements CYGINT_DEVS_ETH_CORTEXM_STM32_REMAP_PINS implements CYGINT_DEVS_SPI_CORTEXM_STM32_BUS3_REMAP_PINS + + requires { + (CYGHWR_HAL_CORTEXM_STM32 == "F107VB") || + (CYGHWR_HAL_CORTEXM_STM32 == "F107VC") || + (CYGHWR_HAL_CORTEXM_STM32 == "F105VB") || + (CYGHWR_HAL_CORTEXM_STM32 == "F105VC") + } + requires { is_active(CYGPKG_DEVS_ETH_PHY) implies (1 == CYGHWR_DEVS_ETH_PHY_DP8384X) } You can at your option put a single or multiple devices in "requires". Configtool will resolve (conflict) with first one. Other listed devices shall be "allowed" and rest of devices (off the list) shall raise conflict. Note: If you opt for multiple devices they should be ones that the controller on Propox board can emulate. Regarding F2 devices let's leave them for the time being. It will be another platform anyway. > > > Why JTAG startup? AFAIK Connectivity line desn't feature FSMC (or am I out of > > date?). I guess SRAM startup should work (but test it first). > You are absolute right. JTAG startup doesn't have sens and I remove it. > > > Regarding ROM startup there's one issue: RAM region is required in order to > > build RedBoot. True, there's not much use of RedBoot on device with 64KiB RAM > > but somebody would like to try. Solution is simple rename SRAM region (nor > > section) into RAM. > I follow other cortex-m target like lm3s where is: > - only one startup ROM > - only SRAM section I am refering to SRAM memory region, not .sram section. > > BTW. I've built RedBoot successful with only SRAM section. You probably do it without GDB support. Then I was unclear, sorry, I should have said "RAM is required by GDB support". When I reconsider, this is a small memory device, perhaps we could live without it. > > If it's possible I would like to shrink amount of startups only to ROM. ROM startup is enough. P.S. As a general advice, please take care about backward compatibility - it is very important. If able, please do regressions on "STM3210E EVAL board" (or equivalent). If you don't have hardware at least check the building process. 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.