We are using StarterWare 1.00.02.02 on CCSv5.1 Code Sourcery GCC for arm-none-eabi - v2009q1 arm-none-eabi toolchain on Windows for AM1808 Zoom eXp board.
There are 2 issues for which I would require your immediate help. My main aim is to implement TFTP/FTP server on my board for which I would require a file-system and a storage device. With the StarterWare code available I could only think of these 2 combinations.
1. FatFS over Memory Card
In the third_party/fatfs/port folder there is a file fat_mmcsd.c which contains APIs for disk related operations (init, read, write, etc). But it includes couple of header files out of which I am unable to find mmcsd_proto.h and hs_mmcsdlib.h. I came to know, as per the release notes, that MMC support is absent for current StarterWare version of AM1808. So that leaves me only with below option.
2. FatFS over USB Mass Storage
For this I used fat_usbmsc.c found under the third_party/fatfs/port folder along with usb_host_msc.c found under examples/evmAM1808/usb_host_msc folder. Now here with support of given usblib I am able to meet almost all requirements for compilation except for
C:\Program Files\CodeSourcery/arm-none-eabi/lib/\libc.a(lib_a-sbrkr.o): In function `_sbrk_r':
sbrkr.c:(.text+0x18): undefined reference to `_sbrk'
make[1]: *** [bin] Error 1
On googling I came to know that this error is generated due to malloc call and is somehow linked to libc library. Further I also found a probable solution as below
(1) Modify standalone.ld script a little bit
[...]
.bss :
{
_bss = .;
*(.bss*)
*(COMMON)
_ebss = .;
. = ALIGN (8);
_end = .;
} > SRAM
PROVIDE(__HEAP_START = _end );
(2) Create a file syscalls.c and add the following code:
/* based on a example-code from Keil for CS G++ */
/* for caddr_t (typedef char * caddr_t;) */
#include <sys/types.h>
extern int __HEAP_START;
caddr_t _sbrk ( int incr )
static unsigned char *heap = NULL;
unsigned char *prev_heap;
if (heap == NULL) {
heap = (unsigned char *)&__HEAP_START;
}
prev_heap = heap;
/* check removed to show basic approach */
heap += incr;
return (caddr_t) prev_heap;
(3) make sure the file is compiled and the object-code from it gets linked.
Source: http://embdev.net/topic/129753
I want to know if making these changes to linker script and toolchain level is advisable or not. Also as mentioned in the linked post further unforeseen modifications would be required. Have you ever come across such an issue before and if so then how did you resolve it? Was the solution reliable? Also apart from these is there any other way to implement TFTP/FTP server on the board with FatFS over some other mass storage device whose driver is available with you?
Also do you have any plans for implementing MMC support for AM1808 StarterWare upcoming version? If not can you please help us porting MMC support which may be available for AM35xx or similar platforms onto AM1808?
Regards,
jitendra
Hi,
In StarterWare we have not used dynamic allocation (malloc) to avoid complexities in handling memory allocation. Since starterware examples are very simple we always used static allocation.
I assume that you have malloc calls in your application, which is not implemented. So it might try to take from library and end up in linker issue.
I am not sure of additional issue in implementing caddr_t _sbrk ( int incr ), since this function is called by the library. So i would suggest to implement your own malloc function to handle dynamic allocation. But you need to be careful to take of fragmentation issues.
In AM1808 I couldnt think of any other option for your use case. As of now we dont have any plans to implement MMC support for AM1808. However MMC support is available for AM335x and we will be able to help you porting that to AM1808.
The discussion on other thread might give you more idea.
Regards
Baskaran
Thanks for your quick response.
I would like to clarify that I have not used malloc anywhere in my application. Infact I have just integrated tftp code (which is free of malloc or any other dynamic memory allocation) with fatfs and ubs_msc code which in turn uses usblib. On compilation using CodeSourcery tool chain I get following error :-
arm-none-eabi-ld -e Entry -u Entry -u __aeabi_uidiv -u __aeabi_idiv --gc-sections -L"C:\Program Files\CodeSourcery/arm-none-eabi/lib/" -L"C:\Program Files\CodeSourcery/lib/gcc/arm-none-eabi/4.3.3/" -L../../../../../../binary/armv5/gcc/am1808/drivers/Debug -L../../../../../../binary/armv5/gcc/am1808/evmAM1808/platform/Debug -L../../../../../../binary/armv5/gcc/am1808/system_config/Debug -L../../../../../../binary/armv5/gcc/am1808/ipclite/Debug -L../../../../../../binary/armv5/gcc/utils/Debug -L../../../../../../binary/armv5/gcc/am1808/usblib/Debug -L../../../../../../binary/armv5/gcc/grlib/Debug -L../../../../../../binary/armv5/gcc/nandlib/Debug -o Debug/enetLwip.out -Map Debug/enetLwip.map \ Debug/*.o* -T enetLwip.lds -ldrivers -lutils -lplatform -lsystem_config -lusblib -lc -lgcc -ldrivers -lutils -lplatform -lsystem_config -lusblib -lc -lgccC:\Program Files\CodeSourcery/arm-none-eabi/lib/\libc.a(lib_a-sbrkr.o): In function `_sbrk_r':sbrkr.c:(.text+0x18): undefined reference to `_sbrk'make[1]: *** [bin] Error 1make[1]: Leaving directory `/d/TI/StarterWare/build/armv5/gcc/am1808/evmAM1808/enet_lwip'make: *** [debug] Error 2
I don't get above error when other examples are compiled using the same tool chain. I assume that some inbuilt library function is using malloc.
Further we have concluded that we will be anyhow needing MMC implementation in our project. It would be highly appreciated if you could help us port the same.
Rohit
On closer inspection I found out that inside third_party\lwip-1.3.2\src\core\mem.c there is a function
void *mem_malloc(mem_size_t size)
which is being called by many files inside lwiplib. Also I checked out
lwiplib/lwip/mem.h which has
#if MEM_LIBC_MALLOC
#ifndef mem_malloc#define mem_malloc malloc#endif
#endif
but MEM_LIBC_MALLOC is defined as 0 hence this code would not compile.
I will further investigate if my tftp code is somehow calling malloc from LIBC.
Rohit.
can you try the below procedure to see who is calling the Malloc()
1. define malloc function in your code
void * malloc(unsigned int temp)
return (void *) 1000;
2. i hope it will link now. if it links load the image on target and have a break point in mallow function. So when the break point is hit, you will know who is calling malloc.
This will give some idea to proceed further.
regards
On closer look, I found out where the malloc was being called from. It was from sprintf call in my tftp application code. When I commented out sprintf calls the code compiles happily.
Now I will check if my TFTP server works over USB Mass Storage Device.
We will still need your help for porting MMC support onto AM1808.
Thanks and Regards,
We are now back on MMC/SD card interface module of AM1808 using StarterWare v1.00.02.02. Since we failed to get any support for the same we have decided to port AM335x StarterWare v2.00.00.05 code onto StarterWare v1.00.02.02.
The following files are of our interest
StarterWare v1 ------- StarterWare v2
hw_mmcsd.h ------- hw_mmcsd.h ----> Same
soc_AM1808.h ------ soc_AM335x.h ---> Different
evmAM1808.h ------- evmAM335x.h ----> Different
Q1. Do you have any software migration guide for AM335x to AM18xx ?
Q2. Since hw_mmcsd.h are same files in both StarterWare versions, whether same MMC/SD controller is used in both Sitara MCUs ?
Q3. According to user guide for StarterWare v2.00.00.05 pg 94 its mentioned that there is "No support for SDIO" but according to AM335x EVM baseboard Schematic v1.1A pg 11 the SD card connector J13 shows 4 wire SDIO mode with MMC0 peripheral. Please clarify.
Q4. Also apart from above header files we feel that protocol level source files can be used as it is from StarterWare v2.00.00.05. If not please mention which other files are to be edited ?
Looking forward to your quick reply.
Any help please ?
Rohit,
Q1. We dont have any software migration guide for MA335x to Am18xx
Q2. No. The MMC/SD controllers used are different in both SoC's
Q3. will check and get back
Q4. The MMCSD lib can be used as is, but the mmcsd driver (DAL) has to be updated to fit with the lib.
You can refer the Linux mmcsd driver, may be this would give you some pointers.
FYI - I noticed that there is a plain C example as part of the BSL SW for AM1808 EVM from LogicPD:http://www.logicpd.com/products/system-on-modules/omap-l138-som-m1/#documentation
Anthony