public inbox for
 help / color / mirror / Atom feed
Subject: [Bug 1001933] New HAL for the M4 core of Freescale Vybrid targets
Date: Wed, 05 Feb 2014 08:59:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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

--- Comment #7 from Ilija Kocho [Илија Кочо] <> ---
Hi Stefan

(In reply to comment #6)


> "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

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 .

> "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 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.


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

  parent reply	other threads:[~2014-02-05  8:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
2014-01-27 12:04 ` bugzilla-daemon
2014-01-27 12:05 ` bugzilla-daemon
2014-01-28  1:46 ` bugzilla-daemon
2014-01-28  1:49 ` bugzilla-daemon
2014-02-03 19:33 ` bugzilla-daemon
2014-02-05  8:59 ` bugzilla-daemon [this message]
2016-12-02  7:07 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).