[U-Boot] [PATCH] ARM: mx6ul: Apply ERR011115 errata workaround
Marcin Niestroj
m.niestroj at grinn-global.com
Tue Jul 24 13:20:54 UTC 2018
Hi Stefano,
On 23.07.2018 10:09, Stefano Babic wrote:
> Hi Marcin,
>
> On 19/07/2018 13:37, Marcin Niestroj wrote:
>> ERR011115 in IMX6UL errata says to use OCRAM memory above
>> 0x908000 (instead of 0x907000) for silicon revision 1.2 shipped
>> prior date code 1740.
>>
>> As we cannot check affected targets in runtime, apply that
>> workaround by default for all IMX6UL platforms. Leave possibility
>> to disable that workaround for non-affected targets, so more OCRAM
>> area can be used by SPL (e.g. for featureful SPL images).
>>
>
>
> I had a project with this issue - anyway, I disagree to apply the
> work-around for all MX6UL.
>
> Rather, we have no possibilities to detect and solve this at runtime.
> SPL is already loaded. But NXP has already fixed this in later
> production. Companies already know if there production is affected or
> not, and they can enable MX6UL_ERR011115 for their products.
I am not sure companies know about affected chips. We already know (you
and me) that such issue exists, because we've already run into it.
Unfortunately it took time to figure out what was the real reason of
non-functional device. Our client has manufactured devices (prototypes,
but still...) with affected chips in last two weeks, so in my opinion it
is easy to run into problems. So the idea of this patch was to prevent
that in future for all i.MX6UL boards.
In my opinion it is easier to figure out that ERR011115 workaround
can be disabled (after verifying that we do not use affected chips)
instead of figuring out why we have non-functional device (because we
were not aware of ERR011115 issue).
>
> We are already fighting with the OCRAM size, specially if other features
> (HAB and secure boot, further filesystems) are enabled. Reducing size is
> ok for some products (they cannot do in other way if they have some of
> these broken devices), it is not ok for other ones.
>
> I will propose to not set it as default for MX6UL.
>
>> Signed-off-by: Marcin Niestroj <m.niestroj at grinn-global.com>
>> ---
>> arch/arm/mach-imx/mx6/Kconfig | 9 +++++++++
>> include/configs/imx6_spl.h | 11 +++++++++--
>> 2 files changed, 18 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-imx/mx6/Kconfig b/arch/arm/mach-imx/mx6/Kconfig
>> index 521fad74b5..61708a0526 100644
>> --- a/arch/arm/mach-imx/mx6/Kconfig
>> +++ b/arch/arm/mach-imx/mx6/Kconfig
>> @@ -58,6 +58,15 @@ config MX6UL
>> select SYSCOUNTER_TIMER
>> bool
>>
>> +config MX6UL_ERR011115
>> + bool "Workaround for ERR011115 in IMX6UL Errata"
>> + depends on MX6UL
>> + default MX6UL
>> + help
>> + Say N here if you are sure that your platform is not affected
>> + with ERR011115. Doing so might be useful in case of featureful
>> + (big) SPL images.
>
> Boards Maintainer should decide themselves instead of setting this as
> default.
As written above, I do not think that board maintainer is usually
the person that knows which chip revision will be used in production.
>
>> +
>> config MX6UL_LITESOM
>> bool
>> select MX6UL
>> diff --git a/include/configs/imx6_spl.h b/include/configs/imx6_spl.h
>> index 720ff045a7..42d12c7503 100644
>> --- a/include/configs/imx6_spl.h
>> +++ b/include/configs/imx6_spl.h
>> @@ -19,16 +19,23 @@
>> * which consists of a 4K header in front of us that contains the IVT, DCD
>> * and some padding thus 'our' max size is really 0x00908000 - 0x00918000
>> * or 64KB
>> + * - Use 0x00909000 as start of OCRAM Free Area as a workaround for
>> + * ERR011115 in IMX6UL Errata
>> */
>> +#ifdef CONFIG_MX6UL_ERR011115
>> +#define CONFIG_SPL_TEXT_BASE 0x00909000
>> +#else
>> #define CONFIG_SPL_TEXT_BASE 0x00908000
>> -#define CONFIG_SPL_MAX_SIZE 0x10000
>> +#endif
>> +
>> +#define CONFIG_SPL_MAX_SIZE (0x00918000 - CONFIG_SPL_TEXT_BASE)
>
> Sebastian has already reported that this is wrong. Anyway, even if this
> was correct, it would be another issue and should be fixed in a separate
> patch. The issue in the commit messsage is fixed just moving
> CONFIG_MX6UL_ERR011115.
Sebastian reported CONFIG_SPL_PAD_TO to be wrong and I agree with that.
However CONFIG_SPL_MAX_SIZE in my opinion should be set as I proposed.
It is only used in linker scripts, mainly to check that we fit our code
within maximum SPL size.
Regards,
Marcin
>
>> #define CONFIG_SPL_STACK 0x0091FFB8
>> /*
>> * Pad SPL to 68KB (4KB header + 64KB max size). This allows to write the
>> * SPL/U-Boot combination generated with u-boot-with-spl.imx directly to a
>> * boot media (given that boot media specific offset is configured properly).
>> */
>> -#define CONFIG_SPL_PAD_TO 0x11000
>> +#define CONFIG_SPL_PAD_TO (CONFIG_SPL_MAX_SIZE + 0x1000)
>>
>> /* MMC support */
>> #if defined(CONFIG_SPL_MMC_SUPPORT)
>>
>
> Best regards,
> Stefano Babic
>
--
Marcin Niestroj
More information about the U-Boot
mailing list