Compilation of Plasma SW under Linux

Hi All,

I have previously send this message to comp.arch.embedded, but probably it was "NTG", as it is more associated with the soft CPU on FPGA problem. Therefore I try once (the last one ;-) ) again in the comp.arch.fpga

I have successfully compiled the Plasma soft CPU for my Xilinx Spartan 3E Starter Kit (the version of Plasma core

formatting link
contains the top entity and UCF needed for this board).

However I was not able to generate my own software for this CPU. The provided tools (

formatting link
formatting link
formatting link
) are "Windows-only" and unfortunately do not run under wine emulator.

I have changed the makefile to make use of the mips-linux-gnu-gcc or mipsel-linux-gnu-gcc packages (available from

formatting link
)

It was also necessary to replace some backslashes with slashes.

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv # Customize for Linux CC_X86 = gcc -Wall -O -g CP = cp RM = rm -rf #BIN_MIPS = ../../mips/sde/bin VHDL_DIR = ../vhdl #GCC_MIPS = mipsel-linux-gnu-gcc $(CFLAGS) #AS_MIPS = mipsel-linux-gnu-as #LD_MIPS = mipsel-linux-gnu-ld #DUMP_MIPS = mipsel-linux-gnu-objdump GCC_MIPS = mips-linux-gnu-gcc $(CFLAGS) AS_MIPS = mips-linux-gnu-as LD_MIPS = mips-linux-gnu-ld DUMP_MIPS = mips-linux-gnu-objdump

# Customize for Windows ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

To make sources compiling I had to add the redefiniton of strncat2 to the rtos.h file:

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv #define strcpy strcpy2 //don't use intrinsic functions #define strcat strcat2 #define strncat strncat2 // code.txt & test.bin Entry=0x10000c50 length=0=0x0

I can try to force mips-linux-gnu-as to generate the PIC file by adding the "-KPIC" option, but then I get the following warning:

mips-linux-gnu-as -KPIC -o boot.o ../tools/boot.asm ../tools/boot.asm: Assembler messages: ../tools/boot.asm:35: Warning: No .cprestore pseudo-op used in PIC code ../tools/boot.asm:85: Warning: No .cprestore pseudo-op used in PIC code

Anyway the convert_bin complains as before.

So I have two questions:

1) How to avoid the problem with PIC code? 2) Is it possible to generate the ROM contents with the standard tool like mips(el)-linux-gnu-objcopy ? Or how to fix the convert to work under linux?
--
TIA & Regards,
Wojciech M. Zabolotny
Reply to
Wojciech Zabolotny
Loading thread data ...

Hello,

I'd suggest that you try compiling your own mips gcc cross-compiler on your linux machine, using as target *mipsel-elf* (I am using it for Plasma).

Below is a makefile that should automate most of the job (beware of wrapped lines).

Hope it can help.

Steven

GCC_VER=gcc-4.0.2 BINUTILS_VER=binutils-2.16.1 GDB_VER=gdb-6.6 INSIGHT_VER=insight-6.6 TARGET = mipsel INSTALL_DIR= /opt/mipsic/

all: @echo "## GNU SDK builder (binutil-gcc-gdb) for target machine $(TARGET) " @echo " 1) Make sure that Makefile variable INSTALL_DIR shall point to an *existing* installation directory" @echo " 2) Create a new environment variable MIPSIC and set its value to $(INSTALL_DIR)" @echo " 3) Check that your PATH environmenet variable points to $(INSTALL_DIR)/bin " @echo " 4) Run make build_sdk" insight : $(INSTALL_DIR)/bin/$(TARGET)-elf-insight

binutils : $(INSTALL_DIR)/bin/$(TARGET)-elf-ar gdb : $(INSTALL_DIR)/bin/$(TARGET)-elf-gdb gcc : $(INSTALL_DIR)/bin/$(TARGET)-elf-gcc

utils : $(INSTALL_DIR)/bin/bin2mif \ $(INSTALL_DIR)/bin/bin2hex # $(INSTALL_DIR)/bin/hex2mif \ # $(INSTALL_DIR)/bin/elf2bin \

build_sdk : \ $(INSTALL_DIR)/bin/$(TARGET)-elf-gcc \ $(INSTALL_DIR)/bin/$(TARGET)-elf-gdb \ $(INSTALL_DIR)/bin/$(TARGET)-elf-insight \

$(INSTALL_DIR) : mkdir -p $(INSTALL_DIR) export PATH=$PATH:$(INSTALL_DIR)/bin

# # Binutils # build : -mkdir build

$(BINUTILS_VER).tar.bz2 : @echo Downloading $(BINUTILS_VER) @wget ttp://ftp.gnu.org/pub/gnu/binutils/$(BINUTILS_VER).tar.bz2

build/$(BINUTILS_VER)/ : $(BINUTILS_VER).tar.bz2 build @echo Uncompressing $(BINUTILS_VER) @tar xvfj $(BINUTILS_VER).tar.bz2 > /dev/null mv $(BINUTILS_VER) build/$(BINUTILS_VER)

$(INSTALL_DIR)/bin/$(TARGET)-elf-objdump : build/$(BINUTILS_VER) $(INSTALL_DIR) cd build/$(BINUTILS_VER); \ ./configure --prefix=$(INSTALL_DIR) --target=$(TARGET)-elf ;\ make ;\ make install ;\ cd ../

# # gcc #

$(GCC_VER).tar.bz2 : @echo Downloading $(GCC_VER) @wget

formatting link
$(GCC_VER)/$(GCC_VER).tar.bz2

build/$(GCC_VER)/ : $(GCC_VER).tar.bz2 @echo Uncompressing $(GCC_VER) @tar xvfj $(GCC_VER).tar.bz2 > /dev/null mv $(GCC_VER) build/$(GCC_VER)

$(INSTALL_DIR)/bin/$(TARGET)-elf-gcc : build/$(GCC_VER) $(INSTALL_DIR)/bin/$(TARGET)-elf-objdump cd build/ ; ./$(GCC_VER)/configure --prefix=$(INSTALL_DIR)

--target=$(TARGET)-elf --enable-languages=c ;\ make ;\ make install

# # gdb # $(GDB_VER).tar.bz2 : @echo Downloading $(GDB_VER) wget

formatting link
$(GDB_VER).tar.bz2 build/$(GDB_VER)/ : $(GDB_VER).tar.bz2 build @echo Uncompressing gdb tar xvfj $(GDB_VER).tar.bz2 > /dev/null mv $(GDB_VER) build/$(GDB_VER) $(INSTALL_DIR)/bin/$(TARGET)-elf-gdb : build/$(GDB_VER) $(INSTALL_DIR)/bin/$(TARGET)-elf-gcc cd build/$(GDB_VER); \ sh ./configure --prefix=$(INSTALL_DIR) --target=$(TARGET)-elf ;\ make ;\ make install ;\ cd ../

# # insight-gdb # $(INSIGHT_VER).tar.bz2 : @echo Downloading $(INSIGHT_VER) wget

formatting link
$(INSIGHT_VER).tar.bz2 build/$(INSIGHT_VER) : $(INSIGHT_VER).tar.bz2 build @echo Uncompressing insight-gdb @tar xvfj $(INSIGHT_VER).tar.bz2 > /dev/null mv $(INSIGHT_VER) build/$(INSIGHT_VER)

$(INSTALL_DIR)/bin/$(TARGET)-elf-insight : build/$(INSIGHT_VER) $(INSTALL_DIR)/bin/$(TARGET)-elf-gcc cd build/$(INSIGHT_VER)/ ;\ ./configure --prefix=$(INSTALL_DIR) --target=$(TARGET)-elf ;\ make ;\ make install ;\ cd ../

# clean

real_clean : cd build ; \rm -r * # # scripts # $(INSTALL_DIR)/bin/mips-assembler: cp scripts/* $(INSTALL_DIR)/bin/

# archive zip : cd .. ; zip -r mips-devkit.zip mips-devkit

Wojciech Zabolotny a écrit :

Reply to
Steven Derrien

IMO comp.arch.embedded was the correct place.

Building the GNU tools for cross compilation is pretty standard. Steven's reply is good. I have a similar script as part of YAR, building newlib also:

formatting link

Regards, Tommy

Reply to
Tommy Thorn

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.