From: Igor Grinberg <grinberg@compulab.co.il>
To: u-boot@lists.denx.de
Subject: [U-Boot] Update and Cut down mach types
Date: Thu, 28 Apr 2011 09:20:56 +0300 [thread overview]
Message-ID: <4DB90748.2020400@compulab.co.il> (raw)
In-Reply-To: <4DB7EDBE.80909@discworld.dascon.de>
On 04/27/11 13:19, Michael Schwingen wrote:
> Am 04/26/2011 11:38 PM, schrieb Reinhard Meyer:
>>>> So IMO, if we have mach-types in U-Boot for supporting Linux, then we
>>>> should keep using a (reasonably) up-to-date Linux machine ID list just
>>>> like we do now -- mach-types that disappear from the list mean Linux
>>>> support has become useless for that machine in U-Boot. And if we have
>>>> our own mach-type policy, different from "has linux support", then we
>>>> need to specify what this policy is and how it is implemented.
>>> I think we should be gentle to users of existing code and avoid
>>> breaking it. From now on, we could establish a policy that a mach-id
>>> can only be referenced when and as long mainline Linux support for
>>> this board exists.
>>>
>>> I'm open for suggestions.
>>
>> Hi Wolfgang, Albert,
>>
>> why don't we just create the #define MACH_xxx lines directly from the
>> "http://www.arm.linux.org.uk/developer/machines/download.php". We don't
>> need all the *_is_* macros in u-boot anyway. Then we would have just a
>> few 1000
>> lines of #define MACH_*
>>
> I had already proposed that - after all, that is the way Linux does it
> as well: the mach-types.h file is auto-generated from that list (or now
> from a cut-down version of that list), so directly using the original
> list to generate the .h file in u-boot would completely cut out the
> middle man.
>
> This would have multiple advantages IMHO:
>
> - the downloaded file is terse: only one line per machine, compared
> with the current mach-types.h where one added machine generates lots of
> lines (most of which we do not need at all!). Reviewing a patch that
> pulls in a new upstream version would be easier with the original file
> instead of the .h file.
>
> - Newly added machines turn up much earlier. When bringing up a new
> board, you will usually work on u-boot first. Having to wait until the
> machine ID trickles down into the Linux kernel, and *then* gets pulled
> into u-boot at some later time, makes for a substantial delay until
> board patches can be submitted to u-boot.
>
> - It would actually save space:
> 138803 Apr 27 12:12 mach-types (freshly downloaded, complete
> unfiltered list)
> 1177444 Apr 5 20:55 ./arch/arm/include/asm/mach-types.h (from u-boot
> master, before the patch that removes boards)
>
> - There would be no problem with removing boards that are supported in
> u-boot, but not in Linux mainline - we would have the IDs for all known
> boards, while still saving space.
>
> I do think the maintenance effort when using the original mach-types
> file would be lower than with the current system. However, when I
> proposed this before,
+1 to all said above, though some minor patching should be done:
u-boot $ grep -rn machine_is_ --exclude=mach-types.h *
arch/arm/cpu/arm920t/at91rm9200/ether.c:204: if (machine_is_csb337()) {
board/ti/omap1610inn/omap1610innovator.c:66: if (machine_is_omap_h2())
board/ti/omap1610inn/omap1610innovator.c:68: else if (machine_is_omap_innovator())
--
Regards,
Igor.
next prev parent reply other threads:[~2011-04-28 6:20 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-19 12:42 [U-Boot] Update and Cut down mach types Paulraj, Sandeep
2011-04-19 13:39 ` Matthias Weißer
2011-04-19 13:45 ` Paulraj, Sandeep
2011-04-20 8:44 ` Albert ARIBAUD
2011-04-19 14:21 ` Wolfgang Denk
2011-04-19 18:42 ` Matthias Weisser
2011-04-19 18:44 ` Michael Schwingen
2011-04-20 8:15 ` Detlev Zundel
2011-04-20 8:58 ` Igor Grinberg
2011-04-20 17:15 ` Michael Schwingen
2011-04-20 17:49 ` Albert ARIBAUD
2011-04-20 19:26 ` Michael Schwingen
2011-04-21 11:39 ` Albert ARIBAUD
2011-04-26 18:14 ` Michael Schwingen
2011-04-26 19:40 ` Wolfgang Denk
2011-04-26 20:38 ` Albert ARIBAUD
2011-04-26 21:32 ` Wolfgang Denk
2011-04-26 21:38 ` Reinhard Meyer
2011-04-27 10:19 ` Michael Schwingen
2011-04-28 6:20 ` Igor Grinberg [this message]
2011-04-29 8:58 ` Detlev Zundel
2011-05-01 10:10 ` [U-Boot] [PATCH 1/3] arm: omap: innovator: fix compilation error Igor Grinberg
2011-05-17 12:40 ` Igor Grinberg
2011-05-21 21:40 ` Paulraj, Sandeep
2011-05-01 10:10 ` [U-Boot] [PATCH 2/3] arm: omap: innovator: Prepare for mach-types.h changes Igor Grinberg
2011-05-01 20:28 ` Alessandro Rubini
2011-05-02 7:18 ` Igor Grinberg
2011-05-03 10:08 ` [U-Boot] [PATCH v2 " Igor Grinberg
2011-05-03 12:29 ` Wolfgang Denk
2011-05-03 13:00 ` Igor Grinberg
2011-05-04 7:13 ` [U-Boot] [PATCH v3 " Igor Grinberg
2011-05-01 10:10 ` [U-Boot] [PATCH 3/3] arm: at91: ether: " Igor Grinberg
2011-05-01 19:38 ` Reinhard Meyer
2011-05-02 7:29 ` Igor Grinberg
2011-05-02 10:09 ` Detlev Zundel
2011-05-02 12:49 ` [U-Boot] [PATCH v2 " Igor Grinberg
2011-05-16 13:31 ` Igor Grinberg
2011-04-27 11:44 ` [U-Boot] Update and Cut down mach types Detlev Zundel
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=4DB90748.2020400@compulab.co.il \
--to=grinberg@compulab.co.il \
--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 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.