From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Schwingen Date: Wed, 27 Apr 2011 12:19:42 +0200 Subject: [U-Boot] Update and Cut down mach types In-Reply-To: <4DB73B5C.5090601@emk-elektronik.de> References: <0554BEF07D437848AF01B9C9B5F0BC5DC365D89D@dlee01.ent.ti.com> <4DAEA026.1010309@compulab.co.il> <4DAF14A0.7050909@discworld.dascon.de> <4DAF1CBA.9020902@aribaud.net> <4DAF3381.7000804@discworld.dascon.de> <4DB0175A.3080000@aribaud.net> <4DB70B98.6040208@discworld.dascon.de> <20110426194003.AD040D52706@gemini.denx.de> <4DB72D4A.5070102@aribaud.net> <20110426213200.2F204D52705@gemini.denx.de> <4DB73B5C.5090601@emk-elektronik.de> Message-ID: <4DB7EDBE.80909@discworld.dascon.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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, cu Michael