From b5b0e4e351e20a606de22db6a56ad6bc1e2aa8fd Mon Sep 17 00:00:00 2001 From: Fabio Estevam Date: Fri, 9 Mar 2018 08:25:00 -0300 Subject: [PATCH 1/2] imximage: Remove failure when no IVT offset is found Sometimes imximage throws the following error: CFGS board/freescale/vf610twr/imximage.cfg.cfgtmp CFGS board/freescale/vf610twr/imximage.cfg.cfgtmp MKIMAGE u-boot-dtb.imx Error: No BOOT_FROM tag in board/freescale/vf610twr/imximage.cfg.cfgtmp arch/arm/mach-imx/Makefile:100: recipe for target 'u-boot-dtb.imx' failed Later on, when running mkimage for the u-boot.imx it will succeed in finding the IVT offset. Looks like some race condition happening during parallel build when processing mkimage for u-boot-dtb.imx and u-boot.imx. A proper fix still needs to be implemented, but as a workaround let's remove the error when the IVT offset is not found. It is useful to have such message, especially during bring-up phase, but the build error that it causes is severe, so better avoid the build error for now. The error checking can be re-implemented later when we have a proper fix. Reported-by: Breno Lima Reported-by: Thomas Petazzoni Signed-off-by: Fabio Estevam --- tools/imximage.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/tools/imximage.c b/tools/imximage.c index eb7e682038..ed9d935903 100644 --- a/tools/imximage.c +++ b/tools/imximage.c @@ -777,11 +777,6 @@ static uint32_t parse_cfg_file(struct imx_header *imxhdr, char *name) (*set_dcd_rst)(imxhdr, dcd_len, name, lineno); fclose(fd); - /* Exit if there is no BOOT_FROM field specifying the flash_offset */ - if (imximage_ivt_offset == FLASH_OFFSET_UNDEFINED) { - fprintf(stderr, "Error: No BOOT_FROM tag in %s\n", name); - exit(EXIT_FAILURE); - } return dcd_len; } From 314d9f7e3eff41873011d9a0687f469680a00074 Mon Sep 17 00:00:00 2001 From: Yasushi SHOJI Date: Thu, 8 Mar 2018 13:21:10 +0900 Subject: [PATCH 2/2] imx: syscounter: make sure asm is volatile Without the volatile attribute, compilers are entitled to optimize out the same asm(). In the case of __udelay() in syscounter.c, it calls `get_ticks()` twice, one for the starting time and the second in the loop to check the current time. When compilers inline `get_ticks()` they see the same `mrrc` instructions and optimize out the second one. This leads to infinite loop since we don't get updated value from the system counter. Here is a portion of the disassembly of __udelay: 88: 428b cmp r3, r1 8a: f8ce 20a4 str.w r2, [lr, #164] ; 0xa4 8e: bf08 it eq 90: 4282 cmpeq r2, r0 92: f8ce 30a0 str.w r3, [lr, #160] ; 0xa0 96: d3f7 bcc.n 88 <__udelay+0x88> 98: e8bd 8cf0 ldmia.w sp!, {r4, r5, r6, r7, sl, fp, pc} Note that final jump / loop at 96 to 88, we don't have any `mrrc`. With a volatile attribute, the above changes to this: 8a: ec53 2f0e mrrc 15, 0, r2, r3, cr14 8e: 42ab cmp r3, r5 90: f8c1 20a4 str.w r2, [r1, #164] ; 0xa4 94: bf08 it eq 96: 42a2 cmpeq r2, r4 98: f8c1 30a0 str.w r3, [r1, #160] ; 0xa0 9c: d3f5 bcc.n 8a <__udelay+0x8a> 9e: e8bd 8cf0 ldmia.w sp!, {r4, r5, r6, r7, sl, fp, pc} a2: bf00 nop I'm advised[1] to put volatile on all asm(), so this commit also adds it to the asm() in timer_init(). [1]: https://lists.denx.de/pipermail/u-boot/2018-March/322062.html Signed-off-by: Yasushi SHOJI Reviewed-by: Fabio Estevam --- arch/arm/mach-imx/syscounter.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-imx/syscounter.c b/arch/arm/mach-imx/syscounter.c index 9290918dca..1d4ebfe343 100644 --- a/arch/arm/mach-imx/syscounter.c +++ b/arch/arm/mach-imx/syscounter.c @@ -62,7 +62,7 @@ int timer_init(void) unsigned long val, freq; freq = CONFIG_SC_TIMER_CLK; - asm("mcr p15, 0, %0, c14, c0, 0" : : "r" (freq)); + asm volatile("mcr p15, 0, %0, c14, c0, 0" : : "r" (freq)); writel(freq, &sctr->cntfid0); @@ -82,7 +82,7 @@ unsigned long long get_ticks(void) { unsigned long long now; - asm("mrrc p15, 0, %Q0, %R0, c14" : "=r" (now)); + asm volatile("mrrc p15, 0, %Q0, %R0, c14" : "=r" (now)); gd->arch.tbl = (unsigned long)(now & 0xffffffff); gd->arch.tbu = (unsigned long)(now >> 32);