All of lore.kernel.org
 help / color / mirror / Atom feed
From: nicolas.ferre@atmel.com (Nicolas Ferre)
To: linux-arm-kernel@lists.infradead.org
Subject: Building kernel for more than one SoC
Date: Mon, 11 Aug 2014 17:42:33 +0200	[thread overview]
Message-ID: <53E8E469.9050807@atmel.com> (raw)
In-Reply-To: <20140804201712.GK30282@n2100.arm.linux.org.uk>

On 04/08/2014 22:17, Russell King - ARM Linux :
> On Thu, Jul 31, 2014 at 01:59:36PM +0000, Grant Edwards wrote:
>> I'm told that it should be possible to build a kernel that will run on
>> two different SoC chips.  They're closely related (same ARM9 core,
>> many identical internal peripherals -- AT91SAM9G20 and 'G25), and
>> would likely have identical external hardware.
>>
>> In order to handle the internal periphals that differ, it was
>> recommended that I use loadable modules to keep the kernel size small.
>> However, my root filesystem is in RAM, so I don't see how loadable
>> modules helps unless I remove all of the .ko files from the root
>> filesystem after the kernel has booted.
> 
> I think whoever made that recommendation probably isn't aware of the
> direction that mainline kernels are heading.
> 
> Where we're going with mainline kernels is to have a set of drivers
> which work irrespective of the hardware you have.
> 
> We've actually had this policy for about the last decade - we've
> supported building the same family of SoCs into one single kernel
> (identified by their mach-* directory) and expecting that their
> drivers will cope with the differences between the SoCs at runtime.
> (Note that the CPU itself has never really come into it; we've had
> good abstractions for the CPU support since the late 90's, with the
> exception of a borderline between the ARMv5 and ARMv6 architectures.)
> 
> Whether the Atmel code does that or not, I don't know, but it _should_
> do it.

Absolutely, we do follow this policy for quite some time. So anything
that prevents what Russell describes above should be considered as a bug ;-)

> Over the last few years, we've been moving mainline towards even
> tighter integration, where it's possible to build completely
> dissimilar SoCs together, so ultimately we end up with: legacy kernels,
> one multi-platform ARMv5 and earlier kernel, and one multi-platform
> ARMv6 and later kernel.

We are almost at the point where we can have a multi-platform ARMv6/7
for sama5 SoCs and ARMv5 for our ARM9s.

>> It seems it would be simpler to just link in all required drivers for
>> both chips and discard the ones that aren't needed after kernel
>> initialization.
> 
> Even better is to abstract the differences and have the same driver
> code deal with the different variants internally - the selection of
> which variant being controlled via the device tree "compatible"
> property, or another appropriate method.

Sure. Everything in at91 is converted to device tree those days.

Best regards,
-- 
Nicolas Ferre

  reply	other threads:[~2014-08-11 15:42 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-31 13:59 Building kernel for more than one SoC Grant Edwards
2014-07-31 21:07 ` Thomas Petazzoni
2014-08-04 19:11   ` Grant Edwards
2014-08-04 20:17 ` Russell King - ARM Linux
2014-08-11 15:42   ` Nicolas Ferre [this message]
2014-08-11 15:47     ` Grant Edwards
2014-08-11 16:12       ` Robert Nelson
2014-08-11 20:43         ` Grant Edwards
2014-08-11 20:59           ` Russell King - ARM Linux
2014-08-11 21:15             ` Grant Edwards
2014-08-11 21:38               ` Robert Nelson
2014-08-11 21:57                 ` Grant Edwards
2014-08-11 22:43               ` Russell King - ARM Linux
2014-08-11 23:02                 ` Grant Edwards
2014-08-14  1:12                   ` Tomasz Figa
2014-08-12  3:52                 ` Olof Johansson

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=53E8E469.9050807@atmel.com \
    --to=nicolas.ferre@atmel.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.