[U-Boot] problem detecting CFI

[U-Boot] problem detecting CFI

[wpa at fastmail.fm]

I have a working u-boot 2008.10 on a mips 32 board and am trying to port
it over to u-boot 2009.06.
So I used buildroot 2009.08 to build the tool chain for my mips32 board
as well as u-boot2009.06. I also copied the previous u-boot
initialization code to
initialize timer, serial port, ram and etc from u-boot 2008.10 to
2009.06.

Right now the problem is the new u-boot 2009.06 does not detect cfi of
the flash. I am pretty sure u-boot is running from SDRAM when the
problem happens because the address is in the range of SDRAM. Please let
me know if you have any suggestion - I am running out of ideas. I am
attaching the printout from both the working u-boot 2008.10 and u-boot
2009.06 below.

Thanks a lot.

U-Boot 2009.06 (Sep 30 2009 - 18:41:26)

Reset Cause: Hardware Reset
DRAM:  64 MB
Top of RAM usable for U-Boot at: 98000000
Reserving 139k for U-Boot at: 97fdc000
Reserving 4352k for malloc() at: 97b9c000
Reserving 36 Bytes for Board Info at: 97b9bfdc
Reserving 36 Bytes for Global Data at: 97b9bfb8
Reserving 128k for boot params() at: 97b7bfb8
Stack Pointer at: 97b7bf98
Now running in RAM - U-Boot at: 97fdc000
flash detect cfi
not found
flash detect cfi
not found


U-Boot 2008.10 (Sep 30 2009 - 11:37:03)

Reset Cause: Hardware Reset
DRAM:  64 MB
Top of RAM usable for U-Boot at: 98000000
Reserving 736k for U-Boot at: 97f44000
Reserving 4352k for malloc() at: 97b04000
Reserving 44 Bytes for Board Info at: 97b03fd4
Reserving 36 Bytes for Global Data at: 97b03fb0
Reserving 128k for boot params() at: 97ae3fb0
Stack Pointer at: 97ae3f98
Now running in RAM - U-Boot at: 97f44000
flash detect cfi
fwc addr b0000000 cmd f0 f0 8bit x 8 bit
fwc addr b0000000 cmd ff ff 8bit x 8 bit
fwc addr b0000055 cmd 98 98 8bit x 8 bit
is= cmd 51(Q) addr b0000010 is= 4f 51
fwc addr b0000555 cmd 98 98 8bit x 8 bit
is= cmd 51(Q) addr b0000010 is= 4f 51
fwc addr b0000000 cmd f0 f0f0 16bit x 8 bit
fwc addr b0000000 cmd ff ffff 16bit x 8 bit
fwc addr b00000aa cmd 98 9898 16bit x 8 bit
is= cmd 51(Q) addr b0000020 is= 5151 5151
is= cmd 52(R) addr b0000022 is= 5252 5252
is= cmd 59(Y) addr b0000024 is= 5959 5959
device interface is 2
found port 2 chip 1 port 16 bits chip 8 bits

[U-Boot] problem detecting CFI

[wpa at fastmail.fm]

I just found something interesting - 

In my previous email I thought the CFI detection was running from DRAM,
but that assumption seems to be wrong. Previously I though it was
running from DRAM because I traced the execution using BDI into 
mips/start">cpu/mips/start.S relocate_code, it runs to the place where
it relocates itself. To be exact, here -

addi t0, s2, in_ram - start
jr t0
nop

I checked and found the pc register changed to pointing to a SDRAM
location, so relocation seems to be fine. I also load the symbol-file to
the DRAM location at that point. 
But afterwards if I set breakpoint to board_init_r, the breakpoint is
not triggered.

Then I realized if I keep using the same symbol-file, the breakpoint at
board_init_r can be triggered, and at that point, I can see the PC is
still pointing to the flash.

I don't understand how can the code, which has been relocated to SDRAM
at one point, suddenly going back to run in the flash when it calls
board_init_r. Can someone help me?

Thanks.


On Thu, 01 Oct 2009 16:47 -0500, wpa at fastmail.fm wrote:
> I have a working u-boot 2008.10 on a mips 32 board and am trying to port
> it over to u-boot 2009.06.
> So I used buildroot 2009.08 to build the tool chain for my mips32 board
> as well as u-boot2009.06. I also copied the previous u-boot
> initialization code to
> initialize timer, serial port, ram and etc from u-boot 2008.10 to
> 2009.06.
> 
> Right now the problem is the new u-boot 2009.06 does not detect cfi of
> the flash. I am pretty sure u-boot is running from SDRAM when the
> problem happens because the address is in the range of SDRAM. Please let
> me know if you have any suggestion - I am running out of ideas. I am
> attaching the printout from both the working u-boot 2008.10 and u-boot
> 2009.06 below.
> 
> Thanks a lot.
> 
> U-Boot 2009.06 (Sep 30 2009 - 18:41:26)
> 
> Reset Cause: Hardware Reset
> DRAM:  64 MB
> Top of RAM usable for U-Boot at: 98000000
> Reserving 139k for U-Boot at: 97fdc000
> Reserving 4352k for malloc() at: 97b9c000
> Reserving 36 Bytes for Board Info at: 97b9bfdc
> Reserving 36 Bytes for Global Data at: 97b9bfb8
> Reserving 128k for boot params() at: 97b7bfb8
> Stack Pointer at: 97b7bf98
> Now running in RAM - U-Boot at: 97fdc000
> flash detect cfi
> not found
> flash detect cfi
> not found
> 
> 
> U-Boot 2008.10 (Sep 30 2009 - 11:37:03)
> 
> Reset Cause: Hardware Reset
> DRAM:  64 MB
> Top of RAM usable for U-Boot at: 98000000
> Reserving 736k for U-Boot at: 97f44000
> Reserving 4352k for malloc() at: 97b04000
> Reserving 44 Bytes for Board Info at: 97b03fd4
> Reserving 36 Bytes for Global Data at: 97b03fb0
> Reserving 128k for boot params() at: 97ae3fb0
> Stack Pointer at: 97ae3f98
> Now running in RAM - U-Boot at: 97f44000
> flash detect cfi
> fwc addr b0000000 cmd f0 f0 8bit x 8 bit
> fwc addr b0000000 cmd ff ff 8bit x 8 bit
> fwc addr b0000055 cmd 98 98 8bit x 8 bit
> is= cmd 51(Q) addr b0000010 is= 4f 51
> fwc addr b0000555 cmd 98 98 8bit x 8 bit
> is= cmd 51(Q) addr b0000010 is= 4f 51
> fwc addr b0000000 cmd f0 f0f0 16bit x 8 bit
> fwc addr b0000000 cmd ff ffff 16bit x 8 bit
> fwc addr b00000aa cmd 98 9898 16bit x 8 bit
> is= cmd 51(Q) addr b0000020 is= 5151 5151
> is= cmd 52(R) addr b0000022 is= 5252 5252
> is= cmd 59(Y) addr b0000024 is= 5959 5959
> device interface is 2
> found port 2 chip 1 port 16 bits chip 8 bits
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] problem detecting CFI

[wpa at fastmail.fm]

I can fix this problem not but I really don't understand how the problem
happens in the first place. I found gp got changed in relocate_code in
file start.S. 

In relocate_code "function", the $gp is adjusted to point to the new
location, but somehow before program jumps to the relocated place, $gp
was changed. But I don't know where it is changed. So I used t8 register
to save the adjusted gp, and put it back before it jump to DRAM. But I
don't know why $gp was changed in the between. Can someone give me some
idea? I did not touch any thing else in this file.

        /*
         * Fix $gp:
         *
         * New $gp = (Old $gp - CONFIG_SYS_MONITOR_BASE) + Destination
         Address
         */
        move    t6, gp
        sub     gp, CONFIG_SYS_MONITOR_BASE
        add     gp, a2          /* gp now adjusted              */
        move    t8, gp          /*  add here <=== save gp               
        */

...

        /* Jump to where we've relocated ourselves.
         */
        move    gp, t8                        /* add here <=== copy gp
        back */
        addi    t0, s2, in_ram - _start
        jr      t0
        nop




On Thu, 01 Oct 2009 18:25 -0500, wpa@fastmail.fm wrote:
> I just found something interesting -
>
> In my previous email I thought the CFI detection was running from
> DRAM, but that assumption seems to be wrong. Previously I though it
> was running from DRAM because I traced the execution using BDI into
> mips/start">cpu/mips/start.S relocate_code, it runs to the place where
> it relocates itself. To be exact, here -
>
> addi t0, s2, in_ram - start jr t0 nop
>
> I checked and found the pc register changed to pointing to a SDRAM
> location, so relocation seems to be fine. I also load the symbol-file
> to the DRAM location at that point. But afterwards if I set breakpoint
> to board_init_r, the breakpoint is not triggered.
>
> Then I realized if I keep using the same symbol-file, the breakpoint
> at board_init_r can be triggered, and at that point, I can see the PC
> is still pointing to the flash.
>
> I don't understand how can the code, which has been relocated to SDRAM
> at one point, suddenly going back to run in the flash when it calls
> board_init_r. Can someone help me?
>
> Thanks.
>
>
> On Thu, 01 Oct 2009 16:47 -0500, wpa at fastmail.fm wrote:
> > I have a working u-boot 2008.10 on a mips 32 board and am trying to
> > port it over to u-boot 2009.06. So I used buildroot 2009.08 to build
> > the tool chain for my mips32 board as well as u-boot2009.06. I also
> > copied the previous u-boot initialization code to initialize timer,
> > serial port, ram and etc from u-boot 2008.10 to 2009.06.
> >
> > Right now the problem is the new u-boot 2009.06 does not detect cfi
> > of the flash. I am pretty sure u-boot is running from SDRAM when the
> > problem happens because the address is in the range of SDRAM. Please
> > let me know if you have any suggestion - I am running out of ideas.
> > I am attaching the printout from both the working u-boot 2008.10 and
> > u-boot 2009.06 below.
> >
> > Thanks a lot.
> >
> > U-Boot 2009.06 (Sep 30 2009 - 18:41:26)
> >
> > Reset Cause: Hardware Reset DRAM:  64 MB Top of RAM usable for U-
> > Boot at: 98000000 Reserving 139k for U-Boot at: 97fdc000 Reserving
> > 4352k for malloc() at: 97b9c000 Reserving 36 Bytes for Board Info
> > at: 97b9bfdc Reserving 36 Bytes for Global Data at: 97b9bfb8
> > Reserving 128k for boot params() at: 97b7bfb8 Stack Pointer at:
> > 97b7bf98 Now running in RAM - U-Boot at: 97fdc000 flash detect cfi
> > not found flash detect cfi not found
> >
> >
> > U-Boot 2008.10 (Sep 30 2009 - 11:37:03)
> >
> > Reset Cause: Hardware Reset DRAM:  64 MB Top of RAM usable for U-
> > Boot at: 98000000 Reserving 736k for U-Boot at: 97f44000 Reserving
> > 4352k for malloc() at: 97b04000 Reserving 44 Bytes for Board Info
> > at: 97b03fd4 Reserving 36 Bytes for Global Data at: 97b03fb0
> > Reserving 128k for boot params() at: 97ae3fb0 Stack Pointer at:
> > 97ae3f98 Now running in RAM - U-Boot at: 97f44000 flash detect cfi
> > fwc addr b0000000 cmd f0 f0 8bit x 8 bit fwc addr b0000000 cmd ff ff
> > 8bit x 8 bit fwc addr b0000055 cmd 98 98 8bit x 8 bit is= cmd 51(Q)
> > addr b0000010 is= 4f 51 fwc addr b0000555 cmd 98 98 8bit x 8 bit is=
> > cmd 51(Q) addr b0000010 is= 4f 51 fwc addr b0000000 cmd f0 f0f0
> > 16bit x 8 bit fwc addr b0000000 cmd ff ffff 16bit x 8 bit fwc addr
> > b00000aa cmd 98 9898 16bit x 8 bit is= cmd 51(Q) addr b0000020 is=
> > 5151 5151 is= cmd 52(R) addr b0000022 is= 5252 5252 is= cmd 59(Y)
> > addr b0000024 is= 5959 5959 device interface is 2 found port 2 chip
> > 1 port 16 bits chip 8 bits
> > _______________________________________________
> > U-Boot mailing list U-Boot at lists.denx.de
> > http://lists.denx.de/mailman/listinfo/u-boot
> _______________________________________________
> U-Boot mailing list U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] MIPS cpu has problem detecting CFI

[myuboot at fastmail.fm]

I think I found a problem in cpu/mips/start.S.

gp register is used to point to the SDRAM. But after gp is adjusted to
proper location, a C function flush_cache is called. But this function
actually changes gp register before gp is used to jump to SDRAM. That
makes the u-boot run from flash and fails to detect CFI.

Here is the assembler code for flush_cache.c
(gdb) disassem 0xb0000798
Dump of assembler code for function flush_cache:
0xb000078c <flush_cache+0>:     lui     gp,0x3
0xb0000790 <flush_cache+4>:     addiu   gp,gp,-32300
0xb0000794 <flush_cache+8>:     addu    gp,gp,t9

And here is how I fixed the issue -


diff --git a/u-boot-2009.08/cpu/mips/start.S
b/u-boot-2009.08/cpu/mips/start.S
index 57db589..0e8f8ed 100644
--- a/u-boot-2009.08/cpu/mips/start.S
+++ b/u-boot-2009.08/cpu/mips/start.S
@@ -321,6 +321,7 @@ relocate_code:
        move    t6, gp
        sub     gp, CONFIG_SYS_MONITOR_BASE
        add     gp, a2          /* gp now adjusted              */
+        move    t8, gp
        sub     s1, gp, t6      /* s1 <-- relocation offset     */

        /*
@@ -358,6 +359,7 @@ relocate_code:

        /* Jump to where we've relocated ourselves.
         */
+        move    gp, t8
        addi    t0, s2, in_ram - _start
        jr      t0
        nop

[U-Boot] MIPS cpu has problem detecting CFI

[Andrew Dyer]

On Sat, Oct 10, 2009 at 12:27 PM,  <myuboot@fastmail.fm> wrote:
> On Fri, 09 Oct 2009 12:16 -0500, "Andrew Dyer" <amdyer@gmail.com> wrote:
>> On Fri, Oct 9, 2009 at 11:21 AM, ?<myuboot@fastmail.fm> wrote:
>> > I think I found a problem in cpu/mips/start.S.
>> >
>> > gp register is used to point to the SDRAM. But after gp is adjusted to
>> > proper location, a C function flush_cache is called. But this function
>> > actually changes gp register before gp is used to jump to SDRAM. That
>> > makes the u-boot run from flash and fails to detect CFI.
>> >
>> > Here is the assembler code for flush_cache.c
>> > (gdb) disassem 0xb0000798
>> > Dump of assembler code for function flush_cache:
>> > 0xb000078c <flush_cache+0>: ? ? lui ? ? gp,0x3
>> > 0xb0000790 <flush_cache+4>: ? ? addiu ? gp,gp,-32300
>> > 0xb0000794 <flush_cache+8>: ? ? addu ? ?gp,gp,t9
>> >
>> > And here is how I fixed the issue -
>> >
>> >
>> > diff --git a/u-boot-2009.08/cpu/mips/start.S
>> > b/u-boot-2009.08/cpu/mips/start.S
>> > index 57db589..0e8f8ed 100644
>> > --- a/u-boot-2009.08/cpu/mips/start.S
>> > +++ b/u-boot-2009.08/cpu/mips/start.S
>> > @@ -321,6 +321,7 @@ relocate_code:
>> > ? ? ? ?move ? ?t6, gp
>> > ? ? ? ?sub ? ? gp, CONFIG_SYS_MONITOR_BASE
>> > ? ? ? ?add ? ? gp, a2 ? ? ? ? ?/* gp now adjusted ? ? ? ? ? ? ?*/
>> > + ? ? ? ?move ? ?t8, gp
>> > ? ? ? ?sub ? ? s1, gp, t6 ? ? ?/* s1 <-- relocation offset ? ? */
>> >
>> > ? ? ? ?/*
>> > @@ -358,6 +359,7 @@ relocate_code:
>> >
>> > ? ? ? ?/* Jump to where we've relocated ourselves.
>> > ? ? ? ? */
>> > + ? ? ? ?move ? ?gp, t8
>> > ? ? ? ?addi ? ?t0, s2, in_ram - _start
>> > ? ? ? ?jr ? ? ?t0
>> > ? ? ? ?nop
>>
>> Something seems weird here - IIRC, $gp is supposed to be saved in the
>> stack frame during the function prologue and restored from the frame
>> on exit. ?Also I think relying on $t8 is risky, as I don't believe it
>> is guaranteed by the ABI to be preserved across function calls.
>>
>> What compiler are you using? ?Can you post the whole flush_cache()
>> disassembly?
>
> You may be right. The c function should get the input arguments through
> stack. I just use the same toolchain(with -S option) to generate the
> assembler code and the assembler code does not show the modification on
> the gp register. I am attaching the whole assembler code file here too.
> But the assembler code I sent in my previous mail did show the gp
> pointer is changed. In that email, I got that assembler using  gdb
> through a BDI debugger. I don't have BDI with me today so I cann't give
> you the whole assembler code using BDI.
>
> Could it be the gcc toolchain  generates the wrong code when it is
> creating object file, but generates correct assembler code? Or the BDI
> is changing the assembler code at run time such that I see the wrong
> assembler code? But if that is the case, I don't know how to explain
> with my workaround/fix the board did come up even without bdi and it
> seems to work every time. I am so confused now. Any suggestion on
> anything I can try?

1) please don't top post, put replies on the bottom, I fixed this in this post.

2) reply to the list, there are a lot of smart people (better versed
in toolchains than I) who read it.
I've cc'd the list on this one.

3) the assembler looks fine, but it doesn't have the function prologue
that the gdb dump shows.  I doubt the bdi is modifying the asm.  I
/think/ the linker might be the part that inserts that or maybe the
compile after it generates the asm.  Try looking at the output of
'${CROSS_COMPILE}objdump --source cpu.o' and then
'${CROSS_COMPILE}objdump --source u-boot'.

4) where did the toolchain come from, what version, etc.?  Maybe run
gcc with the -v option to see the subprograms and options it sets.

5) try downloading the mips ELDK and build u-boot with that.

[U-Boot] MIPS cpu has problem detecting CFI

[myuboot at fastmail.fm]

On Sat, 10 Oct 2009 15:47 -0500, "Andrew Dyer" <amdyer@gmail.com> wrote:
> On Sat, Oct 10, 2009 at 12:27 PM,  <myuboot@fastmail.fm> wrote:
> > On Fri, 09 Oct 2009 12:16 -0500, "Andrew Dyer" <amdyer@gmail.com> wrote:
> >> On Fri, Oct 9, 2009 at 11:21 AM, ?<myuboot@fastmail.fm> wrote:
> >> > I think I found a problem in cpu/mips/start.S.
> >> >
> >> > gp register is used to point to the SDRAM. But after gp is adjusted to
> >> > proper location, a C function flush_cache is called. But this function
> >> > actually changes gp register before gp is used to jump to SDRAM. That
> >> > makes the u-boot run from flash and fails to detect CFI.
> >> >
> >> > Here is the assembler code for flush_cache.c
> >> > (gdb) disassem 0xb0000798
> >> > Dump of assembler code for function flush_cache:
> >> > 0xb000078c <flush_cache+0>: ? ? lui ? ? gp,0x3
> >> > 0xb0000790 <flush_cache+4>: ? ? addiu ? gp,gp,-32300
> >> > 0xb0000794 <flush_cache+8>: ? ? addu ? ?gp,gp,t9
> >> >
> >> > And here is how I fixed the issue -
> >> >
> >> >
> >> > diff --git a/u-boot-2009.08/cpu/mips/start.S
> >> > b/u-boot-2009.08/cpu/mips/start.S
> >> > index 57db589..0e8f8ed 100644
> >> > --- a/u-boot-2009.08/cpu/mips/start.S
> >> > +++ b/u-boot-2009.08/cpu/mips/start.S
> >> > @@ -321,6 +321,7 @@ relocate_code:
> >> > ? ? ? ?move ? ?t6, gp
> >> > ? ? ? ?sub ? ? gp, CONFIG_SYS_MONITOR_BASE
> >> > ? ? ? ?add ? ? gp, a2 ? ? ? ? ?/* gp now adjusted ? ? ? ? ? ? ?*/
> >> > + ? ? ? ?move ? ?t8, gp
> >> > ? ? ? ?sub ? ? s1, gp, t6 ? ? ?/* s1 <-- relocation offset ? ? */
> >> >
> >> > ? ? ? ?/*
> >> > @@ -358,6 +359,7 @@ relocate_code:
> >> >
> >> > ? ? ? ?/* Jump to where we've relocated ourselves.
> >> > ? ? ? ? */
> >> > + ? ? ? ?move ? ?gp, t8
> >> > ? ? ? ?addi ? ?t0, s2, in_ram - _start
> >> > ? ? ? ?jr ? ? ?t0
> >> > ? ? ? ?nop
> >>
> >> Something seems weird here - IIRC, $gp is supposed to be saved in the
> >> stack frame during the function prologue and restored from the frame
> >> on exit. ?Also I think relying on $t8 is risky, as I don't believe it
> >> is guaranteed by the ABI to be preserved across function calls.
> >>
> >> What compiler are you using? ?Can you post the whole flush_cache()
> >> disassembly?
> >
> > You may be right. The c function should get the input arguments through
> > stack. I just use the same toolchain(with -S option) to generate the
> > assembler code and the assembler code does not show the modification on
> > the gp register. I am attaching the whole assembler code file here too.
> > But the assembler code I sent in my previous mail did show the gp
> > pointer is changed. In that email, I got that assembler using  gdb
> > through a BDI debugger. I don't have BDI with me today so I cann't give
> > you the whole assembler code using BDI.
> >
> > Could it be the gcc toolchain  generates the wrong code when it is
> > creating object file, but generates correct assembler code? Or the BDI
> > is changing the assembler code at run time such that I see the wrong
> > assembler code? But if that is the case, I don't know how to explain
> > with my workaround/fix the board did come up even without bdi and it
> > seems to work every time. I am so confused now. Any suggestion on
> > anything I can try?
> 
> 1) please don't top post, put replies on the bottom, I fixed this in this
> post.
> 
> 2) reply to the list, there are a lot of smart people (better versed
> in toolchains than I) who read it.
> I've cc'd the list on this one.
> 
> 3) the assembler looks fine, but it doesn't have the function prologue
> that the gdb dump shows.  I doubt the bdi is modifying the asm.  I
> /think/ the linker might be the part that inserts that or maybe the
> compile after it generates the asm.  Try looking at the output of
> '${CROSS_COMPILE}objdump --source cpu.o' and then
> '${CROSS_COMPILE}objdump --source u-boot'.
> 
> 4) where did the toolchain come from, what version, etc.?  Maybe run
> gcc with the -v option to see the subprograms and options it sets.
> 
> 5) try downloading the mips ELDK and build u-boot with that.

Thanks for 1) and 2).
For 3), both results show GP register is modified.
the result of ${CROSS_COMPILE}objdump --source cpu.o is:

void flush_cache(ulong start_addr, ulong size)
{
  7c:   3c1c0000        lui     gp,0x0
  80:   279c0000        addiu   gp,gp,0
  84:   0399e021        addu    gp,gp,t9
        unsigned long lsize = CONFIG_SYS_CACHELINE_SIZE;
        unsigned long addr = start_addr & ~(lsize - 1);
  88:   2403fff0        li      v1,-16
  8c:   00831024        and     v0,a0,v1
        unsigned long aend = (start_addr + size - 1) & ~(lsize - 1);
  90:   2484ffff        addiu   a0,a0,-1
  94:   00852021        addu    a0,a0,a1
  98:   00831824        and     v1,a0,v1

        while (1) {
                cache_op(Hit_Writeback_Inv_D, addr);
  9c:   bc550000        cache   0x15,0(v0)
                cache_op(Hit_Invalidate_I, addr);
  a0:   bc500000        cache   0x10,0(v0)
                if (addr == aend)
  a4:   1443fffd        bne     v0,v1,9c <flush_cache+0x20>
  a8:   24420010        addiu   v0,v0,16
                        break;
                addr += lsize;
        }
#if defined(CONFIG_TNETVxxxx)
        invalidate_dcache();
  ac:   8f990000        lw      t9,0(gp)
  b0:   03200008        jr      t9
  b4:   00000000        nop

000000b8 <do_reset>:
void __attribute__((weak)) _machine_restart(void)
{
}

void flush_cache(ulong start_addr, ulong size)
{
  7c:   3c1c0000        lui     gp,0x0
  80:   279c0000        addiu   gp,gp,0
  84:   0399e021        addu    gp,gp,t9
        unsigned long lsize = CONFIG_SYS_CACHELINE_SIZE;
        unsigned long addr = start_addr & ~(lsize - 1);
  88:   2403fff0        li      v1,-16
  8c:   00831024        and     v0,a0,v1
        unsigned long aend = (start_addr + size - 1) & ~(lsize - 1);
  90:   2484ffff        addiu   a0,a0,-1
  94:   00852021        addu    a0,a0,a1
  98:   00831824        and     v1,a0,v1

        while (1) {
                cache_op(Hit_Writeback_Inv_D, addr);
  9c:   bc550000        cache   0x15,0(v0)
                cache_op(Hit_Invalidate_I, addr);
  a0:   bc500000        cache   0x10,0(v0)
                if (addr == aend)
  a4:   1443fffd        bne     v0,v1,9c <flush_cache+0x20>
  a8:   24420010        addiu   v0,v0,16
                        break;
                addr += lsize;
        }
#if defined(CONFIG_TNETVxxxx)
        invalidate_dcache();
  ac:   8f990000        lw      t9,0(gp)
  b0:   03200008        jr      t9
  b4:   00000000        nop

000000b8 <do_reset>:
void __attribute__((weak)) _machine_restart(void)
{
}


For 4), I generated the toolchain by myself using buildroot 2009.08. 
Using built-in specs. And the result of gcc -v is:
Target: mips-linux-uclibc
Configured with:
/home/root123/sources/buildroot-2009.08-k/toolchain_build_mips/gcc-4.4.1/configure
--prefix=/usr --build=i386-pc-linux-gnu --host=i386-pc-linux-gnu
--target=mips-linux-uclibc --enable-languages=c
--with-sysroot=/home/root123/sources/buildroot-2009.08-k/build_mips/staging_dir
--with-build-time-tools=/home/root123/sources/buildroot-2009.08-k/build_mips/staging_dir/usr/mips-linux-uclibc/bin
--disable-__cxa_atexit --enable-target-optspace --with-gnu-ld
--disable-libssp --disable-tls --enable-shared
--with-gmp=/home/root123/sources/buildroot-2009.08-k/toolchain_build_mips/gmp
--with-mpfr=/home/root123/sources/buildroot-2009.08-k/toolchain_build_mips/mpfr
--disable-nls --enable-threads --disable-multilib
--disable-decimal-float --with-float=soft --with-abi=32
--with-tune=mips32 : (reconfigured)
/home/root123/sources/buildroot-2009.08-k/toolchain_build_mips/gcc-4.4.1/configure
--prefix=/usr --build=i386-pc-linux-gnu --host=i386-pc-linux-gnu
--target=mips-linux-uclibc --enable-languages=c
--with-sysroot=/home/root123/sources/buildroot-2009.08-k/build_mips/staging_dir
--with-build-time-tools=/home/root123/sources/buildroot-2009.08-k/build_mips/staging_dir/usr/mips-linux-uclibc/bin
--disable-__cxa_atexit --enable-target-optspace --with-gnu-ld
--disable-libssp --disable-tls --enable-shared
--with-gmp=/home/root123/sources/buildroot-2009.08-k/toolchain_build_mips/gmp
--with-mpfr=/home/root123/sources/buildroot-2009.08-k/toolchain_build_mips/mpfr
--disable-nls --enable-threads --disable-multilib
--disable-decimal-float --with-float=soft --with-abi=32
--with-tune=mips32
Thread model: posix
gcc version 4.4.1 (GCC)

For most of the flags above, they are automatically added by buildroot.
Please let me know if there is anything wrong with the setting. 

4) I am not familiar with ELDK. It seems to be able to create toolchain
quickly. I will give it a try. How is the toolchain created by ELDK
different from buildroot or openembedded?

Thanks. 

[U-Boot] MIPS cpu has problem detecting CFI

[Andrew Dyer]

On Mon, Oct 12, 2009 at 10:10 AM,  <myuboot@fastmail.fm> wrote:
> Thanks for 1) and 2).
> For 3), both results show GP register is modified.
> the result of ${CROSS_COMPILE}objdump --source cpu.o is:
>
> void flush_cache(ulong start_addr, ulong size)
> {
> ?7c: ? 3c1c0000 ? ? ? ?lui ? ? gp,0x0
> ?80: ? 279c0000 ? ? ? ?addiu ? gp,gp,0
> ?84: ? 0399e021 ? ? ? ?addu ? ?gp,gp,t9

It looks like the code expects t9 to have the gp value.  I need to get
my setup up to -current and do a build test with eldk to help much
more (we don't do much mips anymore here, so my setup is a bit behind
the times).

> ? ? ? ?unsigned long lsize = CONFIG_SYS_CACHELINE_SIZE;
> ? ? ? ?unsigned long addr = start_addr & ~(lsize - 1);
> ?88: ? 2403fff0 ? ? ? ?li ? ? ?v1,-16
> ?8c: ? 00831024 ? ? ? ?and ? ? v0,a0,v1
> ? ? ? ?unsigned long aend = (start_addr + size - 1) & ~(lsize - 1);
> ?90: ? 2484ffff ? ? ? ?addiu ? a0,a0,-1
> ?94: ? 00852021 ? ? ? ?addu ? ?a0,a0,a1
> ?98: ? 00831824 ? ? ? ?and ? ? v1,a0,v1
>
> ? ? ? ?while (1) {
> ? ? ? ? ? ? ? ?cache_op(Hit_Writeback_Inv_D, addr);
> ?9c: ? bc550000 ? ? ? ?cache ? 0x15,0(v0)
> ? ? ? ? ? ? ? ?cache_op(Hit_Invalidate_I, addr);
> ?a0: ? bc500000 ? ? ? ?cache ? 0x10,0(v0)
> ? ? ? ? ? ? ? ?if (addr == aend)
> ?a4: ? 1443fffd ? ? ? ?bne ? ? v0,v1,9c <flush_cache+0x20>
> ?a8: ? 24420010 ? ? ? ?addiu ? v0,v0,16
> ? ? ? ? ? ? ? ? ? ? ? ?break;
> ? ? ? ? ? ? ? ?addr += lsize;
> ? ? ? ?}
> #if defined(CONFIG_TNETVxxxx)
> ? ? ? ?invalidate_dcache();
> ?ac: ? 8f990000 ? ? ? ?lw ? ? ?t9,0(gp)
> ?b0: ? 03200008 ? ? ? ?jr ? ? ?t9
> ?b4: ? 00000000 ? ? ? ?nop
>
> 000000b8 <do_reset>:
> void __attribute__((weak)) _machine_restart(void)
> {
> }
>

> For 4), I generated the toolchain by myself using buildroot 2009.08.
> Using built-in specs. And the result of gcc -v is:
> Target: mips-linux-uclibc
> Configured with:
> /home/root123/sources/buildroot-2009.08-k/toolchain_build_mips/gcc-4.4.1/configure
> --prefix=/usr --build=i386-pc-linux-gnu --host=i386-pc-linux-gnu
> --target=mips-linux-uclibc --enable-languages=c
> --with-sysroot=/home/root123/sources/buildroot-2009.08-k/build_mips/staging_dir
> --with-build-time-tools=/home/root123/sources/buildroot-2009.08-k/build_mips/staging_dir/usr/mips-linux-uclibc/bin
> --disable-__cxa_atexit --enable-target-optspace --with-gnu-ld
> --disable-libssp --disable-tls --enable-shared
> --with-gmp=/home/root123/sources/buildroot-2009.08-k/toolchain_build_mips/gmp
> --with-mpfr=/home/root123/sources/buildroot-2009.08-k/toolchain_build_mips/mpfr
> --disable-nls --enable-threads --disable-multilib
> --disable-decimal-float --with-float=soft --with-abi=32
> --with-tune=mips32 : (reconfigured)
> /home/root123/sources/buildroot-2009.08-k/toolchain_build_mips/gcc-4.4.1/configure
> --prefix=/usr --build=i386-pc-linux-gnu --host=i386-pc-linux-gnu
> --target=mips-linux-uclibc --enable-languages=c
> --with-sysroot=/home/root123/sources/buildroot-2009.08-k/build_mips/staging_dir
> --with-build-time-tools=/home/root123/sources/buildroot-2009.08-k/build_mips/staging_dir/usr/mips-linux-uclibc/bin
> --disable-__cxa_atexit --enable-target-optspace --with-gnu-ld
> --disable-libssp --disable-tls --enable-shared
> --with-gmp=/home/root123/sources/buildroot-2009.08-k/toolchain_build_mips/gmp
> --with-mpfr=/home/root123/sources/buildroot-2009.08-k/toolchain_build_mips/mpfr
> --disable-nls --enable-threads --disable-multilib
> --disable-decimal-float --with-float=soft --with-abi=32
> --with-tune=mips32
> Thread model: posix
> gcc version 4.4.1 (GCC)
>
> For most of the flags above, they are automatically added by buildroot.
> Please let me know if there is anything wrong with the setting.
>

nothing stands out, but I'm not a gcc expert.

> 4) I am not familiar with ELDK. It seems to be able to create toolchain
> quickly. I will give it a try. How is the toolchain created by ELDK
> different from buildroot or openembedded?

It comes with a prebuilt toolchain.  I believe the compiler version is
a bit older than what you are running (looks like 4.2.2 from the web
page).

[U-Boot] MIPS cpu has problem detecting CFI

[Andrew Dyer]

On Mon, Oct 12, 2009 at 5:11 PM, Andrew Dyer <amdyer@gmail.com> wrote:
> On Mon, Oct 12, 2009 at 10:10 AM, ?<myuboot@fastmail.fm> wrote:
>> Thanks for 1) and 2).
>> For 3), both results show GP register is modified.
>> the result of ${CROSS_COMPILE}objdump --source cpu.o is:
>>
>> void flush_cache(ulong start_addr, ulong size)
>> {
>> ?7c: ? 3c1c0000 ? ? ? ?lui ? ? gp,0x0
>> ?80: ? 279c0000 ? ? ? ?addiu ? gp,gp,0
>> ?84: ? 0399e021 ? ? ? ?addu ? ?gp,gp,t9
>
> It looks like the code expects t9 to have the gp value. ?I need to get
> my setup up to -current and do a build test with eldk to help much
> more (we don't do much mips anymore here, so my setup is a bit behind
> the times).

whoops - the above is wrong - t9 is supposed to have the starting
address of the function in it.  The 0 constants in the preceding two
instructions are supposed to be setup by the linker to give an offset
to the correct value of $gp for this function.

http://books.google.com/books?id=kk8G2gK4Tw8C&pg=PA413&lpg=PA413&dq=mips+%24gp+%24t9+register&source=bl&ots=cZ4SkaNyWt&sig=COnSNFcUHtReMS9vVMere9DFzQk&hl=en&ei=G6vTSuXFA42sMOf4xZQD&sa=X&oi=book_result&ct=result&resnum=4&ved=0CBUQ6AEwAw#v=onepage&q=mips%20%24gp%20%24t9%20register&f=false

was where I found this.