[U-Boot] Mips: start.S Questions
I've figured out most of the boot process by following through the code, but I have a few questions about start.S:
1. Calls to RVECENT and XVEVENT: what exactly do these do? RVECENT just branches to the first parameter f, and does nothing with the second parameter. Yet the first argument passed is romReserved which is defined:
romReserved: b romReserved
Isn't that just an infinite loop? 2. What are these for?:
#ifdef CONFIG_PURPLE /* 0xbfc00400 */ .word 0xdc870000 .word 0xfca70000 .word 0x20840008....etc..
The rest seems pretty straightforward, just some processor specific things I need to research.
-- Regards, Peter Belm
Hi Peter,
I've figured out most of the boot process by following through the code, but I have a few questions about start.S:
- Calls to RVECENT and XVEVENT: what exactly do these do? RVECENT just
branches to the first parameter f, and does nothing with the second parameter.
These macros are used to setup up "reserved vector entries" - and "exception vector entries".
Yet the first argument passed is romReserved which is defined:
This is not quite correct. "romReserved" is only used for the, well, reserved entries. There are other parameters passed, these two are pretty important for example:
_start: RVECENT(reset,0) /* U-boot entry point */ RVECENT(reset,1) /* software reboot */
And they will yield calls to "reset".
romReserved: b romReserved
Isn't that just an infinite loop?
Yep - but the vectors are reserved, so they should never be jumped to.
- What are these for?:
#ifdef CONFIG_PURPLE /* 0xbfc00400 */ .word 0xdc870000 .word 0xfca70000 .word 0x20840008....etc..
Absolutely no idea :)
Maybe some magic stuff needed by some other hardware? I advise to ignore this unless you find something comparable in the boot code you have for your CPU.
Cheers Detlev
This is not quite correct. "romReserved" is only used for the, well, reserved entries. There are other parameters passed, these two are pretty important for example:
The thing I don't get is if you expand the RVECENT macro into the code wouldn't you get this:
_start: b reset; nop /* U-boot entry point */ b reset; nop /* software reboot */
b romReserved b romReserved
....
romReserved: b romReserved
So wouldn't it get stuck in an infinite loop straight away, calling romReserved recursively? I'm obviously overlooking something I think.
And what's the point of passing the second parameter (0-127) to RVECENT when it's not used?
Hi Peter,
This is not quite correct. "romReserved" is only used for the, well, reserved entries. There are other parameters passed, these two are pretty important for example:The thing I don't get is if you expand the RVECENT macro into the code wouldn't you get this:
_start: b reset; nop /* U-boot entry point */ b reset; nop /* software reboot */
b romReserved b romReserved
....
romReserved: b romReserved
So wouldn't it get stuck in an infinite loop straight away, calling romReserved recursively? I'm obviously overlooking something I think.
Why should it? I presume the CPU starts at _start, so it will "b reset", i.e. branch (jump) to "reset" and be happy. Its only if the CPU jumps to one the reserved vectors that it will loop. And well, as they are reserved, this is a legal thing to do, no? As the purple port works, I'm pretty sure they do not usually get jumped to there ;)
And what's the point of passing the second parameter (0-127) to RVECENT when it's not used?
This is only making life easier in the "create table" part of the code not to miss one of the defined vectors. So it really serves only documentary functions.
Cheers Detlev
Why should it? I presume the CPU starts at _start, so it will "b reset", i.e. branch (jump) to "reset" and be happy. Its only if the CPU jumps to one the reserved vectors that it will loop. And well, as they are reserved, this is a legal thing to do, no? As the purple port works, I'm pretty sure they do not usually get jumped to there ;)
I knew I must be missing something, I didn't see that the reset definition comes straight under all the other vector calls, so _start just runs through all the vectors if for some reason reset returns (twice) and would get trapped because of RVECENT(romReserved,2).
I shouldn't have missed my morning coffee :-P thank you for your help.
Hi Peter,
Why should it? I presume the CPU starts at _start, so it will "b reset", i.e. branch (jump) to "reset" and be happy. Its only if the CPU jumps to one the reserved vectors that it will loop. And well, as they are reserved, this is a legal thing to do, no? As the purple port works, I'm pretty sure they do not usually get jumped to there ;)I knew I must be missing something, I didn't see that the reset definition comes straight under all the other vector calls, so _start just runs through all the vectors if for some reason reset returns (twice) and would get trapped because of RVECENT(romReserved,2).
It seems to me that you may still be missing the point that a "b reset" is an unconditional jump, not a call, i.e. we will never return to the next instruction. A call would be a "bal reset", i.e. "branch and link" which puts the address of the next instruction into the $ra register. One would return with "jr $ra".
As I'm not really into MIPS, please don't ask me why MIPS has branch *and* jump mnemonics - I don't see how they designate different concepts.
Cheers Detlev
It seems to me that you may still be missing the point that a "b reset" is an unconditional jump, not a call, i.e. we will never return to the next instruction. A call would be a "bal reset", i.e. "branch and link" which puts the address of the next instruction into the $ra register. One would return with "jr $ra".
Yes, you're right, sorry. I wasn't thinking that through very far, now I know that is just goes to reset I'm continuing on.
I've done a fair bit of work with MIPS, so when it comes to instructions I'm actually fairly well versed (when I'm paying attention anyway!)
On Fri, Aug 21, 2009 at 6:23 PM, Peter Belm peterbelm@gmail.com wrote:
This is not quite correct. "romReserved" is only used for the, well, reserved entries. There are other parameters passed, these two are pretty important for example:
The thing I don't get is if you expand the RVECENT macro into the code wouldn't you get this:
_start: b reset; nop /* U-boot entry point */
On power on, first instruction that will get executed is 'b reset, nop'. So code will Jump to reset label from where actual booting sequence start.
b reset; nop /* software reboot */
b romReserved b romReserved
....
romReserved: b romReserved
So wouldn't it get stuck in an infinite loop straight away, calling romReserved recursively? I'm obviously overlooking something I think.
So romReserved will not get called in normal booting-sequence as code will jump to 'reset' label. In case of some exception 'romReserved' will be called and then board will struck in while loop.
Thanks, Chetan Nanda
And what's the point of passing the second parameter (0-127) to RVECENT when it's not used?
-- Regards, Peter Belm
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
participants (3)
-
Chetan Nanda -
Detlev Zundel -
Peter Belm