This is the mail archive of the ecos-bugs@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.Singer@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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]