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.

Beginners > Xport with DevKitARM: Replacing crt0 and agb-exit

#160859 - biolizard89 - Wed Jul 23, 2008 6:47 pm

I'm using a Charmed Labs Xport with a GBA. The Xport devkit uses DevKitAdvance, but I'd like to upgrade to DevKitARM. The problem is, Charmed Labs hacked DevKitAdvance a bit. The code that patches DevKitAdvance is available at http://gbaxport.cvs.sourceforge.net/gbaxport/xport/src/crt0/ (It replaces crt0 and agb-exit).

So the question is, how would I apply the same changes to DevKitARM? I notice that DevKitARM contains both a crt0.o and a gba_crt0.o. Which one would I replace with the Xport crt0? What should I do with the other? DevKitAdvance has an "interwork" directory, is the DevKitARM equivalent the "be" directory, or should I do something else with the interwork files? Would replacing agb-exit in DevKitARM be identical to doing so in DevKitAdvance? (the code for that is:)
Code:
   $(CC) -c -mthumb agb-exit.c

   arm-agb-elf-ar r $(ROOT)/thumb/libc.a agb-exit.o


Is there anything else I would have to do to replace crt0 and agb-exit? Anything else which I'm probably missing?

Thanks!

#160862 - Dwedit - Wed Jul 23, 2008 7:26 pm

The changes made to crt0 between devkitadvance and their patched version are:

*Changing waitstates to 0x4490
*Initializing the interrupt vector

the waitstates settings applied is 0x4490, meaning:
SRAM 4 cycles
WS0 - 4 cycles, 1 cycle
WS1 - 4 cycles, 1 cycle
WS2 - 4 cycles, 1 cycle
Prefetch on

Between devkitadv and devkitarm, they took out all interrupt code from crt0.s, and moved it into libgba. Also, the new crt0 never touches waitstates. The default values should work fine until new values are set.
If you use libgba, you usually the irq init functions to initialize and enable interrupts.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

#160865 - biolizard89 - Wed Jul 23, 2008 7:50 pm

Well, here's the problem. I'm using the Xport libraries, which do not include the standard libgba. They use their own libraries (which they stupidly named libgba as well). Since I don't want to go about rewriting the Xport libraries, I need the crt0 to work out-of-the-box with the Xport libraries. Thus, I believe it is necessary to use the Xport crt0. I don't care about the crt0 improvements between DevKitAdvance and DevKitARM (I don't even know what improvements there are); I'm mainly interested in updated GCC, etc. If I completely replace the DevKitARM crt0 with the Xport crt0, would that screw stuff up, assuming that I'm using the Xport libraries (which expect the Xport crt0) and not libgba?

The rest of my questions apply as well.

Thanks!

#161240 - wintermute - Thu Jul 31, 2008 6:31 am

Basically, yes, if you attempt to apply their patches to devkitARM you'll screw it up.

Stick with their toolchain it'll save you a lot of serious pain.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#161401 - dovoto - Sat Aug 02, 2008 11:34 pm

I use xport with devkitarm (have for 5 years or so now, never used their crappy toolchain).

I was able to rewrite everything interesting in their library in a couple of hours (file io, console comms, accessing the io on the default fpga configs...etc).

I recommend just keeping the source around for a reference and just porting over the parts you want to play with. If you run into any trouble with any of it let me know and i will dig around for my stuff.

You dont need any xport stuff at all to use the device as a simple flash cart for hands free deving (other than their upload tool).
_________________
www.drunkencoders.com

#161418 - biolizard89 - Sun Aug 03, 2008 4:02 am

dovoto wrote:
I use xport with devkitarm (have for 5 years or so now, never used their crappy toolchain).

I was able to rewrite everything interesting in their library in a couple of hours (file io, console comms, accessing the io on the default fpga configs...etc).

I recommend just keeping the source around for a reference and just porting over the parts you want to play with. If you run into any trouble with any of it let me know and i will dig around for my stuff.

You dont need any xport stuff at all to use the device as a simple flash cart for hands free deving (other than their upload tool).

Well, problem is, I'm using the XBC with a modified version of the IC Firmware example, as opposed to just a few of the xport libgba files. So I would have to port virtually all of xport libgba, libxrc, and icfirmware, if I were to go that route. Which would certainly be possible, but I really don't want to go through all that trouble.

At least two people from the Xport community (Kyle Machulis and Cody Lodrige) say they have gotten the official xport libs to compile and run properly on DevKitARM with virtually no modification to the libs (Kyle said to swap out the crt0, and he said there were a few things that he couldn't remember at the time that also needed to be done). Kyle is no longer affiliated with the Xport stuff, and I don't want to have to bother Cody about it on AIM unless no one here knows how it would be done (he hasn't set it up for years, so he says it would take him some effort to look up how he did it).

I'm curious why using the Xport crt0 with the Xport libgba/libxrc would screw up on DevKitARM but not DevKitAdvance. Is there something different about the toolchains that would cause stuff to not work? My understanding was that DevKitARM was much the same as DevKitAdvance, but with newer versions of the tools, and modified to compile for DS etc. in addition to GBA. If I'm just using the GBA tools, and I use the Xport crt0 with libs that were designed for the xport crt0, I cannot see why that wouldn't work. Obviously I would not get the benefits of the new DevKitARM versions of crt0 and libgba, but I don't want that anyway.

Anyone able to enlighten me? (Sorry if these are n00b questions....)

#161428 - dovoto - Sun Aug 03, 2008 10:24 am

What is the "IC Firmware" ?
_________________
www.drunkencoders.com

#161429 - silent_code - Sun Aug 03, 2008 11:09 am

My guess: Integrated Circuit Firmware. ;^)
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.

#161436 - wintermute - Sun Aug 03, 2008 1:59 pm

biolizard89 wrote:

I'm curious why using the Xport crt0 with the Xport libgba/libxrc would screw up on devkitARM but not devkitAdvance. Is there something different about the toolchains that would cause stuff to not work? My understanding was that devkitARM was much the same as devkitAdvance, but with newer versions of the tools, and modified to compile for DS etc. in addition to GBA. If I'm just using the GBA tools, and I use the Xport crt0 with libs that were designed for the xport crt0, I cannot see why that wouldn't work. Obviously I would not get the benefits of the new devkitARM versions of crt0 and libgba, but I don't want that anyway.

Anyone able to enlighten me? (Sorry if these are n00b questions....)


devkitAdvance was patched in some interesting ways for GBA. devkitARM took a completely different path to try and avoid platform specific code so that it could be used as a generic ARM toolchain.

Something else to consider is that devkitadvance is based on 5 or 6 year old versions of the toolchain components. devkitARM also uses a different ABI to the older toolchain
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog