Is is possible to use some c-lib, preferably newlib, with the current GCC-toolchain? How?
 
Does it support some kind of "softfloat" (floating point emulation routines)?

Thanks for you reply. Do I have to change the "bare metal" setup and/or toolchain to be able to use application larger than 64kb?

Hello,
 
there's no limit in code size with the bare metal approach -- not from the compiler's side. You can run code directly from SDRAM with the bare metal code - provided, that you have configured the SDRAM controller (EBIU) correctly. However, as Howard implied, it will run slow without cache.
 
If you can waste a few 100k, I'd recommend starting your programs from u-boot. That already does a lot of cache configuration and also allows easy updates and flash programming. No more worries about writing lots of bootstrap code, either.
 
For the float issue: The libm and the GCC internal libs for Blackfin take care of that, if you use floats in your code, the FPU emulation will be silently linked in
This will of course kill some performance, so if you want to do numerically efficient stuff, you might want to look at all the code using fixed point formats (libbfdsp, etc.)
 
A comment about the newlib: In my opinion this beast is quite bloated and not really nice for embedded stuff. Even using a simple printf would eat up all L1 memory in my little test app, so I went for a somewhat selective approach, rewriting part of the functions. See http://www.section5.ch/forum/viewtopic.php?p=133#133 for a link to the shell.tgz code - it demonstrates how to merge "bare metal" with some basic newlib functionality.
 
Since the standalone support is a bit of an orphaned thing in the uClinux community, you'll get no "perfect" board supply package at this moment, but I guess the shell code should get you going. Just make sure you compile in boards/SRV1.
 
Hope that answers some,
 
- Martin

We originally shipped with u-boot installed, configuring it to automatically load srv1.bin.  The main problem is that u-boot and uClinux are configured by default to run at 57k or 115kbaud, and we really need versions that run at 921k or 2500k so that we can easily switch back and forth between u-boot, uClinux and srv1 firmware all running at the same speed. To accommodate this, hardware flow control specific to the SRV-1 has to be mapped into the u-boot and uClinux serial drivers.  Martin knows about this, and hopefully he will add high-speed serial support before too long, since it's his u-boot and uClinux ports that Analog Devices hosts on their blackfin.uclinux.org distributions.