Devicetree
 help / color / mirror / Atom feed
From: Nicolas Pitre <nico-vtqb6HGKxmzR7s880joybQ@public.gmane.org>
To: Jeremy Kerr <jeremy.kerr-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: Boot interface for device trees on ARM
Date: Fri, 04 Jun 2010 22:29:11 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LFD.2.00.1006042212400.30664@xanadu.home> (raw)
In-Reply-To: <201006050933.06714.jeremy.kerr-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>

On Sat, 5 Jun 2010, Jeremy Kerr wrote:

> All,
> 
> > > With this, the kernel can remain largely backward compatible with the
> > > legacy boot method, requiring _no_ change to the existing code, as the
> > > ID is sufficient to distinguish between both boot types.  The machine
> > > record remains largely relevant even for a DT boot as the majority of
> > > its content is SOC specific anyway, and given a per SOC ID for DT usage
> > > means that the early boot facilities are still usable as is even in the
> > > DT context.  And then the init_machine method in the machine record is
> > > naturally used to parse the device tree and do its work on multiple
> > > machines' behalf instead of relying on compiled-in static data for a
> > > specific machine.
> > 
> > There will still be instances of machine-specific setup code that
> > needs to be chosen at boot (based on the top level 'compatible'
> > property), but init_machine() appears to be early enough to handle
> > this.
> > 
> > hmmm... however, things the device tree blob and the initrd both need
> > to be marked as bootmem at paging_init() time, but init_machine()
> > doesn't run until later.  There will still need to be some hooks for
> > doing early DT processing, but none of that should be either board or
> > SoC specific.
> 
> If we're planning to keep the machine IDs around (even if they are now per-
> SoC), I'd like to know what would be left using them. The only thing that I 
> can see that we currently use is io_pg_offset for the DEBUG_LL builds, and 
> that isn't a convincing case to keep them.

Why not?

Kernel infrastructure backward compatibility means that you need to keep 
struct machine_desc instances around.  Granted, for the DT case, many of 
the members could be NULL or initialized with dummy stubs.  But that is 
very cheap to keep around, and that allows the same kernel binary to be 
able to use both the DT boot and the legacy boot.

In 10 years we might realize that non DT setups are no longer relevant 
and then all we'll have to do is rip out struct machine_desc and ignore 
the r1 value from the bootloader.  Ignoring that now means a flag day. 
And nobody wants a flag day forced upon them.


Nicolas

  parent reply	other threads:[~2010-06-05  2:29 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-18  2:54 Boot interface for device trees on ARM Jeremy Kerr
2010-05-18  4:34 ` Nicolas Pitre
     [not found]   ` <alpine.LFD.2.00.1005172341200.12758-QuJgVwGFrdf/9pzu0YdTqQ@public.gmane.org>
2010-05-18  5:24     ` Jeremy Kerr
     [not found]       ` <201005181324.45701.jeremy.kerr-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
2010-05-18  8:49         ` David Gibson
2010-05-18 12:24           ` Nicolas Pitre
2010-05-18 14:06             ` Jason McMullan
     [not found]               ` <AANLkTikg4rQdnbFxBOUkGc_0DrKqRkp9raZ8Ck5xkLG4-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-05-19  0:21                 ` David Gibson
     [not found]             ` <alpine.LFD.2.00.1005180802010.12758-QuJgVwGFrdf/9pzu0YdTqQ@public.gmane.org>
2010-05-19  0:28               ` David Gibson
2010-05-19  1:28                 ` Nicolas Pitre
     [not found]                   ` <alpine.LFD.2.00.1005182109180.12758-QuJgVwGFrdf/9pzu0YdTqQ@public.gmane.org>
2010-05-19  6:50                     ` David Gibson
2010-05-19 14:45                       ` Grant Likely
2010-05-19  1:41                 ` Jamie Lokier
     [not found]                   ` <20100519014118.GD2318-yetKDKU6eevNLxjTenLetw@public.gmane.org>
2010-05-19  7:12                     ` David Gibson
2010-05-19 14:21                     ` Grant Likely
2010-05-19  8:50               ` Jeremy Kerr
2010-05-19  7:25             ` Mitch Bradley
2010-05-18 11:57         ` Nicolas Pitre
     [not found]           ` <alpine.LFD.2.00.1005180742500.12758-QuJgVwGFrdf/9pzu0YdTqQ@public.gmane.org>
2010-05-19 12:13             ` Grant Likely
     [not found]               ` <AANLkTinsOSI_TIc7Jyy4QFuFaS2d-fi0y3LMuITLyG3N-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-05-19 16:45                 ` Jamie Lokier
     [not found]                   ` <20100519164534.GE1693-yetKDKU6eevNLxjTenLetw@public.gmane.org>
2010-05-19 17:10                     ` Grant Likely
2010-05-19 17:32                       ` M. Warner Losh
2010-05-19 11:57     ` Grant Likely
2010-05-19 12:08       ` Russell King - ARM Linux
     [not found]       ` <AANLkTilJl9_NHiT1LITG7UbA9S7OYsnGMcDAsFEEx5Ob-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-05-19 17:52         ` Nicolas Pitre
     [not found]           ` <alpine.LFD.2.00.1005191055180.12758-QuJgVwGFrdf/9pzu0YdTqQ@public.gmane.org>
2010-05-19 20:08             ` Jamie Lokier
     [not found]               ` <20100519200819.GF1693-yetKDKU6eevNLxjTenLetw@public.gmane.org>
2010-05-19 20:22                 ` Nicolas Pitre
     [not found]                   ` <alpine.LFD.2.00.1005191614580.12758-QuJgVwGFrdf/9pzu0YdTqQ@public.gmane.org>
2010-05-21 16:24                     ` John Rigby
2010-05-21 16:27                       ` Jamie Bennett
     [not found]                       ` <AANLkTil3vDAN4QIJJImk8MnQklisqFJq_RBc7c9VEZxl-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-05-21 19:59                         ` Russell King - ARM Linux
2010-06-03 21:12                         ` Grant Likely
2010-06-04 20:01             ` Grant Likely
     [not found]               ` <AANLkTilhqg270l-_m9raalqAPPRhvLJD9omHe8ysgLjg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-06-04 20:33                 ` John Rigby
2010-06-04 20:37                   ` Jon Loeliger
     [not found]                     ` <E1OKdeH-00053a-U2-CYoMK+44s/E@public.gmane.org>
2010-06-04 21:07                       ` Grant Likely
2010-06-05  1:33                 ` Jeremy Kerr
     [not found]                   ` <201006050933.06714.jeremy.kerr-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
2010-06-05  2:29                     ` Nicolas Pitre [this message]
     [not found]                       ` <alpine.LFD.2.00.1006042212400.30664-QuJgVwGFrdf/9pzu0YdTqQ@public.gmane.org>
2010-06-05  5:59                         ` Grant Likely
2010-06-09  4:26                         ` Jeremy Kerr
     [not found]                           ` <201006091226.15438.jeremy.kerr-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
2010-06-09 13:09                             ` Nicolas Pitre
     [not found] ` <201005181054.32325.jeremy.kerr-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
2010-05-19 11:45   ` Grant Likely

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=alpine.LFD.2.00.1006042212400.30664@xanadu.home \
    --to=nico-vtqb6hgkxmzr7s880joybq@public.gmane.org \
    --cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
    --cc=jeremy.kerr-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.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