public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: A good sub-architecture to base new ports on?
Date: Thu, 17 May 2012 21:04:58 +0000	[thread overview]
Message-ID: <201205172104.59097.arnd@arndb.de> (raw)
In-Reply-To: <CAB9v_DE-FRdyutcZL7EMpTv-9rXqoi+V15T_WyeP9CggrcMZdQ@mail.gmail.com>

On Thursday 17 May 2012, Alexey Zaytsev wrote:
> On Wed, May 16, 2012 at 6:57 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Wednesday 16 May 2012, Alexey Zaytsev wrote:
> > Another good one would be highbank, but that contains a lot of stuff you
> > don't need.
> >
> > ixp4xx is not very actively maintained, so I would not use that as
> > a base.
> >
> > What platform are you talking about? I know of a few people that are
> > working on getting older platforms ported to Linux, so maybe someone
> > is already working on a port.
> 
> It's a 'Solos' soc from Connexant. They released kernel code for
> 2.6.11, and I'm up-porting it to the current kernel. I know at least
> two other people interested in the port, adding them to CC. If you
> know anyone else, it would be great to share the effort.

I haven't heard of that architecture before, but I just found the 2.6.11
source you mentioned. spear6xx is probably a good example in that case,
being from a similar age.

Most of the arch code has actually moved to other subsystems nowadays
and would not be considered part of the platform but instead goes to

timer -> drivers/clksource
watchdog -> drivers/watchdog
msc+crypto -> drivers/crypto
spi -> drivers/spi
defaultrestore -> use gpio-keys and a shell script in user space
gpio -> drivers/gpio
gpio-if -> use existing sysfs insterface rather than new driver
udc -> probably similar enough to one that is already there that you
       can resuse code
drivers/serial/solos-serial -> drivers/tty/serial (from /drivers/serial)
driver/net/arm/solos-ether -> drivers/net/ethernet/conexant

My guess is that getting basic functionality (serial, timer, gpio, spi,
watchdog) is all fairly straightforward when you do it right. Ethernet
is going to be harder but is just one driver, and it's hard to tell
how much work the crypto stuff needs.

	Arnd

  parent reply	other threads:[~2012-05-17 21:04 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-16 13:16 A good sub-architecture to base new ports on? Alexey Zaytsev
2012-05-16 15:57 ` Arnd Bergmann
2012-05-17 15:29   ` Alexey Zaytsev
2012-05-17 17:24     ` Jorge Amorós Argos
2012-05-18 13:31       ` Arnd Bergmann
2012-05-21 20:19         ` Alexey Zaytsev
2012-05-23 20:41           ` Jorge Amorós Argos
2012-05-28  8:49             ` Volkan K.
2012-05-17 21:04     ` Arnd Bergmann [this message]
  -- strict thread matches above, loose matches on Subject: below --
2012-05-27 14:08 Volkan K.

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=201205172104.59097.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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