> -----Original Message----- > From: Baruch Siach [mailto:baruch@xxxxxxxxxx] > Sent: maandag 14 maart 2011 19:04 > To: Vanalme Filip > Cc: barebox@xxxxxxxxxxxxxxxxxxx > Subject: Re: test app > > Hi Vanalme, > > On Mon, Mar 14, 2011 at 03:55:29PM +0100, Vanalme Filip wrote: > > Hi, > > > > Would I have to change a lot if I would like to use standard libraries (e.g. > > stdio for printf and sprint) in my test app ? > > For printf you may use a standalone implementation, and just provide a putc() > routine. See the following implementations: > > http://www.sparetimelabs.com/tinyprintf/index.html > http://www.menie.org/georges/embedded/ > > baruch [Filip] Thanks for the information. I guess this one is because I'm not an experienced programmer.... : If I use a division operator or a modulo division operator in a static function, all compiles well. If I change the static function into a global function, I get following errors : Undefined reference to '__aeabi_idiv' Undefined reference to '__aeabi_idivmod' The function looks basicly like this (just took the 'problem' part) : static void testfunc (int row) { char c[2]; c[0] = row / 10 + '0'; row %= 10; c[1] = row + '0'; } This is how my Makefile looks like : CC = $(CROSS_COMPILE)gcc OBJCOPY = $(CROSS_COMPILE)objcopy OBJDUMP = $(CROSS_COMPILE)objdump AR = $(CROSS_COMPILE)ar AS = $(CROSS_COMPILE)as LD = $(CROSS_COMPILE)ld CFLAGS = -Wall -Os -nostdlib -Wl,-Ttext=0xA0000000 OBJECTS = testapp.o gpio.o uart.o time.o SRCS = $(OBJECTS:.o=.c) all: testapp.bin %.bin : %.elf $(OBJCOPY) -O binary $^ $@ %.elf : $(SRCS) $(CC) $(CFLAGS) $^ -o $@ $(OBJDUMP) -S $@ > dump .PHONY: clean clean: rm -f *bin *elf $(OBJECTS) I never encountered this problem before in other projects and I don't see why this is working in static functions and not in global functions.... Filip > > > > -----Original Message----- > > > From: barebox-bounces@xxxxxxxxxxxxxxxxxxx [mailto:barebox- > > > bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Vanalme Filip > > > Sent: woensdag 9 maart 2011 9:29 > > > To: Baruch Siach > > > Cc: barebox@xxxxxxxxxxxxxxxxxxx > > > Subject: RE: test app > > > > > > > -----Original Message----- > > > > From: Baruch Siach [mailto:baruch@xxxxxxxxxx] > > > > Sent: dinsdag 8 maart 2011 19:09 > > > > To: Vanalme Filip > > > > Cc: barebox@xxxxxxxxxxxxxxxxxxx > > > > Subject: Re: test app > > > > > > > > Hi Vanalme, > > > > > > > > On Tue, Mar 08, 2011 at 04:52:49PM +0100, Vanalme Filip wrote: > > > > > Compiling and linking seems to work well now. When I dump the .elf, I see > > > > > that the start address is 0xA7E00000. That's what I wanted. > > > > > However, when loading the app in ram and executing it, I see that it tries to > > > start > > > > from 0xA0000000 (this is the base address of the RAM section) : > > > > > > > > > > barebox:/test tftp testapp.bin > > > > > TFTP from server 10.0.48.80 ('testapp.bin' -> 'testapp.bin') > > > > > > > > > > barebox:/test cp testapp.bin /dev/ram0 > > > > > barebox:/test go /dev/ram0 > > > > > ## Starting application at 0xA0000000 ... > > > > > ?¶/ÿ'.e¢Óøñ_ > > > > > > > > > > _øýàõÒÿ ïO > > > > > ÿOÿðzþðöàþ A'}®ÿ > > > > > ùý"õÿ?O¿PP¼@Y > > > > > }¸m > > > > > ×´ï@ïðx`G-/ > > > > > > > > > > > > > > > Should I specify an address when executing 'go' or 'cp' ? Isn't it loading the > > > app > > > > always at the beginning of the RAM space, i.e. 0xA0000000 ? > > > > > > > > Is 0xA0000000 the beginning of you external RAM? > > > > > > > > > [Filip] yes. > > > I meanwhile adjusted Makefile and test app source code to start from address > > > 0xA0000000. This seem to work well. My test app is running now. > > > Because it's just a test app, I think it's OK to put it at the beginning of the > external > > > RAM (so at address 0xA0000000). No use in trying to move it to another region > in > > > the external RAM, is it ? > > > > > > > > > > > Note that in my example I used /dev/sram0 (on-chip 128K SRAM), not > /dev/ram0 > > > > (external DDR2 RAM). > > > > > > > > baruch > > > > > > > > > > [Filip] If I'm right (have to verify though), i.MX27 does not have any SRAM on > > > board. So, I guess external RAM will be the only option. Because the test app > > > resides in the external RAM, it won't be possible to test the whole RAM. But I > think > > > we can live with that limitation. > > > > > > Thanks ! > > > > > > Filip > > -- > ~. .~ Tk Open Systems > =}------------------------------------------------ooO--U--Ooo------------{= > - baruch@xxxxxxxxxx - tel: +972.2.679.5364, http://www.tkos.co.il - _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
