From: myuboot at fastmail.fm <myuboot@fastmail.fm>
To: u-boot@lists.denx.de
Subject: [U-Boot] MIPS cpu has problem detecting CFI
Date: Mon, 12 Oct 2009 10:10:05 -0500 [thread overview]
Message-ID: <1255360205.12428.1339623867@webmail.messagingengine.com> (raw)
In-Reply-To: <c166aa9f0910101347k3c08064y92598a696438d95@mail.gmail.com>
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.
next prev parent reply other threads:[~2009-10-12 15:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-01 21:47 [U-Boot] problem detecting CFI wpa at fastmail.fm
2009-10-01 23:25 ` wpa at fastmail.fm
2009-10-02 21:42 ` wpa at fastmail.fm
2009-10-09 16:21 ` [U-Boot] MIPS cpu has " myuboot at fastmail.fm
[not found] ` <c166aa9f0910091016x6fe7bc77tc16222b6fb7c3c5d@mail.gmail.com>
[not found] ` <1255195660.1993.1339394551@webmail.messagingengine.com>
2009-10-10 20:47 ` Andrew Dyer
2009-10-12 15:10 ` myuboot at fastmail.fm [this message]
2009-10-12 22:11 ` Andrew Dyer
2009-10-12 22:28 ` Andrew Dyer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1255360205.12428.1339623867@webmail.messagingengine.com \
--to=myuboot@fastmail.fm \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.