[theora-dev] help with libtool!

Conrad Parker conrad at metadecks.org
Fri Jun 1 20:41:56 PDT 2007


Hi André,

I've committed the modifications to configure.in in libogg svn:

https://trac.xiph.org/changeset/13008

Please confirm if that works for you :-)

thanks,

Conrad.

On 02/06/07, André Costa <andre.lnc at gmail.com> wrote:
> Hi,
>
> Good News!
>
> After about 10 days of hardwork with leon I got to put the Theora decoder
> (software) running on LEON (FPGA).
>
> That error was a Bug from OGG lib. I had a luck in to find a report from a
> group that put the Vorbis decoder on FPGA. It was a master thesis of 2
> students http://oggonachip.sourceforge.net/ and in general,
> they had almost the same solution of us, the function that spend much time
> of processing (like Fourier transform) in Hardware and the others in
> Software, but they used the LEON2 (I am using LEON3) and FPGA XESS XSV-800
> (I am using Cyclone).
> Vorbis uses the same OGG library and they found a solution for this
> unaligned address error.
>
> "Theoretically passing the appropriate CC environment
> variable to ./configure script and adding --disable-shared option
> (because the sparc-rtems-gcc that came with LECCS did not support shared
> library)
> should accomplish the task. Practically however we found that Ogg library's
> configure script failed to find the size of each integer variable type so
> extra lines in configure.in file were added as follows:
> AC_CHECK_SIZEOF(short,2)
> AC_CHECK_SIZEOF(int,4)
> AC_CHECK_SIZEOF(long,4)
> AC_CHECK_SIZEOF(long long,8)"
>
> http://oggonachip.sourceforge.net/oggonachip-1.0/report.pdf
> (page 44)
>
> After to fix this, I had others problems...
> 0x09 data_access_exception: Access error during load or store instruction
> I don't exactly why, but It is because the LEON or interface wasn't using
> the SDRAM, just SRAM, but Cyclone has 1 MB of SRAM and 16 SDRAM, and the
> addressing between these memory is not continuos. Then, It was happening a
> wrong addressing. After discovery this, the solution was just eliminate the
> SRAM from addressing (with a flag -nosram).
>
> Now, the Theora decoder is running on LEON (FPGA) decoding a vetor of
> inputs.
> I am thinking in to put this on uClinux in order to have a control of the
> video's files and the of player. What do you think about this?
>
>
> Tasks
>
> - To find a configuration that be able to decode the Theora (OK - Completed)
> - Synthesis of LEON3 (OK - Completed)
> - To compile the Theora for LEON and to run this inside of the LEON/FPGA (OK
> - Completed)
>
> - Integrate the processor and theora hardware
>   - Cut the software, generating the inputs for ReconReframes2 and to
> include a AMBA protocol on software.
>   - To change the handshake of Theora Hardware of AVALON to AMBA protocol.
>   - To discovery how to plug the Theora Hardware on AVALON and to control it
> with the LEON.
>
> - To run testbenchs and to verify if it can be possible to decoding in
> timing of player. If not,
> to do improvements and to run the testbenchs again.
>
>
> André Costa
>
>
> On 5/30/07, André Costa <andre.lnc at gmail.com> wrote:
> > Hi,
> >
> > I had a lot of problems with the compilation, but I got to generate a
> binary for LEON.
> > However, there is a error when I run this in LEON (at FPGA). I will to
> explain what I am doing.
> >
> > Firstly, it is the my compilation:
> >
> > # Clean all
> > cd /path_theora_hw/
> > make distclean
> > cd libogg-1.1.3/
> > make distclean
> >
> > # Set CROSS-Compiler and parameters
> > export CC=sparc-elf-gcc
> > export CXX=sparc-elf-gcc
> > export CFLAGS='-mv8 -msoft-float'
> >
> > #Configure and install OGG lib
> > ./configure --prefix=/path_theora_hw/ --target=sparc-elf --host=sparc-elf
> --enable-static
> > make
> > #I need to generate the bin's of OGG for LEON too and install in the
> path_theora_hw
> > make install
> >
> >
> > #Configure and make Theora for LEON (sparc)
> > cd ../
> > ./configure --prefix=/path_theora_hw/ --target=sparc-elf --host=sparc-elf
> --enable-static
> > #Here, I am compiling lib of theora and a dump_video_hardware.c
> > make
> >
> > ----------------------------------
> >
> > This dump_video_hardware.c is a modified file of dump_video.c that I
> created in order to test a player in LEON. I removed all file's functions
> and I am compiling with a vetor of inputs of datas encoded.
> >
> > Well, with these commands and some details* (below I will comment), I get
> the binary for LEON.
> > But, when I run there is this erro.
> >
> > IU in error mode (tt = 0x07)
> > 400013a4 e8220011 st %l4, [%o0 + %l1]
> >
> > I got some informations from leon_sparc list and the trap type 0x07 is a
> memory access to unaligned address.
> > So my store "st %l4,[%o0+%l1]" is trying to save register l4 to an
> unaligned address (o0+l1).
> > Some architectures support unaligned stores by SPARC does not (just in 4
> by 4 bytes).
> > Firsly I thought that it could be a bad compilation, but most likely it is
> not a bad compilation.
> > Some of the code may not be SPARC compatible and needs rewriting.
> > I debug this and I discovered that this error is from function
> ogg_sync_pageout() (OGG lib).
> > This function do some copies of buffers and it should be doing some
> unaligned access.
> > I will probably have to rewrite this, but it depends on how the code was
> written in the first place some times it can be easily solved by aligning
> data structures.
> >
> > I can believe this! , Bad news!! Timothy and Ralph, do you have any idea?
> do you know the OGG lib?
> >
> >
> > * Some considerations..
> > - A other doubt is with a file included in ogg/ogg.h, that is the
> "sys/type.h".
> > It is a C header that is in "/usr/include/sys/sys.h". Then, when this file
> is include I don't know if any libray (and/or define's) compiled to my
> computer (x86) is linked. I think its improbable, but maybe it can be the
> cause of the problem.
> >
> > - The Cross compile didn't get recognize the function toupper() in the
> tagcompare() <comment.c>. Because I am not using this (I think its just used
> in Encoder) I disabled this.
> >
> > Thanks,
> >
> >
> > André Costa
> >
> >
> >
> > On 5/24/07, Ralph Giles < giles at xiph.org > wrote:
> > > On Thu, May 24, 2007 at 06:19:20PM -0300, André Costa wrote:
> > >
> > > > Now I am working on BCC Cross-compiler in order to get the binaries
> for
> > > > LEON3 (Google SoC 2007).
> > >
> > > Woohoo! :)
> > >
> > > > I changed these lines of Makefile ...
> > > >
> > > > CC = sparc-elf-gcc -mv8 -msoft-float
> > > > CPP = sparc-elf-gcc -mv8 -msoft-float -E
> > >
> > > I agree libtool is probably not picking up on the change. Try something
> > > like CC="sparc-elf-gcc -mv8 -msoft-float" ./configure --target=sparc-elf
> > > and see if that works better.
> > >
> > > The GNU autotools generally have very poor support for cross-compilation
> > > though. It is probably worth just writing a custom makefile for it. Copy
> > > the list of relevent files from lib/(*/)Makefile.am and copy the
> > > relevent defines from config.h.in. You probably want:
> > >
> > > #define THEORA_DISABLE_ENCODE 1
> > >
> > > I don't think the library requires any of the others.
> > >
> > > -r
> > >
> > > > PS: I wasn't getting to communicate with the LEON in FPGA by serial
> > > > interface, but I discovered the problem. The number code of my FPGA
> was
> > > > slightly different. The difference was just in mapping of pins. When I
> > > > changed of FPGA (to a cyclone), I got to run a hello word! For while I
> am
> > > > using the cyclone, but after I will need to map all the pins.
> > >
> >
> >
> >
> >
> > --
> > André Costa
> > Gerente Técnico
> > Projeto BrazilIP
> > LSC IC-UNICAMP
> >
> > Cel: + 55 13 9201 1870
> > http://www.brazilip.org.br/
>
>
>
> --
> André Costa
> Gerente Técnico
> Projeto BrazilIP
> LSC IC-UNICAMP
>
> Cel: + 55 13 9201 1870
> http://www.brazilip.org.br/
> _______________________________________________
> theora-dev mailing list
> theora-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/theora-dev
>
>


More information about the theora-dev mailing list