[Bug 1001933] New HAL for the M4 core of Freescale Vybrid targets

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001933

Ilija Kocho [Илија Кочо]  changed:

   What|Removed |Added

   Attachment #2408|0   |1
   is patch||

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001933] New HAL for the M4 core of Freescale Vybrid targets

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001933

--- Comment #7 from Ilija Kocho [Илија Кочо] ili...@siva.com.mk ---
Hi Stefan

(In reply to comment #6)

[snip]

 
 There are a lot of reg*.h files in HAL include directory. Devices in eCos
 are decoupled from HAL in order to enable usage of device drivers with
 different architectures. I know that this philosophy is not perfectly
 implemented, but I aim to do best for new packages. It is especially benefit
 for Freescale's chips that re-use peripherals on different architectures.
 This is exactly the reason for us having those files. For example we have
 designed an Audio Framework, that works on MPC5xxx (Big Endian Power
 Architecture) and Vybrid (Little Endian ARM CortexM), because all of those
 peripheral definitions are taken from the HAL, so it e.g. includes the
 sai_reg.h file for the definition of the SAI (Serial Audio Interface)
 Peripheral, which are endianess swapped files between those two
 architectures. Isn't that exactly what you want to achieve ? How else would
 I achieve that ?

This may justify their inclusion. However, putting them within some
architecture implies another copy for every architecture/variant...

You may consider the hal/misc directory. It is created for devices that do not
have formal I/O  API, and are combined with different architectures. Examples
are DMA, memory devices, etc.
You will already find freescale directory there parenting eDMA library
package.

You have several possibilities:
   - Create a package (some kind of Freescale device library. It may start with
headers, but may also (now and/or in future) also have some code.

   - If you already have some generic library for a particular device, you can
make a package (in a way eDMA is now).

Note: This is not limited only to on-chip devices, however you should consider
which of either devs or hal/misc would be preferable location. Following
discussion may give you some insight on the background of hal/misc and how to
choose between hal/misc vs devs
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001428#c5 .

 
 I'm glad to see SGML docs, but they seem incomplete and their compilation
 raises errors. Quite frankly I do not even know how to correctly view SGML.
 I just opened your Kinetis files with a text editor and tried to get
 something semi correct.
 

Text editor is right tool :) for editing, and in order to see the document you
need to generate HTML or PDF. This link
http://ecos.sourceware.org/ml/ecos-discuss/2014-01/msg4.html may help you
regarding needed tools and doc. generation, I would just add that if you use a
common Linux distribution (I use Ubuntu) you'll find all tools in it's package
manager (such as Synaptic).

However, if you are not able to generate HTML/PDF, I can feed you back or take
care that it compiles, but the contents has to be accurate, up to date and
reflect real state of matters. Please take care of that.

 I have noticed CDL for Compiler selection. It is unnecessary because user
 can specify compiler prefix and flags in Global Build Options. Please
 remove it. Actually we driving a lot of things from that selection, e.g.
 whether we can move some critical code into the TCM (Tightly coupled
 Memory). This requires, that the Compiler can generate some trampolin code
 for that purpose, which the standard eCOS Compiler will not, but the
 Codesourcery will. That checkbox will avoid a lot of user erros and all
 members of our team really like that feature.

Is it really a compiler feature or a linker script? Perhaps some macros? Let's
investigate it.

Ilija

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001933] New HAL for the M4 core of Freescale Vybrid targets

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001933

--- Comment #6 from Stefan Singer stefan.sin...@freescale.com ---
Hi Ilija,
sorry for the slow response, but some urgent things came in the middle. Let me
try to address some of the points:

drivers: We only verified certain elements, e.g. ENET works. We will do some
more checking.

There are a lot of reg*.h files in HAL include directory. Devices in eCos
are decoupled from HAL in order to enable usage of device drivers with
different architectures. I know that this philosophy is not perfectly
implemented, but I aim to do best for new packages. It is especially benefit
for Freescale's chips that re-use peripherals on different architectures.
This is exactly the reason for us having those files. For example we have
designed an Audio Framework, that works on MPC5xxx (Big Endian Power
Architecture) and Vybrid (Little Endian ARM CortexM), because all of those
peripheral definitions are taken from the HAL, so it e.g. includes the
sai_reg.h file for the definition of the SAI (Serial Audio Interface)
Peripheral, which are endianess swapped files between those two architectures.
Isn't that exactly what you want to achieve ? How else would I achieve that ?

I'm glad to see SGML docs, but they seem incomplete and their compilation
raises errors. Quite frankly I do not even know how to correctly view SGML. I
just opened your Kinetis files with a text editor and tried to get something
semi correct.

I have noticed CDL for Compiler selection. It is unnecessary because user can
specify compiler prefix and flags in Global Build Options. Please remove it.
Actually we driving a lot of things from that selection, e.g. whether we can
move some critical code into the TCM (Tightly coupled Memory). This requires,
that the Compiler can generate some trampolin code for that purpose, which the
standard eCOS Compiler will not, but the Codesourcery will. That checkbox will
avoid a lot of user erros and all members of our team really like that feature.

Stefan

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001933] New HAL for the M4 core of Freescale Vybrid targets

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001933

Ilija Kocho [Илија Кочо] ili...@siva.com.mk changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 CC||ecos-patches@ecos.sourcewar
   ||e.org, ili...@siva.com.mk
  Component|HAL |Patches and contributions
Version|unknown |CVS
 Ever confirmed|0   |1

--- Comment #3 from Ilija Kocho [Илија Кочо] ili...@siva.com.mk ---
Stefan

Thank you for the contribution. I shall come with comments soon.
Ilija

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001933] New HAL for the M4 core of Freescale Vybrid targets

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001933

Ilija Kocho [Илија Кочо] ili...@siva.com.mk changed:

   What|Removed |Added

 Depends on||1001397

--- Comment #4 from Ilija Kocho [Илија Кочо] ili...@siva.com.mk ---
Stefan / Jochen

Thank you for your contribution. It would be nice to have Vybrid in our
repository.

I applied your patches to current eCos CVS and got some warnings and conflicts:

   - Wallclock seems to be missing.
   - Some conflicts pointing to I2C and SPI drivers. It seems that your earlier
patch Attachment 2350 from BUG 1001397 fixes I2C conflicts.
Question
  - Is Attachment 2350 up to date or yiu have newer I2C driver version?
  - What about SPI? There should be some patch.
  - What about drivers that show no conflicts: UART, ENET, eDMA, etc? I would
be very happy and proud if they work with Vybrid unmodified but it seeem too
good to be true.

Looking the code:

   - There are a lot of reg*.h files in HAL include directory. Devices in
eCos are decoupled from HAL in order to enable usage of device drivers with
different architectures. I know that this philosophy is not perfectly
implemented, but I aim to do best for new packages. It is especially benefit
for Freescale's chips that re-use peripherals on different architectures.

   - Also there are some type-case problems Vybrid_irq_scheme vs
vybrid_irq_scheme that may work under windows but cause errors on case
sensitive Linux

  - I'm glad to see SGML docs, but they seem incomplete and their compilation
raises errors.



The attached diff contains modifications that I did against current CVS. This
removes conflicts but there are still compilation errors.

Summary:

  -Please prepare new patches that shall work against current CVS. Also provide
patches to device drivers where needed. It would be good to split variant anf
platform patches in separate files.
 - Also for devices - separate patches.
 - Update year in copyright messages (2013 or 2014).
 - Cross-check SGML docs.
 - Remove reg*.h headers.
 - I have noticed CDL for Compiler selection. It is unnecessary because user
can specify compiler prefix and flags in Global Build Options. Please remove
it.

Ilija

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001933] New HAL for the M4 core of Freescale Vybrid targets

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001933

--- Comment #5 from Ilija Kocho [Илија Кочо] ili...@siva.com.mk ---
Created attachment 2410
  -- http://bugs.ecos.sourceware.org/attachment.cgi?id=2410action=edit
resolve conflicts against current 20140128 CVS

I forgot the diff. Here it is.

Ilija

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Patch_or_Contribution granted: [Bug 1001933] New HAL for the M4 core of Freescale Vybrid targets

[bugzilla-daemon]

Stefan Singer stefan.sin...@freescale.com has granted  Patch_or_Contribution:
Bug 1001933: New HAL for the M4 core of Freescale Vybrid targets
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001933


--- Additional Comments from Stefan Singer stefan.sin...@freescale.com
Hi eCos maintainers, please let us know, how to proceed.