Boot from SRAM

[l yk]

Posted on October 23, 2017 at 10:49

I have a question about the stm32f103xx. I want to know how it boots from Embeded SRAM. I have known that the IBUS of Cortex-M3 can't access the SRAM from the reference manual. When boots from the SRAM,  how Cortex-M3 fetches instructions from SRAM?

[Amel NASRI]

Posted on October 23, 2017 at 19:03

Hi

?,

The following table in

http://www.st.com/content/ccc/resource/technical/document/reference_manual/59/b9/ba/7f/11/af/43/d5/CD00171190.pdf/files/CD00171190.pdf/jcr:content/translations/en.CD00171190.pdf

describes how to configure the Boot pins to boot from SRAM:

-Amel

[Tesla DeLorean]

Posted on October 23, 2017 at 19:10

The F1 however does have some quirky behaviour in that it executes the ResetHandler at a specific address, not the one in the vector table.

The F1 can definitely run code from RAM, I usually copy the code there rather than boot into it

[waclawek.jan]

Posted on October 23, 2017 at 19:29

Code can be fetched through S-bus, there's no problem in that.

The tricky part is the reset vector, which have to be at 0x0000004. 'F1 can't remap RAM, and RM0008 mysteriously says ' STM32F10xxx microcontrollers implement a special mechanism to be able to boot also from SRAM'.

The F1 however does have some quirky behaviour in that it executes the ResetHandler at a specific address, not the one in the vector table.

I'd lοve to hear the dιrty details.

Jan

[Tesla DeLorean]

Posted on October 23, 2017 at 20:14

I've discussed it here before, the original work goes back a decade, and I think it was something user

Vetter.Johannes

‌ looked at also, might be wrong.

Anyway look at the GNU startup.s files for the STM32F1 series, at the end of the table is a hex word, this is AT the address the part calls and loads the PC from +4 so that it functions as expected. You could place the ResetHandler right there and not use the hack.

The argument as I recall was that the processor is running some other code first, I did a bunch of work to determine the address, and more work to try and see what other code might be shadowed. This was before the codes showed up in the startup.s files, and they weren't in the Keil or IAR versions. RAM booting was seen as a possible attack vector for ROP, that and seeing what code was actually being run, because it clearly wasn't using the vector it was being supplied.

I don't remember the address, and it likely differs in the high, medium, etc version of the part, 0x20000108 and 0x200001E0 rings a bell,

.equ BootRAM, 0xF1E0F85F ; something like ldr pc, [pc - 0x1E0]

...

g_pfnVectors:

.word _estack .word Reset_Handler .word NMI_Handler .word HardFault_Handler .word MemManage_Handler .word BusFault_Handler .word UsageFault_Handler .word 0 .word 0

....

.word 0

.word 0 .word TIM5_IRQHandler .word SPI3_IRQHandler .word UART4_IRQHandler .word UART5_IRQHandler .word TIM6_IRQHandler .word TIM7_IRQHandler .word DMA2_Channel1_IRQHandler .word DMA2_Channel2_IRQHandler .word DMA2_Channel3_IRQHandler .word DMA2_Channel4_IRQHandler .word DMA2_Channel5_IRQHandler .word ETH_IRQHandler .word ETH_WKUP_IRQHandler .word CAN2_TX_IRQHandler .word CAN2_RX0_IRQHandler .word CAN2_RX1_IRQHandler .word CAN2_SCE_IRQHandler .word OTG_FS_IRQHandler .word 0 .word 0 .word 0 .word 0 .word 0 .word 0 .word 0 .word 0 .word 0 .word 0 .word 0 .word 0 .word 0 .word 0 .word 0 .word 0 .word 0 .word 0 .word 0 .word 0 .word 0 .word 0 .word 0 .word 0 .word 0 .word 0 .word 0 .word 0 .word 0 .word 0 .word 0 .word 0 .word 0 .word 0 .word 0 .word 0 .word BootRAM /* @0x1E0. This is for boot in RAM mode for STM32F10x Connectivity line Devices. */

[Tesla DeLorean]

Posted on October 23, 2017 at 20:26

Ok, here's one of the threads the 17-May-2011 date is deceptive, that's the day the forum core melted, all posts from before have this same time stamp, the thread was perhaps from 2010 or before.

 

[l yk]

Posted on October 24, 2017 at 08:24

Can code be  fetched through S-bus? I have looked through relevant documents of ARM Cortex-M3 but I can't  find where it is. Could you tell me where you find it? I am looking forward to your reply.

[waclawek.jan]

Posted on October 24, 2017 at 09:20

[l yk]

Posted on October 24, 2017 at 13:08

Sorry to disturb, may I don't describe my question clearly.

When MCU starts, CPU needs to fetch instructions from 0x0 to get MSP value and 0x4 to get reset handler through I-BUS.

My question is When booting from embedded SRAM, CPU needs to fetch instruction from 0x0 to get MSP value and 0x4 to get reset handler,

but embedded SRAM is accessiable only at address 0x20000000. How CPU gets MSP value and reset handler when starts from SRAM?

[l yk]

Posted on October 24, 2017 at 13:38

Could you tell me which bus the CPU gets the MSP value and reset handler through when booting from embedded SRAM? And why?