[U-Boot] [PATCH 0/4]: imx: mx6: use OTP for temperature grade and freq grade

[Nikolay Dimitrov <picmaster@mail.bg>]

Hi Tim,

On 05/08/2015 10:26 PM, Tim Harvey wrote:
> On Fri, May 8, 2015 at 10:35 AM, Nikolay Dimitrov
> <picmaster@mail.bg> wrote:
>> Hi Tim,
>>
>>
>> On 05/08/2015 06:42 PM, Tim Harvey wrote:
>>>
> <snip>
>>>
>>> Your right - There is no indication in the IMX6SDLRM that OTP
>>> indicates either temperature grade 'or' speed grade, however my
>>> testing looks like they implement the same OTP settings for this
>>> as the IMX6DUAL/IMX6QUAD as indicated in the IMX6DQRM.
>>>
>>> I have tested these patches with the following SoC's I have
>>> available: - MCIMX6S7CVM08AC (IMX6S r1.2, Industrial temp,
>>> 800MHz) - shows 'industrial (-40C to 105C) 792 MHz' (correct) -
>>> MCIMX6S5EVM10AC (IMX6S r1.2, Extended Commercial temp, 1GHz) -
>>> shows 'extended commercial (-20C to 105C) 996 MHz (at 792 MHz)'
>>> (correct) - MCIMX6U7CVM08AB (IMX6DL r1.1, Industrial temp,
>>> 800MHz) - shows 'industrial (-40C to 105C) 792 MHz' (correct) -
>>> MCIMX6Q6AVT10AC (IMX6Q r1.2. Automotive temp, 1GHz) - shows
>>> 'automotive (-40C to 125C) 996 MHz (at 792 MHz)' (correct)
>>>
>>> I'll send our FAE a question to verify - perhaps your FAE simply
>>>  answered the questions based on the reference manual (which is
>>> notoriously lacking info and in some cases wrong).
>>>
>>> I encourage anyone with additional parts to test these patches
>>> and report if they show accurate information. If anyone has any
>>> IMX6SX I would appreciate removing the check that ignores the
>>> OTP for that and seeing if the results make sense.
>>
>>
>> Here are the results from riotboard (imx6s) testing with your
>> patches against Stefano's tree:
>>
>>
>> Before: CPU:   Freescale i.MX6SOLO rev1.1 at 792 MHz
>>
>> After patch 1: CPU:   Freescale i.MX6SOLO rev1.1 996 MHz (at 792
>> MHz)
>>
>> After patch 2: CPU:   Freescale i.MX6SOLO rev1.1 996 MHz (at 792
>> MHz)
>>
>> After patch 3: CPU:   Freescale i.MX6SOLO rev1.1 // No idea why I
>> lost the MHz values
>
> Nikolay,
>
> thats an issue in my patch if you don't have CONFIG_IMX6_THERMAL.
> I'll fix in a followup patch version
>
>>
>> After patch 4: CPU:   Freescale i.MX6SOLO rev1.1
>>
>>
>> MHz values are missing after patch 3, and looking diagonally at the
>> code I don't see a reason. Next, riotboard doesn't have
>> CONFIG_IMX6_THERMAL by default. When added, I get this:
>>
>>
>> $ make u-boot.imx ...
> <snip>
>>
>> Are there additional CONFIG dependencies?
>
> Looks like CONFIG_IMX6_THERMAL also needs CONFIG_DM_THERMAL (includes
> thermal-uclass from drivers/thermal/Makefile)
>
> Thanks for testing this. If you can get it working please let me know
> what the actual part markings are on the parts you test with.

The updated CONFIGs fixed the build. Here are the outputs of all boards
where I can easily run mainline U-Boot.


Riotboard 1, part number MCIMX6S5DVM10AB
========================================
CPU:   Freescale i.MX6SOLO rev1.1 commercial (0C to 95C) 996 MHz (at 792
MHz)
CPU:   Temperature 53 C

Riotboard 2, part number MCIMX6S5DVM10AC
========================================
CPU:   Freescale i.MX6SOLO rev1.2 commercial (0C to 95C) 996 MHz (at 792
MHz)
CPU:   Temperature 42 C

Marsboard, part number MCIMX6D5EYM10AC
======================================
CPU:   Freescale i.MX6D rev1.2 extended commercial (-20C to 105C) 996
MHz (at 792 MHz)
CPU:   Temperature 38 C


Btw, as the information in the "CPU:" line gets bigger and bigger, it's
probably worth thinking about splitting it into separate lines. This
will simplify the text formatting tricks, can be easily controlled by
CONFIG directives and can look neater. But even if you don't change it,
it looks fine to me - I like to see info, and if I don't need it, I can
always cut it off easily.

Thanks for working on this patch series.

Regards,
Nikolay

PS: I have also some more customer boards with imx6d rev 1.3 and some
imx6q with unknown revisions, but can't test there as mainline u-boot
has broken spi flash support in SPL since 2014.07 and I hadn't had time
to fix it and port it (although I would love to).