[U-Boot] i.MX6: mx6qsabrelite: allow use with Freescale 2.6.38 kernels

[Igor Grinberg]

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 at 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.