I'd like to start working on the DC in linux

[JS Lemming]

But I really don't know where to start to get things set up. I could've sworn I searched this forum before and saw info on how to do it... but I can't find it now for some reason. Perhaps my memory is failing me. I did a google search and found this, but that one "http://gamedev.allusion.net/softprj/kos/dcsetup.php" link doesn't work anymore. Any suggestions or links to tutorials would be nice.

EDIT: I found this, but it looks a bit old. Do you recomend I follow those instructions?

EDIT again: Crap, sorry. I meant to search the programming section but I searched the linux section. I see the posts about how to set it up now.

[emptythought]

http://www.dcemulation.org/phpBB/viewtopic.php?t=65237

[BlackAura]

Most of the available guides are a bit old. actually.

The most recent one I know of is this script. There's a newer version of the dc-chain makefile there using GCC 3.4.6, which you should use in place of the one I mentioned in the post fackue linked to.

Basically, you need to download GCC 3.4.6 (core and g++) instead of GCC 3.4.6. Ignore all the stuff I said about modifying the patches - just leave the patches directory as it is.

I don't think there are any SVN snapshots anymore. You'll probably have to check the lastest version of KOS out of the SVN repository yourself. Install Subversion, and do this:

Code: Select all

svn co https://svn.sourceforge.net/svnroot/cadcdev kos
svn co https://svn.sourceforge.net/svnroot/cadcdev kos-ports

At least, I think that should work. I'm not on my mail Linux box right now, so I can't check easily.

Finally, you can build a working ARM compiler with this toolchain using this command:

Code: Select all

make build-arm

[henzenmann]

We just been through this on the KOS mailing list, but of course the list archives @ sourceforge suck, so I'll just repeat what I posted:

Code: Select all

 Two updated build scripts have recently been posted. They can be found at
 http://stalin.thegypsy.com/
 
 I submitted an updated version of Jim Ursetto's script:
 http://stalin.thegypsy.com/dc-chain-0.1-gcc346.tar
 
 
 Here are some quick instructions:
 
 - Checkout kos and kos-ports from the SVN repository
 - Download and unpack dc-chain-0.1-gcc346.tar
 - Download & unpack (in the dc-chain directory) tarballs for binutils, gcc, newlib (see
download.sh)
 - Edit Makefile and set "kos_root"
 - run make 
 
 - Setup KOS and point it to your compilers (environ.sh)
 - run make in kos
 - run make in kos-ports
 
 You may need to compile the toolchain with gcc <= 3.x, as >= 4.x might be too strict.

For more info check out http://sourceforge.net/mailarchive/foru ... um_id=2046

[JS Lemming]

Alright, I have binutils-2.15, gcc-3.4.6, and newlib-1.12.0 in the dc-chain-0.1-gcc346 dirrectory. I have kos and kos-ports downloaded into my home dirrectory. I told the make file where kos lives. Now, I typed "make patch" into the terminal and it said "bash: make: command not found" What's up with that?

EDIT:

- Download & unpack (in the dc-chain directory) tarballs for binutils, gcc, newlib (see
download.sh)

What the heck does "tarballs" mean?

[Roofus]

What the heck does "tarballs" mean?

A "tarball" is a form of archiving under Linux/Unix. It stores a bunch of files in one big file without compression. You can run the .tar file through a compressor like GZip and end up with one of those famous .tar.gz files.

[henzenmann]

Alright, I have binutils-2.15, gcc-3.4.6, and newlib-1.12.0 in the dc-chain-0.1-gcc346 dirrectory. I have kos and kos-ports downloaded into my home dirrectory. I told the make file where kos lives.

Good. Just to check that should be:

Code: Select all

kos_root="/home/your_user_name"

I would suggest however, that you make a directory "/home/your_user_name/dc" and move everything into there, otherwise your $HOME will get rather cluttered over time

Now, I typed "make patch" into the terminal and it said "bash: make: command not found" What's up with that?

You need to install "make". You probably also need to install "gcc-3.4", "patch" and maybe also "autoconf" and "automake" and others (You'll find out when compilation of the toolchain fails ). I think Ubuntu comes with synaptic, which should make this rather straightforward.
You should not need to call the individual Makefile targets (like "make patch"). Just call "make" without arguments and it should do everything automatically.
Another thing: As it is, the Makefile will install the compilers under /usr/local/dc. For that to work, you either need to run "make" as root, or create the directory "/usr/local/dc" as root and then allow your user to write to it:

Code: Select all

mkdir /usr/local/dc
chown your_user_name:your_user_name /usr/local/dc

Or you could change the installation path to "/home/your_user_name/dc" by editing the Makeflile like this:

Code: Select all

sh_prefix  := /home/your_user_name/dc/$(sh_target)
arm_prefix := /home/your_user_name/dc/$(arm_target)

Another note: You may have to compile the toolchain with a pre 4.x version of GCC, although I'm not completely sure if that still applies for a toolchain with gcc-3.4.6.
If the compilation fails at some point with an actual error in the code (ie *not* "i can't find this and that") then that might be the reason. After you installed the "gcc-3.4" package, check to see if it has become your default compiler. Run "gcc --version". If it reports 3.x.x you are good to go. If it reports 4.x.x, you need to call "make CC=gcc-3.4" instead of plain "make" when compiling the toolchain.

Final note: If the compilation process fails, you usually have to start all over again! The Makefile is not smart enough to remember what steps it has already done...you can do it yourself by calling the individual targets in the Makefile yourself, but it is easier to start over once the problem is fixed. See the "unpack.sh" script, which deletes all sources and re-unpacks them given that the tarballs are in the same directory. You can run it like this "sh unpack.sh".

[henzenmann]

BTW, If someone could host it, I would be willing to upload a binary package so people don't need to build the toolchain themselves. It is 44MB big though.

[JS Lemming]

When I ran make, it kept saying it couldn't find some patches and would ask me where they were or something... I just hit enter and said skip the patch. What should I have done there? Do I need to run "unpack.sh" and fix something before I try again? Or is it all good? BTW, after it asked that a few times, the process ended. That took like 20 seconds... Was it supposed to take a longer time?

Also, I tried the "make build-arm" thing and got an error... but I just realized I was supposed to do that last I think... Crap... I probably screwed everything up with that patches thing. What was I supposed to do? Type the dirrectory of the patches? I thought the script would know where they were. *confused*

Code: Select all

travis@travis-desktop:~/Desktop/dc-chain-0.1-gcc346$ make build-arm
+++ Building binutils-2.15 to build-binutils-arm-elf-2.15...
mkdir -p build-binutils-arm-elf-2.15
> /home/travis/Desktop/dc-chain-0.1-gcc346/logs/build-binutils-arm-elf-2.15.log
cd build-binutils-arm-elf-2.15; ../binutils-2.15/configure --target=arm-elf --prefix=/home/travis/dc/arm-elf >> /home/travis/Desktop/dc-chain-0.1-gcc346/logs/build-binutils-arm-elf-2.15.log 2>&1
make -C build-binutils-arm-elf-2.15 all install >> /home/travis/Desktop/dc-chain-0.1-gcc346/logs/build-binutils-arm-elf-2.15.log 2>&1
make: *** [build-arm-binutils] Error 2

BTW, the patching thing would say something like this...

Code: Select all

cd gcc-3.4.6; patch -p1 < /home/travis/Desktop/dc-chain-0.1-gcc346/patches/gcc-3.4.6.diff
The next patch would create the file gcc/config/sh/kos.h,
which already exists!  Assume -R? [n] y
patching file gcc/config/sh/kos.h
can't find file to patch at input line 28
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff -ruN gcc-3.4.6/gcc/config/sh/t-sh gcc-3.4.6-kos/gcc/config/sh/t-sh
|--- gcc-3.4.6/gcc/config/sh/t-sh       2003-06-03 21:01:22.000000000 +0200
|+++ gcc-3.4.6-kos/gcc/config/sh/t-sh   2006-05-29 12:07:52.000000000 +0200
--------------------------
File to patch:

Final BTW...

BTW, If someone could host it, I would be willing to upload a binary package so people don't need to build the toolchain themselves. It is 44MB big though.

I may be able to host it. But how would that work? Is it like, uncompress the binary and then you have a working DC Dev thing? Including all that kos and binutils and gcc and what not?

Sorry for my ignorance. I'm really no good at this sort of stuff.


EDIT:
I tried "make build-sh4" just to see what would happen (cause I saw it in the other topic... and it gave an error too)

Code: Select all

travis@travis-desktop:~/Desktop/dc-chain-0.1-gcc346$ make build-sh4
+++ Building binutils-2.15 to build-binutils-sh-elf-2.15...
mkdir -p build-binutils-sh-elf-2.15
> /home/travis/Desktop/dc-chain-0.1-gcc346/logs/build-binutils-sh-elf-2.15.log
cd build-binutils-sh-elf-2.15; ../binutils-2.15/configure --target=sh-elf --prefix=/home/travis/dc/sh-elf >> /home/travis/Desktop/dc-chain-0.1-gcc346/logs/build-binutils-sh-elf-2.15.log 2>&1
make -C build-binutils-sh-elf-2.15 all install >> /home/travis/Desktop/dc-chain-0.1-gcc346/logs/build-binutils-sh-elf-2.15.log 2>&1
make: *** [build-sh4-binutils] Error 2

[henzenmann]

When I ran make, it kept saying it couldn't find some patches and would ask me where they were or something... I just hit enter and said skip the patch. What should I have done there? Do I need to run "unpack.sh" and fix something before I try again? Or is it all good? BTW, after it asked that a few times, the process ended. That took like 20 seconds... Was it supposed to take a longer time?

On my machine the whole building process takes about an hour.

Also, I tried the "make build-arm" thing and got an error... but I just realized I was supposed to do that last I think... Crap... I probably screwed everything up with that patches thing. What was I supposed to do? Type the dirrectory of the patches? I thought the script would know where they were. *confused*

Code: Select all

travis@travis-desktop:~/Desktop/dc-chain-0.1-gcc346$ make build-arm
+++ Building binutils-2.15 to build-binutils-arm-elf-2.15...
mkdir -p build-binutils-arm-elf-2.15
> /home/travis/Desktop/dc-chain-0.1-gcc346/logs/build-binutils-arm-elf-2.15.log
cd build-binutils-arm-elf-2.15; ../binutils-2.15/configure --target=arm-elf --prefix=/home/travis/dc/arm-elf >> /home/travis/Desktop/dc-chain-0.1-gcc346/logs/build-binutils-arm-elf-2.15.log 2>&1
make -C build-binutils-arm-elf-2.15 all install >> /home/travis/Desktop/dc-chain-0.1-gcc346/logs/build-binutils-arm-elf-2.15.log 2>&1
make: *** [build-arm-binutils] Error 2

If the build process fails, look at the logs to see what exactly went wrong. And again, you should not call the individual targets yourself, just plain "make". Otherwise you have to keep track of what steps where already executed and what target you need to call next.

BTW, the patching thing would say something like this...

Code: Select all

cd gcc-3.4.6; patch -p1 < /home/travis/Desktop/dc-chain-0.1-gcc346/patches/gcc-3.4.6.diff
The next patch would create the file gcc/config/sh/kos.h,
which already exists!  Assume -R? [n] y
patching file gcc/config/sh/kos.h
can't find file to patch at input line 28
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff -ruN gcc-3.4.6/gcc/config/sh/t-sh gcc-3.4.6-kos/gcc/config/sh/t-sh
|--- gcc-3.4.6/gcc/config/sh/t-sh       2003-06-03 21:01:22.000000000 +0200
|+++ gcc-3.4.6-kos/gcc/config/sh/t-sh   2006-05-29 12:07:52.000000000 +0200
--------------------------
File to patch:

This would suggest that patching had already been done. As I said, the Makefile is not smart enough to recognize this, so you need to start over fresh (delete the gcc, binutils and newlib directories and re-unpack the archives you downloaded - this is what the unpack.sh script does).

Final BTW...

BTW, If someone could host it, I would be willing to upload a binary package so people don't need to build the toolchain themselves. It is 44MB big though.

I may be able to host it. But how would that work? Is it like, uncompress the binary and then you have a working DC Dev thing? Including all that kos and binutils and gcc and what not?

This would be just the compilers. You would unpack it and then proceed to setup and compile KOS, which is the easy part.

[JS Lemming]

This would be just the compilers. You would unpack it and then proceed to setup and compile KOS, which is the easy part.

Wait... would that happen to be the exact same thing as this that BA put up? Is there some crazy catch to just using that?

I don't know - it should work. I was able to compile it on my system. Y'know what... the hell with it. I'll just upload mine.

Here it is

That was compiled to run in /usr/local/dc, but it should work anywhere. Unpack it somewhere, and pretend that you compiled it yourself.

EDIT: Nevermind, can't be. Too small.

[JS Lemming]

Alright. I started fresh. I ran make and got this:

Code: Select all

travis@travis-desktop:~/Desktop/dc-chain-0.1-gcc346$ make
cd gcc-3.4.6; patch -p1 < /home/travis/Desktop/dc-chain-0.1-gcc346/patches/gcc-3.4.6.diff
patching file gcc/config/sh/kos.h
can't find file to patch at input line 28
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff -ruN gcc-3.4.6/gcc/config/sh/t-sh gcc-3.4.6-kos/gcc/config/sh/t-sh
|--- gcc-3.4.6/gcc/config/sh/t-sh       2003-06-03 21:01:22.000000000 +0200
|+++ gcc-3.4.6-kos/gcc/config/sh/t-sh   2006-05-29 12:07:52.000000000 +0200
--------------------------
File to patch:

What do I do there?

In the other topic, BA said:

That's weird. It didn't do that on my system.

Try patching it manually. Go into the gcc-3.4.3 directory, and do this:

Code: Select all

cat ../patches/gcc* > patch -p 1

That should do the trick, I hope. Then you need to do the same thing with the newlib patch.

But I fear that will screw up Henz's "just use make" thing because it would try to repatch them wouldn't it?

Gaahhhh.... this going back and forth from the two topics is confusing... some say this, some say that......

[BlackAura]

Ignore that compiler I posted in the other topic - that was just the ARM compiler, and a pretty old version of it at that.

If the patches have already been applied, you can stop the Makefile from reapplying them by using "make build" instead of just "make".

[emptythought]

BTW, If someone could host it, I would be willing to upload a binary package so people don't need to build the toolchain themselves. It is 44MB big though.

We can host it at Consolevision. We're actually looking for someone willing to write a Linux howto on setting up a Dreamcast environment. Either way, we'd be happy to host anything that is useful.

[henzenmann]

Alright. I started fresh. I ran make and got this:

Code: Select all

travis@travis-desktop:~/Desktop/dc-chain-0.1-gcc346$ make
cd gcc-3.4.6; patch -p1 < /home/travis/Desktop/dc-chain-0.1-gcc346/patches/gcc-3.4.6.diff
patching file gcc/config/sh/kos.h
can't find file to patch at input line 28
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff -ruN gcc-3.4.6/gcc/config/sh/t-sh gcc-3.4.6-kos/gcc/config/sh/t-sh
|--- gcc-3.4.6/gcc/config/sh/t-sh       2003-06-03 21:01:22.000000000 +0200
|+++ gcc-3.4.6-kos/gcc/config/sh/t-sh   2006-05-29 12:07:52.000000000 +0200
--------------------------
File to patch:

What do I do there?

I just tried it myself again and it worked without problems:

Code: Select all

$ make CC=gcc-3.4
cd gcc-3.4.6; patch -p1 < /tmp/dc/dc-chain-0.1-gcc346/patches/gcc-3.4.6.diff
patching file gcc/config/sh/kos.h
patching file gcc/config/sh/t-sh
patching file gcc/config.gcc
patching file libstdc++-v3/config/cpu/generic/atomicity.h
patching file libstdc++-v3/config/cpu/sh4/atomicity.h
patching file libstdc++-v3/config/cpu/sh4/atomic_word.h
patching file libstdc++-v3/configure
patching file libstdc++-v3/crossconfig.m4
cd newlib-1.12.0; patch -p1 < /tmp/dc/dc-chain-0.1-gcc346/patches/newlib-1.12.0-kos.diff
patching file config-ml.in
patching file newlib/configure.host
patching file newlib/libc/sys/sh/ftruncate.c
patching file newlib/libc/sys/sh/sys/_types.h
patching file newlib/libc/sys/sh/sys/lock.h
patching file newlib/libc/sys/sh/syscalls.c
patching file newlib/libc/sys/sh/trap.S
patching file newlib/libc/sys/sh/truncate.c
[...]

I think you don't have the GCC sources upacked correctly. The directory should look like this:

Code: Select all

chenz@homer:/tmp/dc/dc-chain-0.1-gcc346/gcc-3.4.6$ ls
ABOUT-NLS  config        config.sub    COPYING.LIB  include       libf2c     libstdc++-v3  ltconfig            Makefile.in   mkinstalldirs   symlink-tree
boehm-gc   config.guess  configure     FAQ          INSTALL       libffi     libtool.m4    ltmain.sh           Makefile.tpl  move-if-change  ylwrap
BUGS       config.if     configure.in  faq.html     install-sh    libiberty  ltcf-c.sh     MAINTAINERS         MD5SUMS       NEWS            zlib
bugs.html  config-ml.in  contrib       fastjar      intl          libjava    ltcf-cxx.sh   maintainer-scripts  missing       README
ChangeLog  config.rpath  COPYING       gcc          LAST_UPDATED  libobjc    ltcf-gcj.sh   Makefile.def        mkdep         README.SCO

What files did you download exactly, and how did you unpack them? You could try to start over and use the scripts instead (run "sh download.sh && sh unpack.sh").

In the other topic, BA said:

That's weird. It didn't do that on my system.

Try patching it manually. Go into the gcc-3.4.3 directory, and do this:

Code: Select all

cat ../patches/gcc* > patch -p 1

That should do the trick, I hope. Then you need to do the same thing with the newlib patch.

But I fear that will screw up Henz's "just use make" thing because it would try to repatch them wouldn't it?

Gaahhhh.... this going back and forth from the two topics is confusing... some say this, some say that......

If the patching does not work from the Makefile, then the command BlackAura posted should not work either. But if for some weird reason it does (don't forget about patching newlib as well), you could then just continue by calling "make build CC=gcc-3.4", which will skip the patching but do all the rest (compile and install the toolchain).

[henzenmann]

BTW, If someone could host it, I would be willing to upload a binary package so people don't need to build the toolchain themselves. It is 44MB big though.

We can host it at Consolevision. We're actually looking for someone willing to write a Linux howto on setting up a Dreamcast environment. Either way, we'd be happy to host anything that is useful.

Cool! Let me know how to get it to you then. And guess what, I just wrote a tutorial too

[henzenmann]

Ignore that compiler I posted in the other topic - that was just the ARM compiler, and a pretty old version of it at that.

If the patches have already been applied, you can stop the Makefile from reapplying them by using "make build" instead of just "make".

Actually I used your binaries before I reinstalled my system. The thing was though that they had to be unpacked to /home/blackaura in order to work

And @JS Lemming: Yes it would work just like BlackAura's binaries (he had posted them for sh-elf as well), only with newer versions of the compilers and a more sensible install location. The only catch might be binary incompatibilities, which should not really be an issue on a PC with any recent GNU/Linux distribution.

[BlackAura]

Actually I used your binaries before I reinstalled my system. The thing was though that they had to be unpacked to /home/blackaura in order to work

Ahem... Yes, that sounds about right.

The only catch might be binary incompatibilities, which should not really be an issue on a PC with any recent GNU/Linux distribution.

The previous toolchain I posted was compiled on Ubuntu 5.10 (or maybe Ubuntu 5.04, I can't remember exactly), but I ran it through apgcc (from the AutoPackage guys) which links the program in such a way that it'll work on Linux distributions with an earlier version of glibc. In theory at least, it should have worked on everything back to RedHat 7, or whenever they started using glibc instead of libc5.

Basically, you need to install apgcc and then do something like this:

Code: Select all

export APBUILD_CC=gcc-3.4
make CC=apgcc

You can also shrink the size of the compilers by deleting all of the info and man pages, (maybe) the locale data, and stripping all of the native binaries (in bin/, arch-elf/bin, and libexec). I managed to get the current toolchain down to 20MB (compressed in a .tar.bz2) by doing that.

It's possible to strip it down more, but it has an annoying tendency to break things if you don't get it exactly right, so it's not worth the couple of hundred kilobytes it'll save.

[henzenmann]

Thanks to fackue/consolevision the pre-built toolchain is now available at http://www.consolevision.com/downloads/ ... 86.tar.bz2
It was built using BlackAura's suggestions.

The tutorial I wrote is available at http://www.consolevision.com/?Dreamcast ... nder_Linux
Some proof-reading would be welcome

[BlackAura]

Excellent. Now we just need pre-compiled versions of some other useful tools.

I just managed to build the latest versions of dcload-ip and dcload-serial, which involved quite a lot of fiddling around to get it using the right copies of libbfd / libiberty, and to make it compile with apgcc, but without dependencies on the native libbfd, or libgcc.

I just need to test them (as much as I can, at least - I have no serial cable anymore to test dcload-serial), and upload them somewhere.

Also useful would be some of Marcus Comstedt's tools, such as scramble and makeip (needs some modification so it can find it's datafiles once installed). I might also try getting GDB working, so we can do some debugging.

Edit: Well, that doesn't work... The DC-side part of dcload-ip works fine, but the PC side doesn't. It seems to be misreading the ELF files - it's uploading 0 bytes starting at 0xffffffff (in other words, doing nothing), and then trying to start executing code at 0xffffffff. Obviously that won't work.

Seems to work OK with .bin files, so that probably means the ELF parser is cocked up. Maybe a dodgy libbfd?

Edit 2: I got it to work now - it was using the headers from the native system version of libbfd, but the library for the SH-4 targetted version. It also required a fair bit of modification, partly because binutils no longer installs libbfd, and partly because libbfd changed a bit. Becuase libbfd isn't installed, you need files in the binutils build directory, so you can only build this if you build your own toolchain.

Download both dcload-ip and dcload-serial like this:

Code: Select all

svn co https://svn.sourceforge.net/svnroot/cadcdev/dcload

First, modify Makefile.cfg. Point the sh-elf compiler paths (TARGETCC et al) at your sh-elf toolchain (3.4.6).

Add "-R .stack" to TARGETOBJCOPY if it's not already there.

Change "-m4" in TARGETCFLAGS to "-m4-single-only"

If using apgcc, change "CC=gcc" to "CC=apgcc". Make sure you're using GCC 3.4 instead of GCC 4.x, because GCC 4 can't compile dcload-serial. Seems to work on dcload-ip though.

Add "-L/path/to/dc-chain-0.1-gcc346/build-binutils-sh-elf-2.15/bfd" to the BFDLIB line. The bfd library is actually in this directory. If you're going to use apgcc, you might want to add "-static-libgcc" too, to eliminate the dependency on libgcc.

Add "-I/path/to/dc-chain-0.1-gcc346/build-binutils-sh-elf-2.15/bfd -I/path/to/dc-chain-0.1-gcc346/binutils-2.15/include" to the BFDINCLUDE line. The BFD headers are in these directories.

Save. Type "make". It'll come up with a load of errors about "size" not being a member of a struct. Each time that happens, replace "->size" with "->_raw_size" in host_src/tool/dc_tool.c. They should all be fairly close together.

Type "make" again. You should now have a working copy of dc-tool in host_src/tool, and an unscrambled binary in target-src/1st_read/1st_read.bin (I know what it says - trust me, it's scrambled).

Or, download my precompiled binaries, and see if they work.

dcload-ip-1.0.4-svn.tar.gz
dcload-serial-1.0.4-svn.tar.gz

The IP version has been tested, and seems to work fine. IP address is 10.0.0.1, but I think you can still use ARP with it. The serial version has not, since I no longer have a serial cable to test with.

In theory, this version should support GDB once I can get that running. I have it compiling, but whether it works or not is another story.