From mboxrd@z Thu Jan 1 00:00:00 1970 From: Igor Grinberg Date: Wed, 20 Apr 2011 11:58:14 +0300 Subject: [U-Boot] Update and Cut down mach types In-Reply-To: <0554BEF07D437848AF01B9C9B5F0BC5DC365D89D@dlee01.ent.ti.com> References: <0554BEF07D437848AF01B9C9B5F0BC5DC365D89D@dlee01.ent.ti.com> Message-ID: <4DAEA026.1010309@compulab.co.il> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Sandeep, Albert, Wolfgang, On 04/19/11 15:42, Paulraj, Sandeep wrote: > Wolfgang, Albert, > > Russell King sent some updates to the linux kernel for mach-types. > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=6f82f4db80189281a8ac42f2e72396accb719b57 > > He also removed a lot of entries which never made it to mainline. Well, as I understood from Russell, the main purpose of this "cut down" is to make "du -s linux/arch/arm" smaller, because there is no real need in all those boards listed in mach-types.h unless there is a support for them in mainline Linux kernel. Nevertheless the real ARM registry remains untouched - meaning that all board ids remain the same and no board is removed from the registry. This is the place where U-Boot board support diverges from Linux... Are we obliged to follow the Linux mach-types.h? Can't we just adopt Russell's "cut down" script to boards supported by U-Boot? Or will it harden the mach-types.h future updates? Have you thought of getting rid of mach-types.h completely? Making every board define its ARM registry id can work and will eliminate the need for mach-types.h update every couple of months. > I have a patch and it is the branch below > > http://git.denx.de/?p=u-boot/u-boot-ti.git;a=shortlog;h=refs/heads/update-mach-types Have you checked that none of the removed boards are in U-Boot tree? Because if there are some, then their build will be broken... And have to be fixed by... say a #define MACH_TYPE_* in a board_config file. > > Please review and if it is acceptable to everyone then we should apply this patch to remain in sync with the mainline kernel. [...] -- Regards, Igor.