I have created a image relocation scheme where my boot loader can load an image into one of several positions in the flash and execute them individually. This involves remapping the IVT from that created by the compiler/linker so that the processor jumps into the correct relocated isr positions. Now, here is the problem I have come up against. I need the boot loader to jump into the new located code. I initially thought it would be okay to just take the reset vector (with the location offset added) out the IVT and jump to that. The only problem I found is that this jumps to a load of scatter file initialisation code that does not appear to use relative addressing and jumps back to the boot loader code. I have managed to get the boot loader to jump directly to main (using hard coding) and this works beautifully, all the routines appear to be using the correct relative branches and jumps. But the main address moves around depending on the image content and needs to be obtained and passed in to the boot loader for it to work, which could be done by getting it placed into an image header but is a little clumbsy, requiring use of FROMELF and some other post linker scripting as well as the header decoding at the other end. So my question is.. how can I get the Keil compiler to set the main address into the reset part of the vector table? Or how can I program the reset isr to jump direct to main with out it calling all this initilisation stuff? Or can I just take out the initialisation, if so how? Hope there is enough but not too much detail there for me to make sense.
Thanks I think the scatter file is just the default for the processor type and will be common. Where exactly do I put --apcs=/ropi, you are right about the images running OAAT. "..branch to image entry point" There's where it goes wrong because the only address I can currently get my hands on is the "reset vector" which in turn calls misbehaving scatter file routines (call absolute addresses). Are you perhaps saying that inclusion of the --apcs=/ropi will make these scatter routines behave? All I want to do is just jump straight to main, therefore missing out the scatterfile stuff. So I want to be able to assign the image IVT with the main address instead of the reset routines.
Hang on, its come to me, don't go away I'll try it before I embarrass myself with a supid solution.
I should be able to get away with changing Reset_Handler PROC EXPORT Reset_Handler [WEAK] IMPORT __main LDR R0, =__main BX R0 ENDP to Reset_Handler PROC EXPORT Reset_Handler [WEAK] IMPORT main LDR R0, =main BX R0 ENDP i have a little problem with testing this a currently my boot loader and images are the same program only with the IVTs modified as I have not got a physical transport working yet ( which is to be I2C ). So a little move time to prove concept. Thanks for all your help :)
> I think the scatter file is just the default for the processor type > and will be common.
You may have to come up with your own.
> Where exactly do I put --apcs=/ropi, you are right about the images > running OAAT.
Add this to the compiler options. And, BTW, according to the docs there are supposedly some limitations with Microlib. Just a heads up.
> Are you perhaps saying that inclusion of the --apcs=/ropi will make > these scatter routines behave?
It should, indeed.
> All I want to do is just jump straight to main, therefore missing > out the scatterfile stuff.
I don't think you want that.
> So I want to be able to assign the image IVT with the main address > instead of the reset routines.
But nobody cares what the address of your reset slot in the new vector table is. It'll never be used anyway. If a reset occurs, it takes down the vector table offset register and the boot loader vector table will be used again.
Regards Marcus
>But nobody cares what the address of your reset slot in >the new >vector table is. It'll never be used anyway. If a reset >occurs, it >takes down the vector table offset register and the boot >loader vector >table will be used again. No I care because the reset vector is what the boot loader reads from ( from the new image ) before jumping to that entry point. It does not have to be the reset vector it could be any of the vectors that is not used, i just use it as a entry point holder for the boot loader ( or infact the other images ) to use for their jump into it. Um, other vectors, now theres an idea!!!
> No I care because the reset vector is what the boot loader reads from > ( from the new image ) before jumping to that entry point.
That's what I meant. It is not used as actual Reset address, so you can use it for anything you like.
Regards Marcus http://www.doulos.com/arm/