public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Albert ARIBAUD <albert.u.boot@aribaud.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] yet another arm mach-types.h thread
Date: Fri, 25 Nov 2011 20:33:58 +0100	[thread overview]
Message-ID: <4ECFEDA6.1060007@aribaud.net> (raw)
In-Reply-To: <201111242329.40991.michael@walle.cc>

Le 24/11/2011 23:29, Michael Walle a ?crit :
>
> Hi,
>
> As there was no real conclusion on my previous "arm mach-types.h" thread, i
> have to reemphasize that the current mach types handling is broken.
>
>   1. u-boot follows linux mach-types.h
>   2. linux only includes ids
>       a, they have (non DT!) board support for or
>       b, id which are not older than 12 months.
>
> Now there are the following cases with problems:
>   - boards which have no linux support but uboot support

These need no machine ID. Machine ID is a Linux thing, right?

>   - boards which have only dt support within linux. uboot won't be able to boot
>     these board with older kernels, which do not have dt support, but instead
>     still using the old-fashioned setup code.

I'm not sure I get this one right. If we're talking about boards that 
started out with a machine ID and then went DT-only, then they did not 
lose their machine ID, did they? And U-Boot is aiming at supporting 
device trees, right, so boards with DT support won't need a machine ID 
long, right?

>   - boards which have only dt support in mainline kernel but have been
>     backported to older kernels and old-fashioned setup code.
>   - there will always be regressions when pulling the newest mach-types.h from
>     linux

Indeed. And these regressions will help show which boards are still 
alive and which are dead and should be removed from the codebase (or 
maybe have moved to DT and might require device tree support in U-Boot).

> The proposed solution was to add the ID to the board config. Why not put all
> ids into the board configs then and remove the mach-types.h?

There is no need for a broad generalization. The general case should be 
that board support in U-Boot provide device tree (resp. machine ID) 
support to boards for which Linux supports device trees (resp. machine 
IDs), and other cases are exceptions that deserve specific treatment 
such as, for instance, custom machine ID support in config files.

> Maybe you want to
> have database with all ids? But with tracking the linux mach-types.h you
> always have the database with boards _linux mainline_ supports and not the
> boards uboot supports. Something seems to be broken there :)

That's because you consider machine IDs to mean "supported by U-Boot" 
whereas basically they say "still supported by Linux without a device tree".

> IMHO either you say
>   - you have a database, that way you have to include the ids _you_ support or
>   - you don't have such a file and have the ids scattered all across the board
>     configs.

There is a database, it is mach-types.h, and it lists the boards for 
which Linux currently supports machine IDs. IDs in config files are for 
boards which want to advertise a machine ID to Linux despite mainline 
Linux currently not supporting their machine ID.

Amicalement,
-- 
Albert.

      reply	other threads:[~2011-11-25 19:33 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-24 22:29 [U-Boot] yet another arm mach-types.h thread Michael Walle
2011-11-25 19:33 ` Albert ARIBAUD [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=4ECFEDA6.1060007@aribaud.net \
    --to=albert.u.boot@aribaud.net \
    --cc=u-boot@lists.denx.de \
    /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