[PATCH 1/3 v3] Add MIPS arch support to barebox

[Shinya Kuribayashi]

Hi,

On 7/2/11 12:29 AM, antonynpavlov wrote:
>> IIRC we will need to preserve ra for NMI case
>
> How this preserved value can be used?

Not used right now.

> We have no need to preserve ra because we have no full-grown exception handlers.

True.

> The MIPS cpu reset entry point is 0xbfc00000 (KSEG1, unmapped and
> uncached region).
> So code after _start label run from 0xbfc00000.

Starting from 0xBFC00000 might be a primary boot scenario in MIPS
systems, but in my opinion it's just one of the use cases.  Memory-
type flash devices are getting less used with newer MIPS SoCs.

> ---- Shinya-san's code start (arch/mips/cpu/start.S) ----
> 	setup_c0_status_reset
>
> 	/*
> 	 * Config: K0 should be set to the desired Cache Coherency
> 	 * Algorithm (CCA) prior to accessing Kseg0.
> 	 */
> 	mfc0	t0, CP0_CONFIG
> 	/* T.B.D. */
> 	mtc0	t0, CP0_CONFIG
>
> 	/*
> 	 * Config: (4KEm and 4KEp cores only) KU and K23 should be set to
> 	 * the desired CCA for USeg/KUSeg and KSeg2/3 respectively prior to
> 	 * accessing those regions.
> 	 */
> 	mfc0	t0, CP0_CONFIG
> 	/* T.B.D. */
> 	mtc0	t0, CP0_CONFIG
> ---- Shinya-san's code end ----
>
> does this code initialise KSEG0 cache mode?
> does this code change CP0_CONFIG at all?
> My answer is "no".

Correct.  Please keep in mind I didn't do anything set up in start.S.
I was thinking around how to generalize the initialization procedures
how we could maintain/support various MIPS processors, and what shape
of code would be reasonable (and scalable).

> But bellow, you can see switching to KSEG0 (label 1f linked to 0x9fc00xxx) ...
>
> ---- Shinya-san's code start (arch/mips/cpu/start.S) ----
> 	/* Switch to CKSEG0 segment */
> 	la	t0, 1f
> 	/* T.B.D. -- Convert an addree of the label '1f' into CKSEG0 */
> 	jr	t0
>
> 1:
> ---- Shinya-san's code end ----

It's intended to be converted to CKSEG0, but it's not necessarily
0x9fc00xxx.

> Let's see relocate code:
> ---- Shinya-san's code start (arch/mips/cpu/start.S) ----
> relocate:
> 	ADR	t0, _start, t1			# t0<- current position of code
> 	PTR_LI	t1, TEXT_BASE
> 	beq	t0, t1, stack_setup
> 	 nop
> ---- Shinya-san's code end ----
>
> This code try to check if relocation needs. It try to compute _start<<current>>
> address.
>
> But
>    * _start link address is KSEG0 address 0x9fc00000;
>    * we have already switched to KSEG0, so _start<<current>>  address
> is 0x9fc00000 too.

No.  ADR tries to compute 'PC-relative' _start address.  If it starts
from physical 0xbfc0000, t0 is set up to 0xbfc0000 even if _start link
address is CKSEG0.  If it starts from physical 0xA0100000, t0 is set
up to 0xA0100000, and in that case _start link address is supposed to
be set to 0x80100000.  The 'link address' is supposed to be used
_after_ relocation.   You see?

I'm afraid there might be something missing in my prototyoe, though.