Hello there
Finally I got myself a beaglebone. I believe the SD card has been flashed with the Angstrom image already. But I am more interested in learning how to write what they call the 'BSP' (board support package). Its been quite a while (more than 8 years :|) since ive done any serious embedded development so forgive me in case my questions seem to be somewhat too rudimentary. Im trying to scrape the rust off now :)
Now beginning with the questions, here they are (questions are in bold, in italics and underlined like this):
Ive come to think that starterware is one such implementation of the BSP. Am I right about it?
Additionally, is it a must to use Code composer studio for writing it? As far as I know, of the many components of the software, we have the compiler and the debugger. But is it possible to use generic tools like the bare metal codesourcery gcc toolchain for the compilation and gdb for the debugging?
Additionally how different is the starterware from the, what TI refers to as the PSP (platform)?The PSP, has u-boot and the linux kernel as its components, which is suggestive of the fact that the PSP is a much more elaborate operating environment than the starterware.
Can the starterware be instead used to boot another component, like a minimal OS? That makes it somewhat like u-boot but more like its frugal cousin. Am I right about it?
Starterware seems to also include tools which can be used to flash the SD card. So does this tool work just like a flash writer irrespective of the contents that are being written?
Lastly, some drivers would need to be installed in order to connect the bone to the host machine. Ive got a windows x64 machine. So will the driver that is mentioned in the getting started page suffice (bone_drv64 or something like that) or will I need something else as well?
Ive got more questions but lets take it one at a time :)
Keen to hear from folks here
Ajiaz,
I leave some of the intricate details to TI folks. But some inputs here from my experience.
Aijaz BaigIve come to think that starterware is one such implementation of the BSP. Am I right about it?
Yes. It includes bootstrap code, low level device driver library and some utilities - flashers etc.
Aijaz BaigAdditionally, is it a must to use Code composer studio for writing it? As far as I know, of the many components of the software, we have the compiler and the debugger. But is it possible to use generic tools like the bare metal codesourcery gcc toolchain for the compilation and gdb for the debugging?
This is not entirely correct. Suppose you decide to used, SD card boot mode, you could just use code sourcery GCC for building your app, and then boot it to check if it works. You could use UART messages splattered in your code for debugging (linux printk stlye debugging). Optionally, you can use uboot in UART boot mode, load your app/bootloader and run/flash from there. Yes, ofcourse CCS makes life lot easier by providing a debugger. But it is optional.
Aijaz BaigAdditionally how different is the starterware from the, what TI refers to as the PSP (platform)?The PSP, has u-boot and the linux kernel as its components, which is suggestive of the fact that the PSP is a much more elaborate operating environment than the starterware.
The difference is huge. Starterware is just a KISS (Keep It Simply Stupid) sort of a code. It really helps if you have simple applications and still want some level of BSP ready for you. The driver library is very low level, no-MMU enabled (or is it?), very thin framework. So, let your application chose it.
Aijaz BaigCan the starterware be instead used to boot another component, like a minimal OS? That makes it somewhat like u-boot but more like its frugal cousin. Am I right about it?
Oh yes, I dont think it anyway stops from booting a component. For example in SD card mode, name anything as APP and flash it it just boots it up. Just take care of relocation addresses etc.
Thanks and regards,
Madhvapathi Sriram
Madhvapathi SriramThis is not entirely correct. Suppose you decide to used, SD card boot mode, you could just use code sourcery GCC for building your app, and then boot it to check if it works. You could use UART messages splattered in your code for debugging (linux printk stlye debugging). Optionally, you can use uboot in UART boot mode, load your app/bootloader and run/flash from there. Yes, ofcourse CCS makes life lot easier by providing a debugger. But it is optional.
Yes I do plan on using SD card boot since beaglebone has hard coded the SYSBOOT pins in a way that it starts to boot from the SD card as its first choice (or is it?) You have not mentioned how would I go about 'loading' the binary (ELF I suppose?) into the 'right' address or is it that the SD card itself is 'found' at a fixed address so that merely loading it into the SD card means that the initial ROM loader would have done the address remapping and the like?
If not is there a tool to take of the address relocation issues? I believe ill have to write a linker script. Can someone elaborate?
Madhvapathi SriramThe difference is huge. Starterware is just a KISS (Keep It Simply Stupid) sort of a code. It really helps if you have simple applications and still want some level of BSP ready for you. The driver library is very low level, no-MMU enabled (or is it?), very thin framework. So, let your application chose it.
Yep, thanks for clarifying.
Madhvapathi SriramOh yes, I dont think it anyway stops from booting a component. For example in SD card mode, name anything as APP and flash it it just boots it up. Just take care of relocation addresses etc.
Could you be a bit more elaborate here? Or can you point me to a guide or something? I plan on reading the flashing and booting guide for starterware. Is there something else that might be useful reading?
Is there a plan which shows me how to do it with Code Composer studio?
Additionally what drivers would I need to have my beaglebone talk to my host machine (host architecture is amd64 also referred to as x64)?
Does the CCS installation already adds those drivers or will I have to install them seperately?
Keen to hear again and thanks for ur prompt reply