ts-7000
[Top] [All Lists]

[ts-7000] Re: Crunch-compiled software runs on TS7260 but crashes under

To:
Subject: [ts-7000] Re: Crunch-compiled software runs on TS7260 but crashes under TS7300
From: "jeremie.chevalier" <>
Date: Tue, 30 Jun 2009 12:22:26 -0000
Dear all,

Just in case someone else encounters the issue in the future, I had the same 
problem and I managed to resolve it.

It seems that by default, the MaverickCrunch coprocessor is enabled on TS-72xx 
boards, but not on TS-7400 ones. Thus, this explains why programs compiled with 
MaverickCrunch optimization (gcc) would run on TS-72xx but not on TS-7400 (you 
got "Segmentation Fault" of "Illegal instruction" error).

However the MaverickCrunch coprocessor can be easily enabled or disabled 
through some registers of the EP9302 processor. The first register to use is 
called "SysSWlock" (address 0x809300c0, 8 bits), its aim is to lock/unlock 
access to EP9302 control registers. The second important register is called 
"DeviceCfg" (address 0x80930080, 32 bits), it's a control register used to 
enable or disable every devices attached to the processor. Bit 23 of that 
latter register is called "CPENA" (for "Co-Processor ENAble"). If set to 0, it 
disables the MaverickCrunch, and of course if set to 1 it enables it. To be 
able to change that bit in "DeviceCfg", you have first to write the magic key 
"0xaa" into the "SysSWlock" register (which switches from 0x00 to 0x1). This 
trick unlocks access to "DeviceCfg" register. Every time you want to modify a 
bit in a control register (like "DeviceCfg"), you will have to write this magic 
key in "SysSWlock".

You can use the binaries "peek8", "peek32", "poke8" and "poke32" provided by 
Technologic Systems to read and write to the registers, given their address. As 
of today, these utilities can be found here (for TS-7400): 
ftp://ftp.embeddedarm.com/ts-arm-sbc/ts-7400-linux/binaries/ts-utils/.

Here's an example on how to turn on MaverickCrunch coprocessor on the TS-7400:

 peek32 0x80930080

=> This reads the "DeviceCfg" register, and outputs "0x8140d00" (could be 
different). When this value is converted to binary, we can observe that bit 23 
is set to 0, thus MaverickCrunch is disabled.
=> When setting bit 23 to 1, the new value to write to the register is 
"0x8940d00". We will write it later.

 peek8 0x809300c0

=> We read the "SysSWlock" register and this outputs 0x0, which means that 
access to control registers is locked. We will unlock it with the following 
command:

 poke8 0x809300c0 0xaa
 peek8 0x809300c0

=> This should now outputs 0x1, which means that our lock is opened. We can 
thus now write the new value to "DeviceCfg":

 poke32 0x80930080 0x8940d00

=> We just wrote the new value for register "DeviceCfg", where bit 23 is set to 
1. Now, the MaverickCrunch coprocessor is enabled!

Best regards,
Jeremie.


--- In  "marcel.groothuis" <> wrote:
>
> --- In  "Martin Guy" <martinwguy@> wrote:
> >
> > 2007/11/16, marcel.groothuis <margrosoft@>:
> > > All software is identical, the CPU's are identical
> > 
> > > Does somebody have any idea or suggestions why the same software runs
> > > on the TS7260 and fails on the TS7300 (all other non-crunch software
> > > runs perfectly)?
> > 
> > Different silicon revisions of the Maverick Crunch hardware have
> > different timing bugs that result in wrong results and mistaken
> > conditional branches - springing them or not depends on the exact
> > sequence of FPU instructions and how far apart they are in time.
> 
> > D1 E0 E1 have the same set of bugs (at least, no changes were made in
> > the hardware)
> > I gather that in E2 the bugs have moved around, so the old compiler
> > workarounds no longer work
> > 
> > 
> >     M
> >
> 
> I just checked our boards. We have both the E1 and E2 revisions
> TS7260, E2 rev TS7300 and E2 rev TS7400. The crunch test runs on both
> the E1 and E2 TS7260 boards and not on all TS7300 and TS7400. I will
> read the errata in more detail but I am now wondering if it has
> something to do with the bootloaders.
> 
> All TS7260 board have Redboot and can run the test succesfully and the
> other boards (TS7300 and TS7400) have a different bootloader for
> smaller boot times. Maybe Redboot initializes the hardware "better"
> than the TS bootloader.
> 
> Can somebody from TS explain me if there are differences in the
> hardware initialization between Redboot and the TS bootloaders that
> could have something to do with the Maverick FPU?
> 
> Grt,
> Marcel
>




------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/ts-7000/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/ts-7000/join
    (Yahoo! ID required)

<*> To change settings via email:
     
    

<*> To unsubscribe from this group, send an email to:
    

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

<Prev in Thread] Current Thread [Next in Thread>
Admin

Disclaimer: Neither Andrew Taylor nor the University of NSW School of Computer and Engineering take any responsibility for the contents of this archive. It is purely a compilation of material sent by many people to the birding-aus mailing list. It has not been checked for accuracy nor its content verified in any way. If you wish to get material removed from the archive or have other queries about the archive e-mail Andrew Taylor at this address: andrewt@cse.unsw.EDU.AU