Frequently Asked Questions This is a general collection of some of the most frequently asked questions about Blackfin Linux. Some of the questions even have answers - to find them, click the question (like most of the side, you must have javascript enabled). Some topics have so many FAQs, a page was created specifically for them! Das U-Boot FAQ Visual DSP FAQ General Questions Why do I want to use Linux? Why do I want to use Linux? See why use linux What is the difference between uClinux and Linux? What is the difference between uClinux and Linux? See the Introduction to uClinux Is it more difficult to debug uClinux applications than Linux applications? Is it more difficult to debug uClinux applications than Linux applications? Debugging uClinux application is the same as debugging Linux application. We can use printk() to print out kernel information; use GDB (GNU Debugger) to debug applications; or use KGDB (Linux Kernel GNU Debugger) to debug the kernel or drivers. Is Linux more stable than uCLinux? Is Linux more stable than uCLinux? 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 How difficult is it to port a Linux application to uCLinux? How difficult is it to port a Linux application to uCLinux? Easy - See porting_applications. Which Toolchain should I use? Which Toolchain should I use? 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. What is the licensing model for Linux? Where can I find more information on GPL and LGPL? What is the licensing model for Linux? Where can I find more information on GPL and LGPL? See Software License. Which release shall I use? Live source or release? Which release shall I use? Live source or release? 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. Is there a feature list? Is there a feature list? Yes - features Why isn't silicon revision XXX supported? Why isn't silicon revision XXX supported? 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. I have found a bug, where to report it? I have found a bug, where to report it? 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. Why do I need to use the same version of toolchain/kernel/uClibc/U-boot/uClinux-dist? Why do I need to use the same version of toolchain/kernel/uClibc/U-boot/uClinux-dist? 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 (Executable and Linking Format) 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. I want to learn more about Linux development. Can you recommend a good resource? I want to learn more about Linux development. Can you recommend a good resource? There are many good resources at the references and pointers section What is the typical Blackfin power consumption and what can I do to improve it? What is the typical Blackfin power consumption and what can I do to improve it? 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 What is the system boot time and what can I do to improve it? What is the system boot time and what can I do to improve it? The total system boot time can be as low as 0.4 seconds – Estimates tips and tricks are detailed here: fast_boot_example What is the typical Blackfin Linux Flash Memory footprint what can I do to improve it? What is the typical Blackfin Linux Flash Memory footprint what can I do to improve it? 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 Is cygwin supported? Is cygwin supported? 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. Common Build Errors Busybox build fails with ''mixed implicit and normal rules'' Busybox build fails with ''mixed implicit and normal rules'' Newer versions of GNU (GNU's Not Unix) make changed their handling of implicit rules and did so in a backwards incompatible way. The latest versions in svn have been updated to address this. You can find the relevant commit here. I get errors about linux/mtd/ftl.h, flash_eraseall.c, or ftl_format.c I get errors about linux/mtd/ftl.h, flash_eraseall.c, or ftl_format.c 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. Can I build the uClinux-dist on a 2.4 host Can I build the uClinux-dist on a 2.4 host 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: update to latest cvs - this has been fixed. 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. My host is running Linux 2.6, why I still cannot build the uClinux-dist My host is running Linux 2.6, why I still cannot build the uClinux-dist 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): /include/linux/mtd/. If it is not there, you can copy (or link) the target mtd directory from /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). While building, make aborts with "expand.c:489: allocated_variable_append: Assertion ... failed." While building, make aborts with "expand.c:489: allocated_variable_append: Assertion ... failed." 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. Building the kernel in the uClinux dist fails with "No rule to make target `drivers/base/bfXXX', needed by `drivers/base/cpu.o'" Building the kernel in the uClinux dist fails with "No rule to make target `drivers/base/bfXXX', needed by `drivers/base/cpu.o'" Same issue as the previous FAQ (Frequently Asked Questions) (expand.c:489:…..). See that question for the answer. While building the uImage, genext2fs segfaults! While building the uImage, genext2fs segfaults! 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 I get errors about "no free space" when generating EXT2 images I get errors about "no free space" when generating EXT2 images 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 rootfs. My uImage is too large to burn in my flash My uImage is too large to burn in my flash 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). Just unselecting previously build applications or libraries will not remove them from the./romfs. You need to either: remove them by hand (rm ./romfs/bin/strace && make image) remove the entire romfs folder (rm -rf ./romfs && make romfs image do a make clean && make 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. I get "BINFMT_FLAT: bad flat file version 0x5" errors I get "BINFMT_FLAT: bad flat file version 0x5" errors 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. I get errors about "BINFMT_FLAT: bad header magic" or "Applet not found" I get errors about "BINFMT_FLAT: bad header magic" or "Applet not found" You need to specify extra flags at link time. Either specify -mfdpic (and make sure ELF (Executable and Linking Format) 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 (American Standard Code for Information Interchange) mode. Make sure you transfer only in binary mode. I get "bfin-uclinux-mkimage: command not found" errors I get "bfin-uclinux-mkimage: command not found" errors 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. How do I enable Large File Support in uClibc / Toolchain How do I enable Large File Support in uClibc / Toolchain 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 I nfs mount the root file system, some directories look they are missing When I nfs mount the root file system, some directories look they are missing 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 ) Upgrade your host cpio application to something that isn't broken Building packages fails with stdarg.h missing! Building packages fails with stdarg.h missing! 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. Running config.sub results in "machine `bfin' not recognized" Running config.sub results in "machine `bfin' not recognized" The config.sub file is outdated. Simply copy the version from uClinux-dist/tools/config.sub over the local version. Building GCC 4.3 fails! Building GCC 4.3 fails! Building GCC (GNU Compiler Collection) 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 likergetz@pinky:~/blackfin-trunk> grepMPFR_VERSION_STRING /usr/include/mpfr.h#define MPFR_VERSION_STRING "2.2.0 Common Questions about Kernel Settings Some device nodes in /dev seem to be missing! Some device nodes in /dev seem to be missing! Please see the dev-management page for more information (especially the troubleshooting section). How do I access the Power Management features of the Blackfin? How do I access the Power Management features of the Blackfin? Please see the power_management_support page for more information How do I change the network settings for the Blackfin? How do I change the network settings for the Blackfin? 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 (Dynamic Host Configuration Protocol) 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. How do I allow more telnet sessions into the Blackfin? (error: All network ports in use) How do I allow more telnet sessions into the Blackfin? (error: All network ports in use) 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 What does a normal Boot Look like? What does a normal Boot Look like? 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 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:~> How do I port applications to Blackfin Linux? How do I port applications to Blackfin Linux? port_program_to_linux. Also This page describes some of the problems and solutions for porting large multi-threaded applications to uClinux. How to config user login? How to config user login? See managing users. Problems installing modules? Problems installing modules? 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. I get a "not found" error I get a "not found" error 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. I get a "init: /bin/syslogd respawning too fast" error I get a "init: /bin/syslogd respawning too fast" error 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. How do I change the clocks? How do I change the clocks? To change the clocks, edit the PLL (Phase Locked Loop) settings in the configuration settings Customize Kernel Settings → Blackfin Processor Options → Clock Settings → Re-program Clocks while Kernel boots. The way the PLL (Phase Locked Loop) 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 (System Clock) 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 (System Clock)_DIV in ./include/configs/.h, it is not recommended, since you can quickly turn your board into a doorstop. Changing clocks in the kernel is the recommended way. Blackfin board only shows ~60meg free with 128meg (Anomaly 05000263) Blackfin board only shows ~60meg free with 128meg (Anomaly 05000263) 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. How do I access system registers from user space? How do I access system registers from user space? 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. (in other words) 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 (Memory Mapped Register)() and bfin_write_MMR (Memory Mapped Register)() functions. Why is the blackfin serial port named ttyBF0? Shouldn't it be named ttyS0? Why is the blackfin serial port named ttyBF0? Shouldn't it be named ttyS0? The ttyS# namespace is reserved for 8250 based serial drivers. The on-chip Blackfin UART (universal asynchronous receiver/transmitter) 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 How do I specify custom/high baud rates with the standard UART driver? How do I specify custom/high baud rates with the standard UART driver? 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 (universal asynchronous receiver/transmitter) using the kernel headers. So to set the speed to say 543210 baud, just do: #include #include ... 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 (universal asynchronous receiver/transmitter)_DLL/UART (universal asynchronous receiver/transmitter)_DLH) on UART1 to a value of say 9, just do: stty -F /dev/ttyBF1 38400 setserial -a /dev/ttyBF1 divisor 9 spd_cust How do I tell the kernel not to print things out the UART? How do I tell the kernel not to print things out the UART? 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. PPI Underrun Overflow Errors? PPI Underrun Overflow Errors? This and other common PPI (Parallel Peripheral Interface) errors are covered in the ppi article. Can bfin_ppi simple PPI driver do continuous data input or output? Can bfin_ppi simple PPI driver do continuous data input or output? bfin_ppi driver can't support continuous data. If you want to support continuous data, you must either extend bfin_ppi driver to support queue/dequeue model and ping-pong buffer, or write a V4L2 driver. I get "Read-only file system" errors I get "Read-only file system" errors 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. Why is the kernel start address in the middle of the kernel memory space? Why is the kernel start address in the middle of the kernel memory space? Now, when the kernel is booted, you get ## 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 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. Booting the kernel fails with "Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)" Booting the kernel fails with "Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)" 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.