I have been searching for hours now but with no success.
I want to develop bare metalCapplications for the BBB, I do not need any OS. My computer has both Windows 7 and Ubuntu 12.04
so there is some freedom here.
What I understand is:
I still need some initialization/boot routines;something like U-BOOT
I need a compiler/Assembler/Linker = toolchain, something like GCC [with ARM support]
OPTIONAL: an IDE, something like Eclipse CDT.
For 1), I cannot find the download link for an official U-Boot for BBB.
For 2), I cannot find the download link. This web page claims to be “Eclipse CDT manged build extension for GNU ARM Toolchains like CodeSourcery G++ Lite, Yagarto, etc”
But CodeSourcery is not free. I was expecting free GCC support for ARM.
For 3), no problem, I already downloaded Eclipse CDT.
StarterWare is free, but CCS has various cost tiers (including free) and
also supports a 90-day free evaluation. StarterWare includes "official"
boot loader support for the AM335x and the BeagleBone and the "Getting
Started" guide covers using CCS, IAR, or GCC compilers.
You can use lots of other tool chains as well. Dig for info on the TI
web pages and their processor wiki.
Thanks for your response. So the boot loader in StarterWare will be sufficient…Actually I have installed StarterWare before but did not notice the bootloader, thanks for telling me.
Regarding the IDE and toolchain, I do not want to use codesourcery, I want open-source products.
Is it possible to have some combination of Eclipse and GCC that could be enough for me?
You're running bare metal, and both boards use the AM3359 CPU. The
'Black does use a newer version, but even if it's not directly supported
by StarterWare, you'll be way ahead to start off with an AM339x solution
from StarterWare and extend it to do whatever you want than trying to
start totally from scratch.
Sure...there are lots of open ARM compilers, and lots of tool chains and
IDEs. It just depends on what you like and how much you're willing to
configure an IDE vs. having something that works "out of the box".
That thread also says most of the BeagleBone examples will work for the
Black, you'll just have to modify the DDR setup for DDR3 on the 'Black,
vs. the DDR2 on the 'White. If you can't manage that, you probably
don't want to be running on bare metal...
Another option might be to write your app as a u-boot applet. The idea
being that you modify the u-boot init script to not load Linux, and
then you can either type your app's name at the u-boot prompt or
auto-start it. The nice part about u-boot is that you have it already
and it gets you booted to a serial console. You'll be recompiling
u-boot when you write your code, but that's not too hard or time
consuming.
Having said that, I don't think that u-boot would be a great
environment if you start doing too many complicated things with the
AM3359. It also looks like Starterware supports more AM3359 hardware,
but if you're really using the more complicated peripherals, I think
that you should give Linux another look.
What is your motivation? the BBB is one of the ARM Cortex A systems,
which have virtual memory and all the OS-supporting features, which
you are planning to ignore.
Wouldn't it be better to use one of the ARM Cortex M systems, such as
LPC/NXT or STM/STMicro boards?
The Cortex A series isn't really intended for low interrupt latency,
which is why there are dual 200 MHz fixed-point micro-controllers on the
chip (the PRUs). You can also get pretty good latency numbers running
Linux with the Xenomai patches, and have a *LOT* easier time programming
than if you were on bare metal.
I've got pre-built images running a LinuxCNC under a Xenomai kernel that
see typical latencies in the 20-50 uS range, and worst-case latency of
about 80 uS (did I mention the Cortex A series isn't optimized for
latency?).
PRU latency can be as low as 5 or 10 nS, depending on how you write your
code.
It looks like my earlier post was not “sent to all”. So basically I was saying I do not want OS because it introduce latency, and then @Christopher replied to me.
@Christopher: Here is the numbers:
Without having to access the hardware through an operating system, developers can fine-tune the system to achieve optimal resource management of the CPU, peripherals and memory, and to reduce system latencies by up to 500X compared to running under the Linux® operating system
Well, they're being conservative on their multiplier. As mentioned, I
get worst-case latency around 80 uS with Xenomai on the BBB, and with
"stock" Linux I see worst-case latencies pushing into tens of mS, which
means 80 uS is apx. 1000x better.
You can easily get *ANOTHER* 500x improvement (to sub uS latency) by
using the PRU instead of the ARM core for timing critical functions.
...all without getting rid of Linux and running on bare metal.
So I will ask one more time: What sort of latency numbers do you need
for your application?
Odds are you don't have to run on bare metal to achieve them. If you
do, you may want to consider an alternate platform, like one of the
M-core ARM (slower but has much better IRQ handling) or the new ARM core
+ FPGA System-on-chip parts from Altera and Xilinx.
Thanks, actually I am driven by the need for as much throughput of my intended application/algorithm as possible, but do not have hard limit latencies. The problem with the PRUs is that they are not officially supported, but that is not a big issue, hopefully.
Anyway, I think I steered this thread outside its main purpose, sorry for that.
P.S. I am aware of the ZYNQ module from xilinx, but do not intend to use FPGAs for the moment.
The DDR settings are not for beginners. typically you wouldn’t care as the .gel file does this for you on the white
The goal is to get up and running quickly as such TI supports the white and wont keep winging out gel files for the Linux hobbysist
you would ie running if you had bought a BB white
using the starterware examples are very obvious how to use the devices and what happens from reset on this is a MUST to have any success with a chip this complex
Linux drivers must follow a certain paradigm and may be harder to understand as well as its just to much to absorb AND way to many files to peruse as it does everything we don’t need EVEYTHING frank
Buy a BB white have examples running in no time and have fun become an expert then tackle the DDR settings and learn a marketable skill ie
real time embedded rtos for arm using jtag which saves time and grief
Sorry Linux is not hard realtime OS no chance on gathering real data and processing it in 30 uSec
do you really wanna be a hobbyist wanker posting for help because they changed the kernel again?
Then in your downtime study the DDR settings and the schematics. These people don’t know what barebones is on here and if they do they only use open source tools like fly swatter. they just wont accept few apps need its overhead except the hobbyist
No disrespect to starterware intended. I just couldn't pass up an
opportunity to suggest another way to run bare metal, since
starterware is the default response on this list.
This is probably going to be my last post on this topic, since this
isn't the way I do my development, but it's pretty easy (I think) and
it *almost* comes out of the box on the Beaglebone.
Here's what you do:
1. Download the u-boot sources and build them. RCN has docs on this.
2. There's a hello world example in <u-bootdir>/examples/standalone.
When you build u-boot, it gets compiled too. The binary is
hello_world.bin.
3. Copy hello_world.bin to the FAT partition on the MicroSD card
4. Make sure that you're connected to the bbb via a serial cable
5. Boot the BeagleBone and hit a key to break into u-boot
6. At the u-boot prompt type the following:
U-Boot# load mmc 0 0x80300000 hello_world.bin
reading hello_world.bin
594 bytes read in 5 ms (115.2 KiB/s)
U-Boot# go 0x80300000 a b c d
## Starting application at 0x80300000 ...
Example expects ABI version 6
Actual U-Boot ABI version 6
Hello World
argc = 5
argv[0] = "0x80300000"
argv[1] = "a"
argv[2] = "b"
argv[3] = "c"
argv[4] = "d"
argv[5] = "<NULL>"
Hit any key to exit ...
The thing missing from the u-boot API is the code to handle the
peripherals, but getting the basic Arduino API functions up and
running wouldn't be too hard.
There, done with u-boot post. Starterware is cool too. But now I'm
going back to my Linux happy place.
No disrespect to starterware intended. I just couldn't pass up an