[U-Boot] Mips: start.S Questions

[U-Boot] Mips: start.S Questions

[Peter Belm]

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

[U-Boot] Mips: start.S Questions

[Detlev Zundel]

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:
>
>    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. 

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.

>    2. 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

-- 
Some people unfortunately like  jumping up and down about spaces but not code.
[...]   I'd rather read good poetry written in very bad hand writing than bad
poetry written in beautiful handwriting, and I think the same is true of code.
           -- Alan Cox <20090701130018.115ce0ea@lxorguk.ukuu.org.uk>
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] Mips: start.S Questions

[Peter Belm]

>
> 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?

-- 
Regards,
Peter Belm

[U-Boot] Mips: start.S Questions

[Detlev Zundel]

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

-- 
Lobbing insults is not a useful technique for reaching understanding.
                                        -- Thomas Bushnell, BSG
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] Mips: start.S Questions

[Peter Belm]

>
> 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.

-- 
Regards,
Peter Belm

[U-Boot] Mips: start.S Questions

[Detlev Zundel]

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

-- 
Q: What is a compact city?
A: It's a city that can be guarded by finitely many near-sighted
   policemen.
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] Mips: start.S Questions

[Peter Belm]

>
> 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!)

-- 
Regards,
Peter Belm

[U-Boot] Mips: start.S Questions

[Chetan Nanda]

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 at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
>