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: "charliem_1216" <>
Date: Tue, 30 Jun 2009 13:38:48 -0000
Hi Jeremie --

--- In  "jeremie.chevalier" <> 
wrote:
>
> 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).

That's strange, perhaps RedBoot is meddling, it wouldn't be the first time.
> 
> 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".
> 

I guess you are running the 2.4 TS kernel?  In vanilla 2.6 kernels, enabling 
crunch is a kernel compile option.  IIRC, crunch support is more involved than 
just enabling crunch via these registers, as the kernel needs to know what to 
save during context switches, etc.  

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

But, crunch output from almost all gcc's is subtly broken.  Martin Guy has done 
a lot of work to get this straightened out.  If you are using crunch, you 
definitely should read over his notes and try his modified gcc:

http://martinwguy.co.uk/martin/crunch/

regards, .......... Charlie
> 
> Best regards,
> Jeremie.
> 
> 
> --- In  "marcel.groothuis" <margrosoft@> 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