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

[bugzilla-daemon at bugs dot ecos dot sourceware dot 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 #16 from Ilija Kocho <ilijak@siva.com.mk> 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 the assignee for the bug.