i.MX7D PU_IROM_MMU_EN_VAR address

[bryan_odonoghue]

Hello.

Looking at u-boot for the i.MX6 we see the following addresses

+#define MX6DQ_PU_IROM_MMU_EN_VAR 0x009024a8
+#define MX6DLS_PU_IROM_MMU_EN_VAR 0x00901dd0
+#define MX6SL_PU_IROM_MMU_EN_VAR 0x00900a18

associated with this code

 /*
 * If the MMU is enabled, we have to notify the ROM
 * code, or it won't flush the caches when needed.
 * This is done, by setting the "pu_irom_mmu_enabled"
 * word to 1. You can find its address by looking in
 * the ROM map. This is critical for
 * authenticate_image(). If MMU is enabled, without
 * setting this bit, authentication will fail and may
 * crash.
 */
 /* Check MMU enabled */
 if (get_cr() & CR_M) {
 if (is_cpu_type(MXC_CPU_MX6Q) ||
 is_cpu_type(MXC_CPU_MX6D)) {
 /*
 * This won't work on Rev 1.0.0 of
 * i.MX6Q/D, since their ROM doesn't
 * do cache flushes. don't think any
 * exist, so we ignore them.
 */
 writel(1, MX6DQ_PU_IROM_MMU_EN_VAR);
 } else if (is_cpu_type(MXC_CPU_MX6DL) ||
 is_cpu_type(MXC_CPU_MX6SOLO)) {
 writel(1, MX6DLS_PU_IROM_MMU_EN_VAR);
 } else if (is_cpu_type(MXC_CPU_MX6SL)) {
 writel(1, MX6SL_PU_IROM_MMU_EN_VAR);
 }
 }

I'm getting a weird bug on i.MX7 where if I call authenticate_image() with dcache on for a particular image it never returns from ROM - however if I disable dcache before authenticate_image() and re-enable it directly after, the routine authenticates the image trouble free.

Is there a requirement to inform the IROM on i.MX7 in a similar fashion to i.MX6 in terms of writing a register to tell the IROM to perform a flush when MMU is on ?

I don't see the i.MX6 requirement documented nor do I see the above hard-coded addresses document for i.MX6 (perhaps I'm not looking in the right place) - which is why I'm asking for i.MX7.

If the i.MX7 requires a similar write to a register to tell IROM what to-do could NXP share that information - i.e. address location and appropriate bits to write ?

If not any insights as to why disabling dache before authenticate_image() should make a difference to the stability of the authenticate_image() callback would be highly appreciated.

[bryan_odonoghue]

Hi Utkarsh

Let me see if I can find a way to share our binaries with you. I'm assuming you have an I.mx7 board with a jtag. 

I'd like to give you the same image twice one with and one without dcache enabled. 

[utkarsh_gupta]

Hi Bryan,

I tested this on u-boot imx_v2016.03_4.1.15_2.0.0_ga branch which is a u-boot release from NXP BSP and this issue does not occur. Please test using this u-boot branch and let me know your results.

Thanks,

Utkarsh

[utkarsh_gupta]

Hi Bryan,

I am not sure what A B C are.

Which repository does this u-boot belong to? Also are you working on an open chip or closed chip?

Are you working on a MX7 NXP reference board? If yes then please provide which board and the boot images with it and I can test here.

Thanks,

Utkarsh

[bryan_odonoghue]

Hi Utkarsh

Relevant u-boot base is

* 1989374 - configs: Finish migration of PHY_GIGE (2 months ago).

gcc:

arm-linux-gnueabihf-gcc -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabihf-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/arm-linux-gnueabihf/5/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-armhf-cross/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-armhf-cross --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-armhf-cross --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libgcj --enable-objc-gc --enable-multiarch --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-werror --enable-multilib --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=arm-linux-gnueabihf --program-prefix=arm-linux-gnueabihf- --includedir=/usr/arm-linux-gnueabihf/include
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4)

ld:

arm-linux-gnueabihf-ld -v
GNU ld (GNU Binutils for Ubuntu) 2.26.1

The interesting thing is if I run images B, A, C through authenticate_image() instead of image A, B, C there's no problem.

If I switch off the dcache - B, A, C or A, B, C or any other combination works.

There definitely seems to be some relationship between the dcache and the lockup.

I might be able to share an image with you guys offline that shows the lockup. Since I don't have a JTAG header on the board I can't do much deep inspection at the moment.

[utkarsh_gupta]

Hi Bryan,

Which release branch of u-boot are you working with?

Thanks,

Utkarsh

[bryan_odonoghue]

For reference here is a fix that works for me

+ dcache_disable();
load_addr = (uint32_t)hab_rvt_authenticate_image(
HAB_CID_UBOOT,
ivt_offset, (void **)&start,
(size_t *)&bytes, NULL);
+ dcache_enable();