public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Jonathan Larmour <jlarmour@redhat.com>
To: Rafael Rodríguez Velilla <rrv@tid.es>
Cc: ecos <ecos-discuss@sourceware.cygnus.com>
Subject: Re: [ECOS] Drivers and related...
Date: Thu, 01 Feb 2001 11:22:00 -0000	[thread overview]
Message-ID: <3A79B787.E6B8C93@redhat.com> (raw)
In-Reply-To: <3A79AE27.B1F8F45A@tid.es>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1962 bytes --]

Rafael Rodríguez Velilla wrote:
> 
>    I'm porting eCos for a SOC with an embedded ARM. Everything is going
> quite right but now I find the following problem with eCos philosophy.
> My problem is quite simple:
> 1 My SOC has a lot of devices embedded (such as UARTS, display
> controller, keyboard controller, interrupts controller, and so on)
> 2 My SOC is in a platform with some peripherals such as the display
> itself, the 3volt to 5 volt converter and so on.
> 
> I want to integrate the drivers in eCos so that the user can configure
> the platform in the same way as in the rest of the operating system,
> that is, with cdl.
> 
> Where should I put all these drivers? under hal/MICROPP/arch o under
> hal/MICROPP/tema, a mix of both or even as an independent package ?
> (tema is the name of the platform and MICROPP the name of the SOC)

It depends on the driver. Things like interrupt controllers need to be
dealt with in the HAL; things like serial drivers should be under
devs/serial at the top level. Given there is no formal infrastructure for
the other devices (keyboard, display) you say about, integrating them into
the platform HAL (i.e. tema) may be sufficient.
 
> I have created a new architecture, it has an embedded ARM but I
> considered that it can be considered a new architecture because of all
> the extra components that  are indefectibly together. Do you consider
> this a correct assumption?

Whether a CPU has peripherals on-chip or off-chip makes little difference
on the operating system level. So treating it as a platform, not an
architecture, would be better. Generally peripherals are macrocells, so you
could easily find them again on a different CPU, so in this case putting
the drivers into separate packages would ease code reuse if code reuse is
likely.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

      reply	other threads:[~2001-02-01 11:22 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-01 10:47 Rafael Rodríguez Velilla
2001-02-01 11:22 ` Jonathan Larmour [this message]

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=3A79B787.E6B8C93@redhat.com \
    --to=jlarmour@redhat.com \
    --cc=ecos-discuss@sourceware.cygnus.com \
    --cc=rrv@tid.es \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).