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

[Antony Pavlov]

On 3 July 2011 19:17, Shinya Kuribayashi <skuribay at gmail.com> wrote:

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

The generalization is possible if you have the piece of code for the
processor A and the piece of code for the processor B.
Then you can make generalization and produce the piece of code for the
both processors.

But it is very difficult to write universal code without attempts to
check of it ability to work.

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

In this particular example it is necessarily 0x9fc00xxx.
You have set CONFIG_TEXT_BASE=0x9fc00000.

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

No, I don't.

in barebox.lds.S you have:
---- begin ----
SECTIONS
{
        . = TEXT_BASE;
        /* read-only */
        _text = .;      /* Text and read-only data */
        .text : {
----- end ----

So '_start' link address is always TEXT_BASE.

Here is the code:
---- Shinya-san's code start (arch/mips/cpu/start.S) ----
        la      t0, 1f     // pc = 0xbfc00xxx
        jr      t0
1:
relocate:
        ADR	t0, _start, t1
        PTR_LI	t1, TEXT_BASE
---- Shinya-san's code end ----

ADR macro always run with pc == 'relocate' link address.
So ADR will compute '_start' link address.
This code always make t0 == t1.

Eventually you can try to check the code using an emulator.

--- Shinya-san's code start (arch/mips/cpu/start.S) ----
        la      t0, 1f     // pc = 0xbfc00xxx
        jr      t0
1:
relocate:
	ADR	t0, _start, t1		// pc = 0x9fc00xxx, t0=0x9fc00000
	PTR_LI	t1, TEXT_BASE           // t1 = 0x9fc00000
	beq	t0, t1, stack_setup
	 nop
---- Shinya-san's code end ----

-- 
Best regards,
  Antony Pavlov