From mboxrd@z Thu Jan 1 00:00:00 1970 From: Igor Grinberg Date: Sun, 04 Mar 2012 16:14:56 +0200 Subject: [U-Boot] i.MX6: mx6qsabrelite: allow use with Freescale 2.6.38 kernels In-Reply-To: <4F534D67.3010709@denx.de> References: <1330728909-12203-1-git-send-email-eric.nelson@boundarydevices.com> <20120302232545.464F212A7F30@gemini.denx.de> <4F51BBA9.4090608@googlemail.com> <20120303093826.C3054126F3B0@gemini.denx.de> <4F52015A.2080003@googlemail.com> <20120303133050.690AA82301@gemini.denx.de> <4F534D67.3010709@denx.de> Message-ID: <4F5378E0.6080206@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, On 03/04/12 13:09, Stefano Babic wrote: > On 03/03/2012 14:30, Wolfgang Denk wrote: >> Dear Dirk Behme, >> > > Hi, > >> In message <4F52015A.2080003@googlemail.com> you wrote: >>> >>>> Agreed. If these patches were only for backward compatibility I would >>>> not complain much. But they are known to introduce forward incompati- >>>> bilities with all this MACH_ID stuff, and this is what I would like to >>>> avoid. >>> >>> Now I'm just trying to learn something regarding [1]: >>> >>> Which changes would you accept in the category 'backward compatibility'? >> >> There are 3 commits in this series: >> >> [PATCH 1/3] i.MX6: mx6qsabrelite: add CONFIG_REVISION_TAG >> [PATCH 2/3] i.MX6: mx6qsabrelite: add MACH_TYPE_MX6Q_SABRELITE >> [PATCH 3/3] i.MX6: mx6qsabrelite: add ext2 support >> >> I dislike #1 because it uses the completely undocumented >> CONFIG_REVISION_TAG, and I agree with Marek's and Stefano's comments. > > A lot of boards are currently set CONFIG_REVISION_TAG. Sure, it would be > nice to document it. To be consistent we should drop this CONFIG_ from > all boards, or add documentation for it. > > However, I am asking if this TAG is really needed. I have searched in > 2.6.38 Kernel provided by Freescale if the TAG is really evaluated to > set different revisions of the boards, but I have not found anything. Is > it really needed ? If not, we should drop it. Linux's system_rev global variable is set to that value. You can check for it by "cat /proc/cpuinfo | grep Revision". > >> >> The problems I mentioned are with # 2, which now would depend on >> MACH_TYPE_MX6Q_SABRELITE, which may or may not exist. > > Right, I agree. And we do not know (maybe it is not this case) if > MACH_TYPE_MX6Q_SABRELITE will be dropped in the future. IMHO we should > not use mach-types at all.. +1 making the mach-type local to a board moves the maintenance burden to a board maintainer which is good because it can be decided on per board basis. Also, we should always raise the question if it is still needed for a particular board and don't let it in, if it is not... > >> >> Also, I think we should not need this any more at all, as we now have >> DT support in Linux on ARM, too. >> >> I see no issues with # 3. > > I will merge #3 into u-boot-imx > >> >>> And which changes 'introduce forward incompatibilities', and what are >>> these incompatibilities? >> >> See the recent problems that occurred when RMK decided to "clean up" >> the machids file. >> >>> (assuming this will be changed to >>> >>> --- a/include/configs/mx6qsabrelite.h >>> +++ b/include/configs/mx6qsabrelite.h >>> @@ -27,6 +27,7 @@ >>> #define CONFIG_SYS_MX6_CLK32 32768 >>> #define CONFIG_DISPLAY_CPUINFO >>> #define CONFIG_DISPLAY_BOARDINFO >>> +#define CONFIG_MACH_TYPE 3769 >> >> Such a change would avoid breakages as the ones mentioned above, but >> is this nice? Either we have a mach-types.h that can be used, or we >> don't, > > Personally I vote for the second choice. U-boot does not use mach-types, > and it is at the end only a parameter for the kernel. +1 > > I think the solution in the patch is better as to try to maintain the > mach-types file: not very nice, but setting its value is not different > as several other setups inside the configuration file that are very > board specifiv. +1 > And CONFIG_MACH_TYPE is well documented. 10x ;-) > >> in which case we should stop using any definitions from it, >> especially for new boards where it's not needed due to DT support in >> the kernel. > > Agree completely - mach-types introduces a strong dependency with the > kernel, and we do not need it. +1 I think, some more time is needed for the transition to DT. We should let the boards use non-DT configurations, but move the maintenance to the board maintainer (i.e. set the CONFIG_MACH_TYPE in the board config file). Also, soon there will be no non-DT boards accepted in the mainline kernel (probably, also, there will be no new machine types accepted in the machine types registry), so the need for the mach-type will just go away, no? -- Regards, Igor.