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.

DS development > FAT library / SaTa's version

#80178 - melw - Wed Apr 19, 2006 3:38 pm

Ok, I feel a bit stupid asking this but after playing around with an hour or so and not finding a solution I decided to ask here. The problem: Official Chishm FAT library doesn't support SCSD/M3SD but RAIN v14 has a modified version of the library with asm implementation for these cards. However, when I try to use the SaTa's version I can't get the functions residing in the .s files to link. Compiling goes all ok, but in the linking phase I get the following error (example of what happens compiling only with M3SD support):

Code:

arm-elf-g++ -g -mthumb-interwork -mno-fpu -specs=ds_arm9.specs main.o io_m3sd_asm.o -Lc:/devkitpro/libnds/lib -lnds9 -o rm9.elf
main.o: In function `M3SD_write1sector(unsigned int, unsigned int)':
c:/devkitpro/libnds/include/gba_nds_fat/io_m3sd.c:189: undefined reference to `SD_crc16(unsigned short*, unsigned short, unsigned short*)'
c:/devkitpro/libnds/include/gba_nds_fat/io_m3sd.c:190: undefined reference to `SD_data_write(unsigned short*, unsigned short*)'


I can get Rain v14 to compile and link without the same problem so I assume there's just something I've forgotten to do in my own project - however having nearly zero experience what comes to using asm files I don't know what would solve the broken references in this case...

#80191 - linus - Wed Apr 19, 2006 8:45 pm

Is it a problem with your make file? Try using one of the make files from the ndslib or palib examples, theyre pretty versatile and include .s files for me (and ive even compiled that version of fat using them).

Good luck.

#80232 - melw - Thu Apr 20, 2006 10:11 am

linus wrote:
Is it a problem with your make file?


Well, I'm not using makefile's at all with this. :) As an answer why is that - the same codebase/engine is used for multiple platforms, not just DS and it was easier to go without one. Otherwise the way I've implemented the FAT support is the same as HyperHacker's solution in this post, i.e. put the FAT lib under libnds/include and then include separately all needed files in the code.

#80233 - Mighty Max - Thu Apr 20, 2006 10:24 am

In this case: Did the build from the .s return any errors then? & does the io_m3sd_asm.o even exist?

(It's compiling-lines are missing in your [code] block)
_________________
GBAMP Multiboot

#80235 - melw - Thu Apr 20, 2006 11:09 am

Mighty Max wrote:
In this case: Did the build from the .s return any errors then? & does the io_m3sd_asm.o even exist?


Yes, the compiling of the .s should be fine, no errors there. Also the io_m3sd_asm.o exists in the build directory after compiling... Here's a bit more what's happening on the command line:

Code:

#asm
arm-elf-gcc -MM -g -Wall -O2 -mcpu=arm9tdmi -mtune=arm9tdmi -fomit-frame-pointer -ffast-math -mthumb-interwork -Ic:/devkitpro/libnds/include -DARM9 -DFPM_ARM -DOPT_ACCURACY -DROMVER=\"\" -o tmp\build\io_m3sd_asm.d c:\devkitpro\libnds\include\gba_nds_fat\io_m3sd_asm.s
arm-elf-gcc  -g -mthumb-interwork -c c:\devkitpro\libnds\include\gba_nds_fat\io_m3sd_asm.s -otmp\build\io_m3sd_asm.o

#arm9 main
arm-elf-g++ -g --no-warnings -Wall -Os -mcpu=arm9tdmi -mtune=arm9tdmi -fomit-frame-pointer -ffast-math -mthumb-interwork -Ic:/devkitpro/libnds/include -DARM9 -c tmp\tmpsrc\main.c -otmp\build\main.o
arm-elf-g++ -g -mthumb-interwork -mno-fpu -specs=ds_arm9.specs tmp\build\main.o tmp\build\io_m3sd_asm.o -Lc:/devkitpro/libnds/lib -lnds9 -otmp\arm9.elf
tmp\build\main.o: In function `M3SD_write1sector(unsigned int, unsigned int)':
c:/devkitpro/libnds/include/gba_nds_fat/io_m3sd.c:189: undefined reference to `SD_crc16(unsigned short*, unsigned short, unsigned short*)'
c:/devkitpro/libnds/include/gba_nds_fat/io_m3sd.c:190: undefined reference to `SD_data_write(unsigned short*, unsigned short*)'
collect2: ld returned 1 exit status
arm-elf-objcopy -O binary tmp\arm9.elf tmp\arm9.bin
arm-elf-objcopy: 'tmp\arm9.elf': No such file


One thing I noticed also is that in the build directory there's no io_m3sd_asm.d - although this seems to be the case also when compiling RAIN.

#80255 - josath - Thu Apr 20, 2006 6:15 pm

The fat lib has many .c files...how come none of them are listed in the link command? I only see main.o and io_m3sd_asm.o for some reason.

For example, my link command looks like:
Code:
arm-elf-g++  -specs=ds_arm9.specs -g -mthumb-interwork -mno-fpu -Wl,-Map,.map  main.o msg.o disc_io.o gba_nds_fat.o io_efa2.o io_fcsr.o io_m3cf.o io_m3sd.o io_mpcf.o io_nmmc.o io_sccf.o io_scsd.o io_m3sd_asm.o io_scsd_asm.o -L/home/davidr/ds/devkitarm//libnds/lib -lnds9 -lpng -lz -o /lvm/shared/ds/ds/Draw3/arm9/Draw3.arm9.elf

Everything from disc_io.o to io_m3sd_asm.o is part of the fat lib.
Are you using one of the makefiles that came with devkitarm/libnds?

#80261 - Mighty Max - Thu Apr 20, 2006 6:34 pm

Erm, now that i see this, you compile them using g++? did you >>extern "C"<< them then? they are normally included from an as c treated and not cpp treated file. .s exports globals via their real and not as cpp expects encoded name.
_________________
GBAMP Multiboot

#80264 - melw - Thu Apr 20, 2006 8:18 pm

Mighty Max wrote:
Erm, now that i see this, you compile them using g++? did you >>extern "C"<< them then? they are normally included from an as c treated and not cpp treated file. .s exports globals via their real and not as cpp expects encoded name.


Ok, that was it! I feel truly stupid now, should've realized that myself as well. :) Don't have a M3SD to test with over here, but at least after declaring the assembler functions as extern "C"'s everything compiles without errors - will check tomorrow if it really works or not.

Thanks, everyone for the help!

#80265 - melw - Thu Apr 20, 2006 8:26 pm

josath wrote:
The fat lib has many .c files...how come none of them are listed in the link command? I only see main.o and io_m3sd_asm.o for some reason.


That's because the library files are included in the code (see link to HyperHacker's post). Only the asm implementation for M3SD and SCSD can't be included the same way.