gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Announcements And Comments > devkitARM release 19

#85642 - wintermute - Thu Jun 01, 2006 1:49 pm

We've had a few updates today which have hopefully ironed out the hiccups with the latest release.

The toolchain has now moved to arm-eabi for various reasons, the main one being that -march=armv5te -mtune=arm946e-s works as intended without those nasty linker errors.

binutils is now 2.16.93
gcc is now 4.1.1

while libgba & libnds 20060531 are listed in the news item a latent problem arose with the division overrides which has been fixed with the 20060601 releases.

dsbuild is unfortunately missing from the archive due to a small build error which went unnoticed. An archive can be downloaded from devkitpro.org directly.

While old libraries are not compatible with the new toolchain a tool called change-eabi has been provided which will remark the object files. This should be treated as a last resort and libraries should be recompiled where possible. I've mailed the Apex Audio and Krawall authors about the new toolchain so hopefully you'll be able to get eabi compatible libraries from them soon.


http://www.devkitpro.org

As usual the toolchain and latest libraries will be automatically updated for people using the devkitPro updater.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#85651 - melw - Thu Jun 01, 2006 3:53 pm

I downloaded the R19, but can't get anything compiling... All the examples give exactly the same error:

Code:
collect2: _spawnvp: No such file or directory
make[2]: *** [/c/devkitPro/examples/nds/Graphics/2D/BG_Rotation/BG_Rotation.elf] Error 1


This on a PC running WinXP with SP2.

#85653 - ribrdb2 - Thu Jun 01, 2006 4:03 pm

What do you mean it's moved to arm-eabi? What was it before? Will this cause problems with debuggers again?

#85656 - wintermute - Thu Jun 01, 2006 4:14 pm

melw wrote:
I downloaded the R19, but can't get anything compiling... All the examples give exactly the same error:

Code:
collect2: _spawnvp: No such file or directory
make[2]: *** [/c/devkitPro/examples/nds/Graphics/2D/BG_Rotation/BG_Rotation.elf] Error 1


This on a PC running WinXP with SP2.


Install msys and/or make sure the msys/bin folder is first in your path.

The updater does this automatically.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#85730 - jake2431 - Fri Jun 02, 2006 1:45 am

Hey wintermute. I haven't tried devKitPro for a while now, but since I saw that there was a new release I decided to try the updater again(remember I was having problems last time?). Anyway I used the updater v. 1.2.7 and it said that another updater was available and i pressed ok(or yes) and that seemed to ge fine. After that it asked if I wanted to use the new updater and I hit yes. then it started to download. About 3o seconds into it, however, it came up with a error message from windows(you know the one that says send or don't send). Any ideas?

#85735 - swimgod - Fri Jun 02, 2006 2:24 am

Code:

> "make"
"make" -C arm7
make[1]: Entering directory `/f/dissonance/arm7'
main.c
arm-elf-gcc -MMD -MP -MF /f/dissonance/arm7/build/main.d -g -Wall -O2 -mcpu=arm7tdmi -mtune=arm7tdmi -fomit-frame-pointer -ffast-math -mthumb-interwork -I/f/dissonance/arm7/include -I/f/dissonance/arm7/build -I/c/devkitPro/libnds/include -I/f/dissonance/arm7/build -DARM7 -c /f/dissonance/arm7/source/main.c -o main.o
linking dissonance.arm7.elf
c:/devkitPro/libnds/lib\libnds7.a: could not read symbols: File format not recognized

i get this problem...

the libnds7.a is from the new release,
and it says "c:/devkitPro/libnds/lib\libnds7.a: could not read symbols: File format not recognized"

whats wrong?
_________________

1x WII 2x remotes
2x NDS/L(FMv7-ORG:v4,FMv7-org:DSL)
1x GBAMP
2x 1gb (MicroDrive{typeII}&SanDisk{typeI})
1x SuperPass2
1x Supercard-CF

MoonShell skins

#85772 - PacoChan - Fri Jun 02, 2006 9:18 am

Hi, I have a problem with the new version. When I compile any GBA example or any GBA game I made before, they compile well but they don't work in any version of VisualBoy Advance, they show a white screen. Is this a problem of the release or of the emulator? (DS demos work fine with dualis)

#85784 - wintermute - Fri Jun 02, 2006 10:13 am

swimgod wrote:
[code]

i get this problem...

the libnds7.a is from the new release,
and it says "c:/devkitPro/libnds/lib\libnds7.a: could not read symbols: File format not recognized"

whats wrong?


http://www.devkitpro.org/index.php?action=fullnews&id=105

http://sourceforge.net/project/shownotes.php?group_id=114505&release_id=421527
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#85787 - ProblemBaby - Fri Jun 02, 2006 10:53 am

I get exactly the same error as melw

Code:

collect2: _spawnvp: No such file or directory


wintermute wrote:

Install msys and/or make sure the msys/bin folder is first in your path.

The updater does this automatically.


I installed with the new version with the updater, so any other ideas?

#85789 - wintermute - Fri Jun 02, 2006 10:58 am

ProblemBaby wrote:


I installed with the new version with the updater, so any other ideas?


Check your path. Is the path to the msys bin directory first?

Did you install msys? Is msys make being used for the build?
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#85790 - wintermute - Fri Jun 02, 2006 11:00 am

PacoChan wrote:
Hi, I have a problem with the new version. When I compile any GBA example or any GBA game I made before, they compile well but they don't work in any version of VisualBoy Advance, they show a white screen. Is this a problem of the release or of the emulator? (DS demos work fine with dualis)


http://www.devkitpro.org/index.php?action=fullnews&id=110
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#85794 - ProblemBaby - Fri Jun 02, 2006 11:23 am

Quote:

Check your path. Is the path to the msys bin directory first?

Did you install msys? Is msys make being used for the build?


I don't understand what you mean about the bin directory being first, if you mean in the environment variable list, it is.

msys is installed and its used for the build.

#85799 - wintermute - Fri Jun 02, 2006 12:33 pm

I mean this

Code:

C:\>echo %PATH%
e:\msys\bin;e:\tools\bin;e:\mingw\bin;C:\WINNT\system32;C:\WINNT;C:\WINNT\System
32\Wbem;E:\WATCOM\BINNT;E:\WATCOM\BINW;E:\devstudio\common\Tools\WinNT;E:\devstu
dio\common\MSDev98\Bin;E:\devstudio\common\Tools;E:\devstudio\VC98\bin


note that the first entry is e:\msys\bin; This is my development msys rather than the msys supplied by devkitPro. I've tried the latter on my setup and it works fine here.

Does it work from an msys shell?

Do you have any gcc related environment variables set?

The one thing that's guaranteed to fix your problem is to remove the elf2flt script but I'd really like to find a way to ensure this works for everyone.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#85800 - wintermute - Fri Jun 02, 2006 12:35 pm

jake2431 wrote:

About 3o seconds into it, however, it came up with a error message from windows(you know the one that says send or don't send). Any ideas?


Possibly a download problem? Have you tried downloading 1.3.1 manually?
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#85803 - melw - Fri Jun 02, 2006 12:47 pm

wintermute wrote:
Install msys and/or make sure the msys/bin folder is first in your path.

The updater does this automatically.


Thanks, this helped. Everything works now as it should.

#85975 - ProblemBaby - Sat Jun 03, 2006 5:15 pm

Installing msys solved the error. Just one more problem my interrupt code doesn't work anymore. As soon as I enable an interrupt, the program hangs. What kind of changes have been made that could cause this?

#85977 - Cearn - Sat Jun 03, 2006 5:37 pm

This maybe a problem in the linkscripts as well. I've seen __sp_irq, which I guess is used in interrupts, end up in EWRAM instead of IWRAM where it belongs. linkscript patch news.
If not that, maybe looking in the VBA disassembler can at least point you to where the thing hangs.

#85986 - ProblemBaby - Sat Jun 03, 2006 6:29 pm

Oh I forgot to tell you that it is NDS code. Dualis and hardware hangs exactly after everything is enabled: IE, IME and DISPSTAT.

#85991 - wintermute - Sat Jun 03, 2006 6:48 pm

If you can break it down to a small testcase which fails I can have a look.

It's certainly possible that the DS linkscripts still have latent problems - there are some issues with calculated values with the newer binutils ld
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#86017 - ProblemBaby - Sat Jun 03, 2006 9:58 pm

I think it is my Process Interrupt routine. I putted the code in itcm for arm9 and now it works in dualis, still not on hardware.

here is the code:
Code:

   u32 i;
   for (i = 0; i < 32; i++)
   {
      if (REG_IF & BIT(i))
         InterruptFunction[i]();
   }

   INTERRUPT_WAITFLAGS |= REG_IE & REG_IF;
   REG_IF |= REG_IE & REG_IF;

#86067 - DekuTree64 - Sun Jun 04, 2006 4:53 am

Ah yes, there are a couple of linkscript bugs I ran across a while back and mentioned in the chat room, but never got around to writing a proper report on.

First is in ds_arm9.ld, up at the top:
Code:
__dtcm_end      =   0x00804000;

__sp_svc   =   __dtcm_end - 0x100;
__sp_irq   =   __sp_svc - 0x100;
__sp_usr   =   __sp_irq - 0x100;

And then down below
Code:
   .dtcm __dtcm_start : AT (__dtcm_lma)
   {
      __dtcm_start = ABSOLUTE(.);
      *(.dtcm)
      *(.dtcm.*)
      . = ALIGN(4);
   } >dtcm = 0xff
   __dtcm_end = . ;

That redefines __dtcm_end, which caused some weirdness with the stack pointers that are calculated off of it. I changed the one at the top (and that __sp_svc references) to __dheap_end.

And then
Code:
   .sbss __dtcm_end :
   {
      __sbss_start = ABSOLUTE(.);
      __sbss_start__ = ABSOLUTE(.);
      *(.sbss)
      . = ALIGN(4);    /* REQUIRED. LD is flaky without it. */
      __sbss_end = ABSOLUTE(.);
   } >dtcm

That __sbss_end = ABSOLUTE(.); needs to be moved outside the brackets.

I added a line for *(.bss*) just before *(COMMON) in the .bss block. If I remember right, that was causing all my .bss stuff to not actually be initialized to 0.
Also, mine has the ABSOLUTE removed from
Code:
   __bss_end = ABSOLUTE(.) ;
   __bss_end__ = ABSOLUTE(.) ;

But I don't remember any specific problem related to that. Probably doesn't matter.


ARM7 has the same problem as __dtcm_end, but with __iwram_end, and I added the *(.bss*) line for it too.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku

#86094 - wintermute - Sun Jun 04, 2006 12:37 pm

DekuTree64 wrote:
Ah yes, there are a couple of linkscript bugs I ran across a while back and mentioned in the chat room, but never got around to writing a proper report on.


Since this is a thread on release 19 it might be an idea if you checked the current linkscripts before making comments like this.

Quote:

First is in ds_arm9.ld, up at the top:
Code:
__dtcm_end      =   0x00804000;

__sp_svc   =   __dtcm_end - 0x100;
__sp_irq   =   __sp_svc - 0x100;
__sp_usr   =   __sp_irq - 0x100;




Code:

__itcm_start   =   ORIGIN(itcm);
__ewram_end   =   ORIGIN(ewram) + LENGTH(ewram);
__eheap_end   =   ORIGIN(ewram) + LENGTH(ewram);
__dtcm_start   =   ORIGIN(dtcm);
__dtcm_top   =   ORIGIN(dtcm) + LENGTH(dtcm);
__irq_flags   =   __dtcm_top - 0x08;
__irq_vector   =   __dtcm_top - 0x04;

__sp_svc   =   __dtcm_top - 0x100;
__sp_irq   =   __sp_svc - 0x100;
__sp_usr   =   __sp_irq - 0x100;



Quote:

That __sbss_end = ABSOLUTE(.); needs to be moved outside the brackets.


It needs to remain inside the brackets. ld seems to have problems with values outside sections - it might be a binutils bug.

Quote:

I added a line for *(.bss*) just before *(COMMON) in the .bss block. If I remember right, that was causing all my .bss stuff to not actually be initialized to 0.


That was fixed in release 18
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#86097 - wintermute - Sun Jun 04, 2006 12:55 pm

ProblemBaby wrote:
I think it is my Process Interrupt routine. I putted the code in itcm for arm9 and now it works in dualis, still not on hardware.

here is the code:
Code:

   u32 i;
   for (i = 0; i < 32; i++)
   {
      if (REG_IF & BIT(i))
         InterruptFunction[i]();
   }

   INTERRUPT_WAITFLAGS |= REG_IE & REG_IF;
   REG_IF |= REG_IE & REG_IF;



That's not quite right. I'd really recommend using the libnds dispatcher and associated functions.


  • there are only 25 irq flags, checking 32 isn't safe (you might be lucky but I've had problems with this sort of thing in the past).
  • REG_IF bits will be set for all pending interrupts regardless of the REG_IE bits so this code will process handlers for disabled irqs.
  • REG_IF |= <any value> will clear all pending irqs since it reads the register first. You should write REG_IF = <irq bit you've just processed> in the appropriate handler rather than just blindly resetting everything.
  • INTERRUPT_WAITFLAGS isn't defined in libnds, you want VBLANK_INTR_WAIT_FLAGS.


The last point is probably your main problem - the bios irq flags are in dtcm which has been moved. I'm not entirely sure who decided on the old address but it overlapped itcm which was the source of some very weird bugs.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#86106 - ProblemBaby - Sun Jun 04, 2006 2:27 pm

I was the last thing you mentioned, Ive my own defines and the address to the irq_handler was wrong. The strange thing is that
__irq_vector is undefined, but not __irq_flags. I looked thoruh the linkscript and found the correct address.

#86108 - wintermute - Sun Jun 04, 2006 2:52 pm

__irq_vector most definitely is defined. You'd have a hard job finding it in the linkscript if it wasn't.

Use the libnds defines in interrupts.h, do not hard code these values in your project.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#86122 - ProblemBaby - Sun Jun 04, 2006 3:30 pm

I see it in the linkscript but when I use it in my code I get:
Code:

error: '__irq_vector' undeclared (first use in this function)

So Ive to hardcode it

#86124 - wintermute - Sun Jun 04, 2006 3:56 pm

Code:

extern VoidFunctionPointer   __irq_vector[];
extern   vuint32   __irq_flags[];
#define VBLANK_INTR_WAIT_FLAGS  *(__irq_flags)
#define IRQ_HANDLER             *(__irq_vector)


Do not hard code these.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#86128 - ProblemBaby - Sun Jun 04, 2006 4:46 pm

It works, thanks

#86927 - Onions - Sat Jun 10, 2006 5:39 pm

I'm having a similar problem to what someone had earlier.

I get this error message when building...

Code:

> "make"
linking hello_world.elf
collect2: _spawnvp: No such file or directory
make[1]: *** [/c/devkitPro/examples/nds/Graphics/2D/hello_world/hello_world.elf] Error 1
"make": *** [build] Error 2

> Process Exit Code: 2
> Time Taken: 00:00


I tried moving the mysys folder to C:\, but when I did that I got...

Code:

> "make"

> Failed to create process: The system cannot find the file specified.

> Process Exit Code: 0
> Time Taken: 00:00


But, I redirected it's location to point to it at C:\ and I know get my first error again.

So, it looks to me the problem wasn't the location, and it was finding the mysys within Devkitpro's root folder to begin with. I would guess my error is similar to those already experienced and fixed, so maybe I'm overlooking something.
Any help in what that may be is appreciated.

#86929 - wintermute - Sat Jun 10, 2006 5:57 pm

Onions wrote:

So, it looks to me the problem wasn't the location, and it was finding the mysys within Devkitpro's root folder to begin with. I would guess my error is similar to those already experienced and fixed, so maybe I'm overlooking something.
Any help in what that may be is appreciated.


The problem has nothing to do with the location of msys, merely it's location in the PATH environment variable. It may be due to paths with spaces in the sytem PATH before the path to msys/bin or perhaps something found in earlier paths is confusing the script execution mechanism.

Editing the system PATH variable so that the msys bin folder is the first entry has fixed this issue for everyone so far. See this post -> http://forum.gbadev.org/viewtopic.php?p=85799#85799
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#86944 - Onions - Sat Jun 10, 2006 9:45 pm

Oh, I thought you meant the mysys location (or path) should be at the root of your drive (such as C:\mysys) for it to work (which I've been told some other apps needed to be located at - HAM, I think is one). You meant it should be the first listed path in the PATH variable found in Control Panel/System.

I've now gotten it to work and have tried out some of the demos.

Thanks! One last question - is there any way to get an emulator to launch with the newly compiled code while working within, say, Programmer's Notepad?

I'd been working with HAM on the GBA lately, and it speeds things along having VisualBoy Advance connected directly into Visual HAM. So I was hoping for something similar if possible (I'm guessing one could write some sort of command line to accomplish this, although I don't know where to start if so).

#86953 - wintermute - Sat Jun 10, 2006 11:10 pm

Set your file associations so that .gba files load with vba when you double click them then add a run target to the makefile, just after the clean target.

Code:

#---------------------------------------------------------------------------------
run:
   start $(OUTPUT).gba


You can then add a "make run" tool for PN2 using the directions shown here -> http://www.devkitpro.org/pn2.shtml
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#86983 - Onions - Sun Jun 11, 2006 4:49 am

Ok, I've associated my files with the appropriate emu, then added the line you listed exactly (well, I had to use tab instead of whatever was originally used - as it caused an error) in my makefile after the clean command...
Code:

#---------------------------------------------------------------------------------
clean:
   @echo clean ...
   @rm -fr $(BUILD) $(TARGET).elf $(TARGET).nds $(TARGET).arm9 $(TARGET).ds.gba


I think my problem lies in the tool making part. I went by the tutorial you showed, but it's not specifically for "running" a file, so I'm probably messing it up somewheres here.
it seems nothing happens, even when I use the shortcut keys I assigned the tool.

Any help is appreciated.

#87000 - MrD - Sun Jun 11, 2006 10:23 am

wintermute wrote:
Set your file associations so that .gba files load with vba when you double click them then add a run target to the makefile, just after the clean target.

Code:

#---------------------------------------------------------------------------------
run:
   start $(OUTPUT).gba


You can then add a "make run" tool for PN2 using the directions shown here -> http://www.devkitpro.org/pn2.shtml


Just don't forget (like me) that this will make .ds.gba files open with VBA too.
_________________
Not active on this forum. For Lemmings DS help see its website.