Flash security .cfmconfig block optimized away by RVCT

[fpga_comp]

I am trying to compile ChibiOS 3.0.0 stable release on RVCT compiler V 5.05 update 1 (build 106). I have bricked a Teensy LC (Kinetis KL26) already because the security block inside hal_lld.c has optimized away by the C compiler. i.e. the security location was overwritten by other pieces of code and irreversibly disable the bulk erase function.

Note: KL26 is close enough to KL25 FREESCALE_FREEDOM_KL25Z" with minor differences in peripherals.

The security block inside hal_lld.c

Code: Select all

/*===========================================================================*/
/* Driver local variables and types.                                         */
/*===========================================================================*/

__attribute__ ((section(".cfmconfig")))
const uint8_t _cfm[0x10] = {
  0xFF,  /* NV_BACKKEY3: KEY=0xFF */
  0xFF,  /* NV_BACKKEY2: KEY=0xFF */
  0xFF,  /* NV_BACKKEY1: KEY=0xFF */
  :
  :


I will be using a modified version of the Freescale startup code which has the block inside their assembly code, their security block is at the correct location.

Code: Select all

                IF      :LNOT::DEF:RAM_TARGET
                AREA    |.ARM.__at_0x400|, CODE, READONLY
                DCB     BackDoorK0, BackDoorK1, BackDoorK2, BackDoorK3
                DCB     BackDoorK4, BackDoorK5, BackDoorK6, BackDoorK7
                DCB     FPROT0,     FPROT1,     FPROT2,     FPROT3
                DCB     FSEC,       FOPT,       0xFF,     0xFF
                ENDIF


Code: Select all

    .ARM.__at_0x400                          0x00000400   Section       16  startup_mkl16.o(.ARM.__at_0x400)

So please double check the map file to make sure that the security block is indeed when you think it is!
Might want to rethink that security block strategy to make sure that the compile cannot optimize it away. Don't make the assumption that if it is in the C code, then it will be in the image. What is the behavior of one compiler might not be the same on a different version or a different one.

[utzig]

I'm pretty sure gcc is acting correctly for this. I don't really have RVCT and know nothing about it, but if you can make/suggest a patch I would be glad to apply (it could even be some #pragma to disable to removal).

Cheers,
Fabio Utzig

[fpga_comp]

I don't know whether the existing code works correctly for IAR compiler, so I only change the behavior specifically for RVCT.
This uses the section ".ARM.__at_0x400" for RVCT and now the block is preserved and at the right location.

Code: Select all

#ifdef __CC_ARM
__attribute__ ((section(".ARM.__at_0x400")))
#else
__attribute__ ((section(".cfmconfig")))
#endif


FYI: ARM Linker: "Using __at sections to place sections at a specific address"
http://infocenter.arm.com/help/index.js ... BBAEE.html

[utzig]

Thanks, I applied the patch. Hopefully it should have been corrected now and not cause trouble to other users.

Cheers,
Fabio Utzig

[flabbergast]

I'm probably having trouble with this. Compiling ChibiOS git /demos/KINETIS/RT-TEENSY3 with gcc (4.9.3 20150529) gives

Code: Select all

.cfmprotect
 *(.cfmconfig)
                0x0000000000000100                _text = .


in build/ch.map
and /demos/KINETIS/RT-FREEDOM-KL25Z

Code: Select all

.cfmprotect
 *(.cfmconfig)
                0x00000000000000c0                _text = .


in build/ch.map. The actual section (16 bytes on 0x400) was just zeroes.

I didn't try it on the teensy (fortunately), but I did try to upload to FRDM-KL25Z and it *was* causing problems (the MBED bootloader refused to upload; loading through gdb/CMSIS-DAP resulted in running code, but subsequently inaccessible MCU through debugger.

When I compile RedoX's teensy branch it places the cfmprotect section at the right place, so I'll try to understand how does he do it.

EDIT: ChibiOS.git /testhal/KINETIS/I2C also places cfmconfig at the right place. ???

[flabbergast]

Found it: It's the USE_LTO setting in the Makefile. If enabled, cfmconfig is optimized away. Is there a way to protect against this?

EDIT: This can be fixed for gcc by adding 'used' attribute:

Code: Select all

__attribute__ ((used,section(".cfmconfig")))


in os/hal/ports/KINETIS/KL2x/hal_lld.c:40
But I don't really know much about gcc and/or other compilers, so could anyone more knowledgeable please check this? Works for me, even with USE_LTO=yes.

[flabbergast]

However this solution interferes with the MCHCK patch I posted in the other thread - the point is that this forces the flashcfg section to always be non-zero at 0x400, so the generated firmware binary for MCHCK does not start at 0xc00, but at 0x400. How to reconcile these? Is there a trick that could be used in the linker script, or should I just make another separate linker script for MCHCK (although it uses the same mk20dx128 chip) which would put the flashcfg bytes somewhere later (they'll just be ignored by the firmware and MCU)? Or should I attempt some #define/#if hackery in hal_lld.c?

[flabbergast]

Decided to create extra linker script(s) for MCHCK, to move the cfmconfig section to a dummy place after the bootloader. See the commit here. Please let me know if this is not a good solution (I mean it works, it is just not completely clean), and how could I do it in a better way.

[utzig]

I'm really curious about the need of the flash_config section at all when using a bootloader. Since the firmware will be stored way beyond the place where the flash configuration is found, would the linker script even need it? Would removing the flash config section and moving the vectors to the the same flash section cause any harm?

What I'm thinking is something in the following lines: https://gist.github.com/utzig/623267a7b21c3b0b153e

Cheers,
Fabio Utzig

[flabbergast]

Yes, that works, thanks! (The flash should start at 0xc00, since that's where the bootloader ends - before there was an extra "flash0" section for .isr, and since it's no longer there - it absorbed to "flash", "flash" should move from 0xd10 to 0xc00.)

(I've committed it into my tree here.)