Frequently Asked Questions

See why use linux

See the Introduction to uClinux

Debugging uClinux application is the same as debugging Linux application. We can use printk() to print out kernel information; use GDB to debug applications; or use KGDB to debug the kernel or drivers.

Since uClinux is using the Linux kernel, we can say noMMU and MMU have the same kernel stability. In user level, one Linux application can not access another application’s memory space; while in uClinux there is no such kind of protection between user applications, so one “bad” uClinux application may corrupt another one by accessing improper memory. But this is unlikely to happen in normal situation, because normal applications just access their own static and dynamic data memory, which is safely managed by the Linux kernel. The other thing is that unlike MMU Linux, uClinux application stacks are allocated at compile/load time, they do not grow at running time. If an application stack overflows, unexpected errors may happen. To avoid this, Blackfin uClinux supplies the option to detect stack overflow and print out useful information. See debugging_applications

Easy - See porting_applications.

You must use gcc for Linux Applications. See toolchain. If you are not using or developing Linux applications, you should see the stand_alone_applications section. There is also a hello-world application to get started simple_hello_world_application_example.

See Software License.

We always suggest using our latest release. There are 2-3 releases every year, each release includes many new features, new drivers, new kernel or libraries, and bug fixings. Always use the same release of the toolchain, kernel, U-Boot and uClinux distribution.

Yes - features

Some versions of silicon have anomalies that simply cannot be worked around, or the amount of effort to do so is significantly higher than we are currently willing to expend. This doesn't mean Linux/U-Boot/etc… won't work (sometimes they do by accident!), just that they most likely will not work and if things fail, then do not ask questions about it on the forums. See the anomalies and features pages for more information.

Before reporting a bug, please read How to Report Bugs Effectively by Simon Tatham. It is available in over 10 languages, so if English is not your first language, that is fine. If you have a question - “How do I do …” - search on this wiki for the topic, or if there are no topics in the wiki to help (or you can't understand the instructions), please read How to ask a question the smart way by Eric Raymond, and then ask on the forums. There are three major forums for Toolchain, U-Boot, and Kernel. If you want to make a bug reports Toolchain, U-Boot, or Kernel.

When http://blackfin.uclinux.org does a release, it calls the releases by year and release version : 2006R2 (is the second release made in 2006). There will be a 2006R2 version of u-boot, toolchain, and uClinux-dist (which includes the kernel) which must be used together to ensure stability.

Primarily, this is because of release testing that goes on. We test on gcc 3.4, gcc 4.1, gcc 4.3, BF518, BF527, BF533, BF537, BF548, BF561, with Flat, shared-Flat, and ELF file formats - our test matrix is already very large, and takes a long time. Because the team does not do mix and match during testing, it is difficult to foresee any random issues that might pop up, or go back to investigate/debug them when they are discovered.

To understand what these issues come from, examine the system:

U-Boot ↔ Kernel ↔ uClibc/shared objects ↔ application

Some features rely on U-Boot ↔ Kernel interaction - which require specific versions of the bootloader, and the kernel. If you use mixed version bootloader/kernel - these features may not work properly. Normally these features are minor things like getting the kernel booted properly. If the kernel is expecting to have U-Boot set something up, and it does not, the kernel will not boot.

With the 2.4 kernel, there was a 2.4.x stable kernel, and a 2.5.x development tree, where large changes took place. With the Linux 2.6.x tree, this is no longer the case, and sometimes the kernel side of the Kernel ↔ uClibc interface (syscalls), or existing kernel drivers are removed (as serial infrastructure changed, old serial drivers were deprecated, and removed) or ioctls in existing drivers change. This doesn't happen often, but when it does, uClibc and/or the application must be updated.

As stated on the uClibc release notes: “You are probably used to this by now, but this release [uClibc 0.9.28] is NOT binary compatible with uClibc 0.9.27 or any earlier release, so be prepared to recompile your software if you are still using an old version of uClibc.” See mainline 0.9.28 release notes. Since sometimes the uClibc's entry or exit code is updated/fixed, or interfaces inside of uClibc change, it requires to ensure that the version you use on the filesystem is exactly the same as what is used to link (installed in the toolchain). This is only a problem with dynamic linking, or shared objects. When things are statically linked, there is no way for the user space uClibc, and host uClibc to become out of sync.

If you are dynamically linking (with -mfdpic or shared flat), and attempt to use a different version of uClibc in the toolchain, than what runs on the target all kinds of undebuggable random errors may be encountered. From causing bus errors, to crashing on exit. This is because the uClibc code in entry and exit code is modified to fix bugs.

I don't have this problem with ARM

The issue of release management has nothing to do with the processor being used, it has to do with the software. The types of releases that we do here, are exactly the same in most embedded distributions using uClibc.

What happens if I need to upgrade in the field?

What the best plan is, depends on why you feel you need to upgrade. Sometimes it is possible to replace the components of either just the kernel, uClibc, toolchain, or application. For example it may be possible to upgrade only the Linux kernel, without making changes in uClibc, or the applications. It should be expected that some work would be required to “un-upgrade” a few specific pieces of the kernel, which may have been modified to work with the latest uClibc (which you do not want to upgrade).

If the problem is in the c library (uClibc), and it needs updating, you need to replace anything on the target file system that is linked dynamically with uClibc. This would include both the applications and the uClibc libraries themselves.

Because of the complexity of doing upgrades, Normally, most people stick with the same version as they shipped on the initial product, and simply maintain that. Normally for bug fixes, developers of blackfin.uclinux.org port the fix back to the previous release. If you need the fix on a specific release - please indicate that in your bug fix, and we can see if that is possible (sometimes it is not). For feature enhancements, normally this is just done on the svn trunk.

OK - What is the latest release

As stated above, when we do a release, the release names include year (2008), release version(R1), and release candidate (-RC1) : 2008R2-RC8 (is the release candidate eight, of the second release made in 2006). There will be a 2006 version of u-boot, toolchain, and uClinux-dist (which includes the kernel) which must be used together to ensure stability. Normally release candidate versions (-RC0) are not tracked closely - and you should just use the highest version which appears on the download page - what goes into release candidates is only bug fixes of existing features (the mainline version of the toolchains, u-boot, kernel, uClibc, and userspace will stay the same in release candidates). The release version (R0) is incremented when a new features are added to an existing code base. Existing features are not changed or removed when incrementing the release version number (the mainline version of the toolchains, u-boot, kernel, uClibc, userspace will stay the same in the same yearly release). This allows the major releases (ones with the same year) to be based off the same branch in svn/git - this means that the difference between R1, and R2 may be a few more features, but no major upgrades on toolchain version, kernel version, and binary compatibility should be there.

However -- There are always minor fixes which are committed into the svn/git release branches after the final version has been uploaded to the downloads pages. This means that the best thing to do is develop from the release branches, not the tar balls. We typically do not release patchfiles for releases - as you can generate these yourself with the correct svn or git commands.

There are many good resources at the references and pointers section

Many operating conditions can affect power consumption, and there are several kernel interfaces allowing you to reduce overall power consumption. Follow the link here power_management_support

The total system boot time can be as low as 0.4 seconds – Estimates tips and tricks are detailed here: fast_boot_example

The flash memory footprint depends on the size of your roof filesystem and your kernel configuration. Estimates tips and tricks to reduce flash memory footprint are detailed here: fast_boot_example

No. Windows does not provide a POSIX environment (including case sensitive file systems), so building many projects will fail. It might work for you, or it might fail. Either way, it is not supported so do not ask questions about it. If you are tied to Windows and cannot create your own Linux install, then take a look at coLinux.

• If your host is 2.4 Linux kernel, See can_i_build_the_uclinux-dist_on_a_2.4_host.
• If your host is 2.6 Linux kernel, See my_host_is_runing_linux_2.6,_why_I_still_cannot_build_the_uclinux-dist.

When compiling uClinux kernel on Linux 2.4 system, if you encounter compile errors in flash_eraseall.c or ftl_format.c, this is most likely the problem of missing header “linux/mtd/ftl.h” on the host. If you are running into problems, you have a few options:

1. update to latest cvs - this has been fixed.
2. try turning off the mtd-utils (but you will loose JFFS2 capabilities). The mtd-utils creates host tools as well as target tools (to create a file system on the host, which can be read by the target). If can be found in Kernel/Library/Defaults Selection → Customize Vendor/User Settings → Flash Tools → mtd-utils.

Sometimes, on a Linux 2.6 system (e.g, Fedora Core), the mtd-utils header files (linux/mtd/*.h) do not exist in the default “include” path: /usr/include/, so you may get an error like:

$ gcc -I/usr/include -I. -o build/ftl_format ftl_format.c
ftl_format.c:51:27: error: linux/mtd/ftl.h: No such file or directory

In this case, please try to find the headers files for mtd-utils in the host kernel source tree (kernel source will be installed in /usr/src/ by default): <kernel_src>/include/linux/mtd/. If it is not there, you can copy (or link) the target mtd directory from <target_kernel_src>/uClinux-dist/linux-2.6.x/include/mtd/ to usr/include/linux/mtd. (which hopefully is a path that your host's gcc looks at for include files).

Your development system is using a very old version of the “make” package that has bugs and you've just hit one. You need to upgrade the “make” package on your system as this is certainly not a bug in our uClinux distribution. For information on how to upgrade, consult the website for your distribution or visit the Make homepage.

Same issue as the previous FAQ (expand.c:489:…..). See that question for the answer.

The glibc-2.7 release has a bug in its scanf() function which causes genext2fs to crash while parsing its device file. Some newer distributions contain this bug. To see what version of glibc your system is running, simply execute /lib/libc.so.6 (this will be the filename on most people's systems … if it is not on your system, you're using a sufficiently uncommon setup where you should know the alternative file instinctively). The version will be in the first line of output.

Here are some ways you can address the problem:

• make sure you're using the latest glibc package for your distribution
• file a bug with your distribution to get them to fix their glibc-2.7 package (upstream bug report)
• use a different distribution that has the bug fixed
• use an older version of your distribution
• do not build kernels with the MTD_UCLINUX option
• edit the device_table.txt and remove all comments and empty lines
• apply the glibc fix yourself and rebuild your glibc

If you get an error that looks like:

../bfin-elf-genext2fs: couldn't allocate a block (no free space)

This means that the ram files system for the target is not big enough to store all the data that you want to put in it. This is controlled in the ./vendors/AnalogDevices/BF5xx-XXXX/Makefile. For more information learn more about the root_file_system_structure

Normally, the uImage is a combination of kernel and filesystem. Make sure: - you have turned off things in the kernel you don't need - go through the file system and delete things you don't need. To find large applications, try:

uClinux-dist> find -P ./romfs/ -type f -printf "%s %p\n" | sort -nr | less

And just delete the large ones that you do not need.
Since this is easier said than done, you can run this little bit of shell script, which goes through the romfs, looking at which libraries are referenced by everything not in the /lib directory, and then goes through those libraries, and prints their dependencies.

rgetz@imhotep:~/blackfin/trunk/uClinux-dist> for i in $(bfin-elf-readelf -d $(find -P ./romfs -perm -001 -type f | grep -v "./lib/") | grep NEEDED | awk '{print $5}' | sort | uniq | sed -e 's/\[//' -e 's/\]//' ) ; do  echo $i; bfin-elf-readelf -d ./romfs/lib/$i 2>/dev/null | grep NEEDED | awk '{print $5}' | sed -e 's/\[//' -e 's/\]//' ; done | sort | uniq
ld-uClibc.so.0
libcrypt.so.0
libc.so.0
libdl.so.0
libgcc_s.so.1
libid3tag.so.0
libjpeg.so.62
libmad.so.0
libm.so.0
libpng12.so.0
libpthread.so.0
libthread_db.so.1
libutil.so.0
libz.so.1

You should not remove anything in the list that the script generates (unless you are only building as flat, and do not want to do any fdpic developments).

The first thing to do is select/unselect (depending on if you want to install the shared libraries):

   Blackfin build options  --->
     [*] Install ELF shared libraries
     [ ]   Cull unused ELF shared libraries 

This should be done after you have removed the libraries - but -- it will remove all shared libraries (or shared libraries which are not referenced by the current applications in the romfs directory. For example - if you have no threaded applications in the romfs directory, it will remove the pthread library (libpthread.so.0), but this will make it so no threaded applications will ever run on the system (without also replacing the pthread library.

Older releases of the Blackfin toolchain/kernel would generate and use BFLT version 5 executables. Starting with the 2006R1 release, the toolchain/kernel generates and uses BFLT version 4 executables. The reason for this change is that unlike the version 4 format, version 5 is not the standard used by other uClinux ports. If you are encountering this error, make sure you are using the same version of the toolchain and kernel. In other words, do not try and compile the 2006R1 kernel sources with a 2005R4 toolchain and if you are using the kernel from current development sources, then you should probably be using the toolchain from current development sources.

You need to specify extra flags at link time. Either specify -mfdpic (and make sure ELF support is turned on in the kernel) or specify -Wl,-elf2flt and run the flat file. Have a look at: simple_hello_world_application_example Another common error is to transfer files via ftp to the board in ASCII mode. Make sure you transfer only in binary mode.

The 2005R3 release of the toolchain omitted this program. You should upgrade to the latest release where this issue has been rectified. If you are building the toolchain yourself using the BuildToolChain script, you need to specify the u-boot source code using the -u option, otherwise the additional tools (such as mkimage) will be omitted.

With 2008R1 and newer, LFS support is enabled by default. With older versions, you need to: The default toolchain doesn't have Large File Support Enabled by default. If you need this feature following needs to be done: In uClinux-dist/uClibc/extra/Configs/ Edit: Config.bfin.default and Config.bfinfdpic.default Change: # UCLIBC_HAS_LFS is not set to UCLIBC_HAS_LFS=y Then rebuild your toolchain using the path set to your patched Kernel/uClibc. Find more here: toolchain_build_script

When building a rootfs with a broken cpio host application, sometimes the permissions on the directories can be set incorrectly. You have a few choices:

• Fix by hand (chmod 755 <dir>)
• Upgrade your host cpio application to something that isn't broken

This occurs most often when the toolchain has not been fully or properly installed. Please verify you installed all the right toolchain packages (including a C library package). For more information, refer to the Installing the Toolchain page.

The config.sub file is outdated. Simply copy the version from uClinux-dist/tools/config.sub over the local version.

Building GCC 4.3 requires GMP 4.1+ and MPFR 2.3.0+, something that gcc 4.1 and 3.4 did not. This means upgrading your host distribution. To check the version, try something like

rgetz@pinky:~/blackfin-trunk> grep MPFR_VERSION_STRING /usr/include/mpfr.h
#define MPFR_VERSION_STRING "2.2.0

Please see the dev-management page for more information (especially the troubleshooting section).

Please see the power_management_support page for more information

To change the network setting of the Blackfin, you will need to modify the ./uClinux-dist/vendors/AnalogDevices/BFXXX-XXXXX/rc file. This file is the startup script that is run each time the Blackfin boots. To set a static ip address of your choice, add the line

ifconfig eth0 192.168.0.1

Or to instead use DHCP for obtaining an IP address, add the line:

dhcpcd &

Then rebuild the kernel. You can also use this file to automatically mount shared drives and other things that need to be done at boot time. A third option is to pass in a static IP address through U-Boot through the bootargs environment variable

setenv bootargs $(bootargs) ip=$(ipaddr):$(serverip):$(gatewayip):$(netmask):$(hostname):eth0:off

This is equivalent to the addip command in U-Boot For more details, see the setting_up_the_network page.

On newer releases (2008R1+), the default behavior is to generate tty sessions dynamically. This requires additional features and steps that if you disable, you break the ability to login via telnet. That includes the Unix98 PTY support option in the kernel configuration under Character Devices. You must also deselect the option telnetd does not use openpty() in the vendor/user configuration. Then at runtime, you must mount the devpts pseudo filesystem on /dev/pts/. The default Analog Devices boards do all of this for you. On older releases (2007R1 and older), the default behavior was a static list of legacy BSD pty's. The default was to only allow two telnet connections into the Blackfin at a given time. To allow more telnet sessions for the Blackfin, you will need to modify the ./uClinux-dist/vendors/AnalogDevices/BFXXX-XXXXX/device_table.txt file. The last number on the line for /dev/ttyp and /dev/ptyp control the number of telnet sessions available. In this case, up to 8 telnet sessions are allowed.

/dev/ttyp	c	666	0	0	3	0	0	1	8
/dev/ptyp	c	666	0	0	2	0	0	1	8

Booting on a BF533-STAMP, with a recent (R4) image, with a ram rootfs looks something like:

stamp>bootm
## Booting image at 01000000 ...
   Image Name:   uClinux Kernel and Filesystem
   Created:      2006-03-23   5:48:47 UTC
   Image Type:   Blackfin Linux Kernel Image (gzip compressed)
   Data Size:    2829207 Bytes =  2.7 MB
   Load Address: 00001000
   Entry Point:  00001000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
Starting Kernel at = 1000
Linux version 2.6.12.1-BFIN-2005R4 (rgetz@home) (gcc version 3.4.4 (Blackfin 05R
Blackfin support (C) 2004 Analog Devices, Inc.
ADSP-BF533 Rev. 0.3
uClinux/BF533
Blackfin uClinux support by blackfin.uclinux.org
Processor Speed: 398 MHz core clock and 79 Mhz System Clock
Board Memory: 128MB
Memory map:
  text = 0x001000-0x0d9d58
  data = 0x0e6838-0x112fec
  bss  = 0x112ff0-0x1204b4
  rootfs = 0x7700000-0x7f00000
  stack = 0x0e8000-0x0ea000
Command line: 'root=/dev/mtdblock0 rw'
Instruction Cache Enabled
Data Cache Enabled (write-through)
Hardware Trace Enabled
Built 1 zonelists
Kernel command line: root=/dev/mtdblock0 rw
Configuring Blackfin Priority Driven Interrupts
PID hash table entries: 256 (order: 8, 4096 bytes)
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Physical pages: 3c00
Memory available: 59648k/130149k RAM, (49k init code, 867k kernel code, 231k dat
Blackfin Scratchpad data SRAM: 4 KB
Blackfin DATA_A SRAM: 16 KB
Blackfin DATA_B SRAM: 16 KB
Security Framework v1.0.0 initialized
Capability LSM initialized
Mount-cache hash table entries: 512
NET: Registered protocol family 16
Blackfin DMA Controller for BF533
stamp_init(): registering device resources
Real Time Clock Driver v1.10e
blackfin_dpmc_init
Dynamic Power Management Controller: major=10, minor = 254
DPMC Driver v0.1
BlackFin BF533 serial driver version 2.00 With DMA Support
io scheduler noop registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
smc91x.c: v1.1, sep 22 2004 by Nicolas Pitre <nico@cam.org>
Blackfin SMC91x interrupt setup: flag PF7, irq 27
eth0: SMC91C11xFD (rev 1) at 20300300 IRQ 27 [nowait]
eth0: Ethernet addr: 00:e0:22:fe:07:91
uclinux[mtd]: RAM probe address=0x7700000 size=0x800000
Creating 1 MTD partitions on "RAM":
0x00000000-0x00800000 : "EXT2fs"
uclinux[mtd0]: set EXT2fs to be root filesystem
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP established hash table entries: 2048 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
NET: Registered protocol family 1
NET: Registered protocol family 17
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 48k freed (0xda000 - 0xe5000)
ttyS0 at irq = 21 is a builtin BlackFin UART
bfin_change_speed: baud = 57600, cval = 0x13

Welcome to:
       ____ _  _
      /  __| ||_|             _  _
 _   _| |  | | _ ____  _   _ \ \/ /
| | | | |  | || |  _ \| | | | \  /
| |_| | |__| || | | | | |_| | /  \
|  ___\____|_||_|_| |_|\____|/_/\_\
|_|

For further information see:
http://www.uclinux.org/
http://blackfin.uclinux.org/



BusyBox v1.00 (2006.02.17-14:21+0000) Built-in shell (msh)
Enter 'help' for a list of built-in commands.

root:~> 

port_program_to_linux. Also This page describes some of the problems and solutions for porting large multi-threaded applications to uClinux.

See managing users.

When I install a module, I get an error:

root:~> modprobe snd-ad73311
soundcore: version magic '2.6.16.11-ADI-2006R1 gcc-4.1' should be '2.6.16.11-ADI-2006R1 gcc-3.4'
insmod: cannot insert `/lib/modules//2.6.16.11-ADI-2006R1/kernel/sound/soundcore.ko': Invalid module format (-1): Exec format error

This error means you build the modules with a different version of the compiler than what the kernel is built with. You must build modules and kernel with the same version.

When I run my application, I get a error :

root:~> /foo
/foo: not found

And I know my application is there:

root:~> ls -l /foo
-rwxr-xr-x    1 0        0            5341 foo

This is normally because the shared library was not installed in the ./romfs/lib directory:

root:~> ls /lib/
modules
root:~>

Just install the shared libs, and try again.

This is from syslogd dieing and then restarting. This can happen for a few reasons:

• read only file system - syslogd writes to a log file - if it fails creating this log file, it dies.
• networking not built into the system - syslogd uses network sockets

To fix this error, you have a few choices:

• Turn off syslogd
• Mount the file system read/write
• Turn back on networking in the kernel.

To change the clocks, edit the PLL settings in the configuration settings Customize Kernel Settings → Blackfin Processor Options → Clock Settings → Re-program Clocks while Kernel boots. The way the PLL works on the Blackfin is by taking the external crystal frequency, multiplying that up by VCO Multiplier (If you have a 25MHz clock, and set the Multipler to be 24, the VCO will be running at 600MHz). The core speed can be run slower than the VCO by programming the Core Clock Divider (Normally 1), and the SCLK must be run slower than the VCO, so it has it's own divisor, System Clock Divider. (If the VCO is running at 600MHz, a system clock divider of 5 will run things at 120MHz). Depending on the software load, it might be better to optimize things to have the fastest system clock possible, rather than the faster core clock.

While you can change the clocks in U-Boot by editing CONFIG_SCLK_DIV in ./include/configs/<board_name>.h, it is not recommended, since you can quickly turn your board into a doorstop. Changing clocks in the kernel is the recommended way.

On some Blackfin devices, there is an anomaly (05000263), which is something like:

DESCRIPTION:
There is an error in the hardware loop logic which can cause incorrect instructions to get executed when the processor is running loops
and instruction ICPLB exceptions occur.

WORKAROUND:
Either:
1) Avoid using hardware loops, OR
2) Make sure hardware loops are located only in L1 memory, OR
3) Make sure ICPLB exceptions do not occur while executing a hardware loop located outside L1 memory.

Since we allow hardware loops in gcc 4.1, and in kernel and user assembly optimized library functions which all run out of L3, neither of the recommended workarounds will work for Linux. What we do, is ensure there is never an ICPLB exception. To do this, we have to cover 100% of the runnable memory in 16 of the entries in the iCPLB table. 1 is used for L1, 1 is used for jumping to zero (can be disabled), so that leaves 14 * 4Meg = 56 Meg available for Linux to use as it's global memory pool.

To reduce the impact of this, we put the file systems at the top of memory (data fetches don't cause ICPLB misses), hopefully above the 56Meg mark, so you can use the entire 56Meg as a kernel memory pool. If for example, you can see this when the kernel boots, when it prints out the system memory map:

Memory map:
  text      = 0x00100000-0x0021f570
  init      = 0x00220000-0x0022ed18
  data      = 0x00232a08-0x0026a4e8
  stack     = 0x00234000-0x00236000
  bss       = 0x0026a4f0-0x002787ec
  available = 0x002787ec-0x025ff000
  rootfs    = 0x02600000-0x03e00000
  DMA Zone  = 0x03e00000-0x04000000

You can still utilize this memory yourself in your drivers, you just cannot allow instruction fetches to come from this non iCPLB covered memory. See the memory allocator page for some tips.

Depending on the silicon version you are using, it may not have this issue in it. BF533 rev 0.5, BF537 rev 0.3 this issue has been fixed. If you selected this version when building your kernel, this limitation will be removed.

Short Answer: You don't. System registers can only be accessed when the processor is in supervisor mode, which can only be done from within the kernel, i.e. a device driver. Have a look at the linux-kernel mailing list FAQ. The job of the kernel is to provide a safe and simple interface to hardware and give different processes a fair share of the resources, and to arbitrate access to resources/hardware.

If a user space application can write MMRs - there is no way for the kernel to ensure it is arbitrating access. In a device driver you should use the bfin_read_MMR() and bfin_write_MMR() functions.

The ttyS# namespace is reserved for 8250 based serial drivers. The on-chip Blackfin UART is not such a device, so we are not allowed to use the ttyS# namespace. If necessary, you can always make a symbolic link from /dev/ttyBF0 to /dev/ttyS0:

ln -s ttyBF0 /dev/ttyS0

The serial core driver supports up to 4,000,000 mbit, but only in standard incremental chunks. If you need higher or non-standard speeds (whatever the hardware actually supports), there are two ways. The standard way (termios2 + arbitrary speeds) was added with Linux-2.6.22, so for older kernels, you will need to use the B38400 hack. With the arbitrary speed support, you have to invoke custom ioctl()'s on the file descriptor for the UART using the kernel headers. So to set the speed to say 543210 baud, just do:

#include <asm/termios.h>
#include <asm/ioctls.h>
...
    struct termios2 t;
    ioctl(fd, TCGETS2, &t);
    t.c_ospeed = t.c_ispeed = 543210;
    t.c_cflag &= ~CBAUD;
    t.c_cflag |= BOTHER;
    ioctl(fd, TCSETS2, &t);
...

The older method requires a helper application. You have to set the baud to B38400 and then run the setserial program (which can be found in the uClinux vendor menu). So to set the actual divisor (UART_DLL/UART_DLH) on UART1 to a value of say 9, just do:

stty -F /dev/ttyBF1 38400
setserial -a /dev/ttyBF1 divisor 9 spd_cust

You can control the output from the kernel by using the console= and loglevel= options on the kernel command line. For more information, see the silent booting document.

This and other common PPI errors are covered in the ppi article.

This is normally because you mounted the file system read only (ro). Have a look at your U-Boot bootargs variable, if it doesn't say something like root=/dev/mtdblock0 rw (the ”rw” part is the important part), it will be mounted as read only. To modify things at runtime, just mount -o remount,rw / at the root prompt, and it will remount your root filesystem (the / part) as read write.

Now, when the kernel is booted, you get <code> ## Booting image at 20040000 …

 Image Name:   Linux-2.6.22.18-ADI-2008R1-svn
 Image Type:   Blackfin Linux Kernel Image (gzip compressed)
 Data Size:    778200 Bytes = 760 kB
 Load Address: 00001000
 Entry Point:  00144000
 Verifying Checksum ... OK
 Uncompressing Kernel Image ... OK

Starting Kernel at = 144000<code> The Entry Point (where the Bootloader jumps to) is at 0x144000, not the base load address of the kernel (0x1000), since the entry point is where the kernel's chip initialization occurs. This is only done once (when the kernel boots), and is put into the init section, which is released/discarded after the kernel is finished with it. There is no point in keeping chip init code when we don't need it. This is different behavior from older releases (where the load address and entry point were the same thing), so people using older vendor Makefiles may create broken uImages until they update their Makefile in the uClinux-dist. See any of the Analog Devices boards for the proper method to call the mkimage utility.

The full error message may look something like (exact details may vary according to your kernel configuration):

VFS: Cannot open root device "mtdblock0" or unknown-block(0,0)
Please append a correct "root=" boot option; here are the available partitions:
1f00       5120 mtdblock0 (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

The Linux kernel needs a valid root file system so that it can load and execute user space code. However, it needs to know what file system to use for its root file system, how to access the hardware where the file system lives, and how to read the particular file system. To these ends, people often times do not setup all of these important pieces:

• set root= to the proper device/partition
• build the right drivers for the hardware into the kernel
• build the right file system type (jffs2/ext2/etc…) into the kernel

Since all of the kernel modules and user space programs live on the root file system, you cannot load modules before accessing the root file system. Many people forget this and build the required kernel pieces as modules instead of into the kernel.