Hello freinds,
Having looked around for almost 2 days for getting some intro about the bootloading process, I would first elaborate a little about what I have understood about the entire thing.
Having referred to a plethora of forum threads, this is what I conclude.
Basically, the ARM7 executes in 3 different modes viz. boot mode, user flash mode and user ram mode. On reset, the core always is in boot mode and executes the boot loader.Now the boot block which is normally resident in the top 64 bytes in user flash gets remapped into the top 64 bytes of the onchip 2GB memory, if I understood correctly. Now heres my first question: If the boot block gets remapped to the top 64 bytes of on-chip memory, then does it mean that the reset vector is reset at location 0 relative to this address?..
If im correct on this one, does it mean that the 'LDR pc,reset_addr' which is usally the very first instruction in the startup file does(or is supposed to do) a short jump to reset addr which should be the very first word of my bootloader right?..the boot loeader should then do all the hardware initializations alongwith the allocation of various stacks for different operating modes including the user mode. It then does have to map the vectors back into the user RAM and load the OS image into the ram as well right? Now this is where things go haywire in my mind: 1. In one of the forum threads here, they said the startup file may use absolute addresses only whereas the manual says that once the MEMMAP register has been assigned a certain value, then based on this value, the core will automatically assume a certain base and accordingly calculate the addresses of the various interrupt vectors. Could someone please clarify what will it actually do?
2. Now how do I tell the linker that I would like to 'install' a given bootloader at a certain location. And how do I decidew where my bootloader should be. I plan to use U boot and while there is enough documentation to get started, I would be pleased if someone could get me straight on this one. I mean the bootloader should be able to boot the system automatically on startup. So I should be ideally placing it in non volatile flash right. Please give me some pointers on this one since these kind of things are bugging me a lot. The documentation on the UBoot website talks about the canyonlands board while I am using a local made board whch uses the LPC2129.If what I wrote above is indeed what it is actually done on the LPC2100s then I might have to specify an absolute address in the very first instruction which typically causes the jump to the reset handler. oh by the way im using uvision4
Keen to get things started, but Im still lost in this huge pile of information scattered in bits and pieces. May be I should get used to the real world now.
Keen to hear from you guys.
I don't know much about this. But would like to try to give you a short/simple answer.
1. You can always execute your codes from the 4G (32 bits) memory addresses. For X86, the 4G (32 bits) memory addresses are mainly for DRAM. For MCU, the 4G (32 bits) memory addresses can be Flash/ROM or SRAM. So, your code can be executed from the Internal (On Chip) Flash.
2. The ARM7TDMI processor has 7 operating modes, with 8 interrupt vectors (Exceptions). The addresses of the 8 interrupt vectors are fixed, can NOT be changed. But the memory addresses can be remapped.
3. After the On Chip (First) boot-loader finishes its work, and YOUR code start. It must start from address 0x0000-0000. And if you need to remap the memory addresses, Your code has to do the remapping work.
4. Every time an IRQ (ex: UART or Timer) happens, the ARM core goes to the address 0x0000-0018.
5. Every time an FIQ happens, the ARM core goes to the Address 0x0000-001C.
6. Your boot-loader (Second) starts from address 0x0000-0000, after Your boot-loader finished its work, your application starts from somewhere, so your application does not have its own interrupt vectors, because 0x0000-0000 is occupied by Your boot-loader. And YOUR code need to handle such a problem.
I didn't notice Per's latest post, until I finished my posting.
Imagine that, Your boot-loader (Second) does not support UART; but your application has to support UART.
When your application is running, and an UART IRQ happens, the ARM core goes to the address 0x0000-0018 looking for the UART support. So the content of 0x0000-0018 must point to the correct UART ISR.
About point 6. the secondary bootloader should run with memory mapping = User Flash Mode. The Application loaded by secondary bootloader should run with memory mapping = User RAM Mode: so the Interrupt vectors of application are re-mapped to Static RAM without conflict with the secondary bootloader Interrupt vectors; How described on manual ...interrupt vectors, continue to appear in their original location in addition to the re-mapped address (ram mode).