#23758 - Abscissa - Wed Jul 21, 2004 5:06 am
I've been using DevKitAdvance, partly because I was previously under the assumption the DevKitARM used the the ARM manufacturer's compiler instead of GCC. Now I've just found out that DevKitARM *does* use GCC, and it's still in active development and uses v.3.4 of GCC. DevKitAdvance hasn't been updated in quite a while. Am I correct in concluding that DevKitARM has basically replaced DevKitAdvance and that I should switch to DevKitARM?
#23759 - dagamer34 - Wed Jul 21, 2004 5:34 am
I knew this thread would be created soon enough. I'm not sure what else to think though. Has anybody posted the obvious differences between the 2 besides the fact that DevKitAdvance hasn't been updated in a while?
_________________
Little kids and Playstation 2's don't mix. :(
#23764 - tepples - Wed Jul 21, 2004 6:25 am
DevkitARM has newer GCC and newer Binutils, possibly allowing for better optimization.
With devkitARM, you must use -specs=gba.specs or -specs=gba_mb.specs to link, as devkitARM targets more than one ARM CPU based platform. But this also means you don't need int __gba_multiboot.
Some of devkitARM's link script things are probably different. I haven't tested the mechanism to put code in IWRAM yet.
Wintermute could probably give you a better idea.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#23767 - Abscissa - Wed Jul 21, 2004 7:38 am
Hmm, I think I'm doing something totally wrong:
I downloaded the latest version of DevKitARM and tried to use it on one of my existing projects. I changed the paths in the makefile to point to DevKitARM instead of DevKitAdvance, and I added the -specs=gba.specs, but got this compiler error:
gcc: gba.specs: No such file or directory
Then I tried omitting -specs=gba.specs, and now I get this:
gcc: installation problem, cannot exec `cc1': No such file or directory
#23768 - tepples - Wed Jul 21, 2004 7:43 am
You might have made a mistake when setting the path. Try
gcc -v
and seeing if you're really running devkitARM or something else like DevKitAdvance or MinGW or DJGPP.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#23769 - Abscissa - Wed Jul 21, 2004 7:58 am
Oh, I got it working.
I was using "arm-elf/bin/gcc.exe", but then after reading up on some other forum posts, I tried changing that to "bin/arm-elf-gcc.exe" along with using the "bin/arm-elf-*.exe" of ld, as, and objcopy as well. This way it found cc1 okay, but cc1 errored out complaining it couldn't find "libiconv-2.dll". So then I used the standard dll quick-fix of copying the dll to the same folder as the executable (;)). And it all works now.
#23869 - NoMis - Fri Jul 23, 2004 7:49 am
Devkitadv wasn't updated in a while so devkitarm is the better one. But i'm still missing gdb.exe in the devkitarm. Don't know if it's implemented by now but without it i can't debug within eclipse so i will use Devkitadv till gdb.exe is added.
NoMis
#23877 - cosmic4z - Fri Jul 23, 2004 12:13 pm
NoMis:
Can't you just compile with devkitARM and produce a .ELF file with debugging info ... and then use GDB (from devkitadvance) to debug the .ELF file ?
_________________
Qwak - www.qwak.co.uk | Forum - www.qwak.co.uk/forum/
#23883 - nrpil - Fri Jul 23, 2004 2:23 pm
Hello,
I'm alos using the kit from http://www.devkit.tk/
Can i without problems just use the gdb from devkitadv ?
Greetings,
Norbert
#23889 - f(DarkAngel) - Fri Jul 23, 2004 4:07 pm
You can cross-compile the latest version of gdb easily. You can get the sources at http://sources.redhat.com/
Assuming that you have extracted the gdb & insight sources to your home dir with the default names:
~/gdb/insight-<ver>/configure --target=arm-elf --prefix=<dir>
make
(optional)
make install
_________________
death scream...
#23902 - wintermute - Fri Jul 23, 2004 9:59 pm
| f(DarkAngel) wrote: |
You can cross-compile the latest version of gdb easily. You can get the sources at http://sources.redhat.com/
Assuming that you have extracted the gdb & insight sources to your home dir with the default names:
~/gdb/insight-<ver>/configure --target=arm-elf --prefix=<dir>
make
(optional)
make install |
assuming you're running linux, windows isn't quite that simple - there is actually an Insight package for win32 available on devkit.tk
#23904 - f(DarkAngel) - Fri Jul 23, 2004 11:14 pm
| wintermute wrote: |
| assuming you're running linux, windows isn't quite that simple |
It is.
http://www.cygwin.com
http://www.mingw.org
_________________
death scream...
#23913 - wintermute - Sat Jul 24, 2004 3:05 am
go try it - it's not even close to that simple.
The mailing lists are full of people tearing their hair out trying to get cross debuggers built on windows.
Getting Insight 5.2.1 to build for windows ended up with a patch that's close to 900k.
#23916 - wintermute - Sat Jul 24, 2004 3:51 am
| dagamer34 wrote: |
| I knew this thread would be created soon enough. I'm not sure what else to think though. Has anybody posted the obvious differences between the 2 besides the fact that DevKitAdvance hasn't been updated in a while? |
ok here goes
The built in crt0 and linkscripts are accessed using the -specs switch when linking. You *must* use arm-elf-gcc (or arm-elf-g++) to link for this option to work. The use of arm-elf-ld to link should be discouraged, especially when using any standard library functions.
available specs files are currently :=
gba.specs - a normal cartridge based image
gba_mb.specs - an ewram based multiboot image
gba_er.specs - an ereader image
gp32.specs - a standard GP32 application, using Mirko's SDK
gp32_gpsdk.specs - a standard GP32 application using the Gamepark SDK
The built in crt0 files do not contain conditional code or interrupt support code. The GBA library currently available at devkit.tk contains code for single interrupts and will be upgraded at some point to provide nested interrupt support. Documentation is in progress although if anyone would care to help out with that I'd be quite grateful.
the main function should be a standard int main() - the FAQ on devrs.com which states that using this name inserts extra code for C++ support is actually wrong for an arm-elf target (actually elf targets in general from what I can gather). I keep meaning to mail Jeff about that one & keep forgetting to do it.
The provided linkscripts are, for the most part, equivalent to the crtls provided on devrs.com with the exception of the global variables which put the heap in iwram and generate a multiboot image. Use the gba_mb.specs file for multiboot. IWRAM heap seems a little pointless really given that there's only 32k available so I've left that one out. There is an additional section (.sbss) which allows uninitialised data to be placed in ewram without affecting the binary size. Currently that section is not cleared at startup when the image is a multiboot binary - it will be fixed in a future release.
| Code: |
unsigned char buffer[32768] __attribute__(section(".sbss"));
|
Since DevkitARM uses the most recent stable packages available for binutils, gcc and newlib (currently 2.15 3.4.0 (3.4.1 shortly) and 1.12.0) the code generation is somewhat better and binary size appears to be reduced in general.
The 3.4.x series is more standard compliant than earlier versions so you may get errors with code that slipped by the older parser. Of note is the requirement to specify the namespace explicitly when using C++.
arm-elf-as recognises the .incbin directive for including binary files - currently this appears to work only in the working directory and not from the specified include paths as the documentation states.
devkitARM does not provide *nix tools such as make - I recommend using the msys package for this.
#23928 - f(DarkAngel) - Sat Jul 24, 2004 4:18 pm
| wintermute wrote: |
go try it - it's not even close to that simple.
The mailing lists are full of people tearing their hair out trying to get cross debuggers built on windows.
|
Do you think you are the only one who can build gcc? Or are you trying to convince people that it is something very difficult and people should chicken out? If it was startup code and linker script you said to be not "that" easy, i would appreciate it. You are only speculating.
I have done more than trying, i have done it for m68k for Sega Genesis, not only gdb, with binuntils, gcc, g++, newlib and libstdc+++, under both cygwin and linux. It IS that simple.
_________________
death scream...
#23935 - wintermute - Sat Jul 24, 2004 11:43 pm
| f(DarkAngel) wrote: |
Do you think you are the only one who can build gcc? Or are you trying to convince people that it is something very difficult and people should chicken out? If it was startup code and linker script you said to be not "that" easy, i would appreciate it. You are only speculating.
|
No, I've just spent enough time helping people to build gcc and associated tools to know that the average person finds it extremely difficult to do.
building under linux is easy
building a cygwin dependent toolchain is fairly easy with a properly configured environment. It's also extremely easy to get things wrong & end up in a mess.
building a win32 native(i.e. not cygwin dependent) toolchain is something else entirely and can be an extremely frustrating experience.
On a more productive note.
I've recently gained a Sourceforge project for my toolchains, currently I have ARM and powerpc and have had a few requests for a dreamcast version. It might be interesting to add a Genesis compiler to the list if you're interested in adding your skills to the project? How feasible would it be to produce a generic 68k compiler as I've done for ARM?
#23953 - tepples - Sun Jul 25, 2004 7:10 am
| wintermute wrote: |
| I've recently gained a Sourceforge project for my toolchains, currently I have ARM and powerpc and have had a few requests for a dreamcast version. |
Standardized MinGW-based sh-elf-gcc binaries would be convenient, as people wouldn't have to install Cygwin just to develop for the Dreamcast, although the KOS library's build process might have to be ported to use MSYS rather than Cygwin.
| Quote: |
| It might be interesting to add a Genesis compiler to the list if you're interested in adding your skills to the project? How feasible would it be to produce a generic 68k compiler as I've done for ARM? |
GCC supports m68k according to the backends page, but I don't know if that's just 68020 or later or if it works with 68000 as well. There seems to be a ? under whether a free m68k simulator exists; wouldn't DGen count?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#23960 - f(DarkAngel) - Sun Jul 25, 2004 3:22 pm
It's not a must to have a cygwin environment to run a gcc toolchain compiled under cygwin. Cygwin .dlls can be found in their homepage.
GCC supports m68000 (m68k familiy since they have similar instructions), but when you use configuration m68k-*-*, compiler defaults to 68020 and you have to use -m68000 switch. Binutils accepts m68000-*-* target but gcc doesn't. I had to modify the default machine in m68k header under gcc/config.
| wintermute wrote: |
| It might be interesting to add a Genesis compiler to the list if you're interested in adding your skills to the project? How feasible would it be to produce a generic 68k compiler as I've done for ARM? |
OK, no problem.
"Generic"? Maybe, if you supply startup code and linkerscripts for each system.
An ancient version of m68k gcc is available at http://home.hiwaay.net/~eubanks/
_________________
death scream...
#23966 - tepples - Sun Jul 25, 2004 6:12 pm
| f(DarkAngel) wrote: |
| It's not a must to have a cygwin environment to run a gcc toolchain compiled under cygwin. |
Other than that it's hard to find binaries of Cygwin-compiled DC-targeted GCC? This in turn is because it's hard to find an affordable web host with the space to host both the binaries and the source code for Newlib, GCC, and Binutils.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#23984 - dovoto - Mon Jul 26, 2004 12:10 am
My tutorials now support (only) devkitArm. I have had no issues other then realizing that the -specs directive was needed and haveing to write my own interupt handler (Wintermute provides one that works quite well in the gbalib on devkit.tk ).
The major advantages in my opinion over devkitadv is the use of minsys as apposed to cygwin, makeing it much faster, and the more recent build of gcc that is employed. The small 8MB package is nice too. I see more and more people switching to this build and it is a trend i would like to see continue.
_________________
www.drunkencoders.com
#23986 - dovoto - Mon Jul 26, 2004 12:22 am
gcc for DC with Kos iintegrated. I have never even used the supplied make files to build kos projects btw so porting to some other makefile system should not be an issue. Both the gcc and the kos versions are outdated but if they are really that hard to find...
http://www.thepernproject.com/Dreamcast/
_________________
www.drunkencoders.com