PetaLinux 2.6.20 with MMU support
Release notes - Version 0.10
Revision History
| Date | Version | Author | Changes |
| 22-2-08 | 0.10 | JW | Initial version |
Acknowledgements
PetaLogix gratefully acknowledges the support of Atmark Techno Inc. for funding the porting of the MicroBlaze Linux MMU support patches to the 2.6.20 kernel.
Introduction
This document is a set of sparse release notes describing how to access, build and run the PetaLinux-MMU-0.1 test release. Based as it is on a standard PetaLinux build environment, (almost all) of the documentation at http://developer.petalogix.com applies. This document is not a PetaLinux tutorial, nor an Atmark Techno SUZAKU User's Guide.
Supported hardware
Currently the only supported and tested hardware platforms are the Xilinx Spartan3E-1600 board and ML505. Support for SUZAKU series boards is in development.
Disclaimer
This is a test release, being made early to allow the community to experiment with, test, and help find bugs in the MicroBlaze Linux MMU support. This test release is not to be used for life support, aerospace or other life- or mission-critical applications.
Bug reports and patches
Please direct all bug reports, patches and user experience information to the MicroBlaze uClinux mailing list.
Download and installation
Click to download the MicroBlaze Linux MMU support test release. A kernel patch with the modifications to the existing 2.6.20-petainux kernel for MMU support is also available.
To install, simply extract the tar.gz archive in a suitable location on your Linux development workstation. All of the usual PetaLinux instructions re: supported development environments apply.
Be sure to source the settings.sh or settings.csh configuration script in the root of the petalinux tree before proceeding.
Building the hardware
The MMU-enabled hardware design is located in petalinux/hardware/user-platforms/Xilinx-Spartan3E1600-MMU-edk92 (or .../Xilinx-ML505-MMU-edk92). Build it as per standard PetaLinux hardware reference design procedures.
$ petalinux-prepare-hardware $ make -f system.make init_bram
Building the kernel
The vendor/platform combination is Xilinx/Spartan3E1600-MMU or Xilinx/ML505-MMU as appropriate. Select these from the top level petalinux-dist configuration menu.
Before running make, it is necessary to execute the following commands:
$ cd petalinux-dist $ mkdir images $ touch images/rootfs.cpio
Finally, run make from the petalinux-dist directory.
Booting the system
Booting the MMU system is identical to any other PetaLinux boot process. You can boot either via u-boot, and the ub.config.img, and image.ub file, or altenratively the kernel image can be downloaded directly to the board via the Xilinx EDK XMD utility.
Note, if downloading via XMD, the file to be downloaded is images/linux.bin (or /tftpboot/linux.bin), NOT image.bin.
You will see a console log something like the following:
Linux version 2.6.20-uc0 (jwilliams@petalogix-ws1) (gcc version 4.1.1) #2 Fri Feb 22 20:19:39 EST 2008
setup_cpuinfo: initialising
setup_cpuinfo: No PVR support in CPU. Using static compile-time info
set_cpuinfo_static: Using static CPU info.
setup_memory: max_mapnr: 0x2000
setup_memory: min_low_pfn: 0x20347
setup_memory: max_low_pfn: 0x22000
On node 0 totalpages: 8192
DMA zone: 64 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 8128 pages, LIFO batch:0
Normal zone: 0 pages used for memmap
Built 1 zonelists. Total pages: 8128
Kernel command line:
xps_intc_0_1.00.a INTC at 0x41200000 mapped to 0xFDFFF000
PID hash table entries: 128 (order: 7, 512 bytes)
xps_timer_1_1.00.a TIMER at 0x41C00000 mapped to 0xFDFFE000
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Memory: 29120k/32768k available
Calibrating delay loop... 24.62 BogoMIPS (lpj=123136)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 1024 (order: 2, 16384 bytes)
TCP bind hash table entries: 512 (order: 1, 10240 bytes)
TCP: Hash tables configured (established 1024 bind 512)
TCP reno registered
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
xgpio0 #0 at 0x42000000 mapped to 0xC2000000 device: 10,185 not using IRQ
xgpio1 #1 at 0x42400000 mapped to 0xC2020000 device: 10,186 using IRQ#5
xgpio2 #2 at 0x42600000 mapped to 0xC2040000 device: 10,187 using IRQ#4
xgpio3 #3 at 0x42800000 mapped to 0xC2060000 device: 10,188 not using IRQ
uartlite.0: ttyS0 at MMIO 0x40600000 (irq = 3) is a uartlite
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
eth0: using fifo mode.
eth0: No PHY detected. Assuming a PHY at address 0.
eth0: Xilinx EMACLite #0 at 0x40C00000 mapped to 0x40C00000, irq=2
TCP cubic registered
NET: Registered protocol family 1
Freeing unused kernel memory: 1556k freed
Mounting proc:
Mounting var:
Populating /var:
Running local start scripts.
Mounting /etc/config:
Populating /etc/config:
flatfsd: Nonexistent or bad flatfs (0), creating new one...
flatfsd: Created 5 configuration files (185 bytes)
Mounting sysfs:
Setting hostname:
Setting up interface lo:
Setting up interface eth0:
Starting thttpd:
uclinux login: root
Password:
BusyBox v1.00 (2008.02.22-10:18+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.
#
The only obvious sign of an MMU in action is that the peripheral base and mapped-to addresses are no longer the same (as they are in a noMMU, direct mapped system). e.g.:
xgpio0 #0 at 0x42000000 mapped to 0xC2000000 device: 10,185 not using IRQ
Once the system boots, /proc gives a few more insights. For example, let's take a look at the 'init' process's memory mappings:
# cat /proc/1/maps 10000000-10003000 r-xp 00000000 00:01 92 /bin/init 10003000-10004000 rw-p 00002000 00:01 92 /bin/init 10004000-10025000 rwxp 10004000 00:00 0 [heap] 48000000-4801a000 r-xp 00000000 00:01 117 /lib/ld-2.3.3.so 4801a000-4801e000 rw-p 00019000 00:01 117 /lib/ld-2.3.3.so 4801e000-48027000 r-xp 00000000 00:01 104 /lib/libcrypt-2.3.3.so 48027000-48029000 rw-p 00008000 00:01 104 /lib/libcrypt-2.3.3.so 48029000-48051000 rw-p 48029000 00:00 0 48051000-481a9000 r-xp 00000000 00:01 119 /lib/libc-2.3.3.so 481a9000-481ab000 r--p 00157000 00:01 119 /lib/libc-2.3.3.so 481ab000-481b6000 rw-p 00159000 00:01 119 /lib/libc-2.3.3.so 481b6000-481b9000 rw-p 481b6000 00:00 0 bff73000-bff88000 rwxp bff73000 00:00 0 [stack]
Here we also see one of the big changes with the MMU - shared, dynamically loadable userspace libraries (libc and friends). These shared libs live in /lib on the MicroBlaze filesystem.
Technical Notes
Compiler and C libraries
With the MMU comes a new version of the MicroBlaze gcc suite, based on GCC 4.1.1. This is a pre-built, glibc (not uClibc) toolchain. To build an application, just do
$ mb-linux-gcc -o hello hello.c
which will build by default, a dynamically linked application. To force static linking with glibc (never a good idea!), pass the --static flag to gcc.
There is just one build of glibc, built for the lowest common denominator MicroBlaze hardware configuration (no mul, div, shift etc). While this makes for portable librarie binaries, it means that all of the C library is running as slowly as possible. You application code, and the kernel code, being built within the PetaLinux auto-config framework, will make use of CPU extensions, however the libraries do not.
The petalinux solution (done e.g. with the no-MMU uClibc toolchain normally distributed with PetaLinux) is to enable multilib on the C libraries. This means a differrent compilation of the libraries for every possible combination of CPU settings. This letsus choose the most efficient binaries for a particular system, but leads to enormous host-based toolchain installs.
The solution here is not immediately apparent. For now, we will live with the single, glibc version. Any gcc toolchain gurus please give us some ideas.
Root filesystem handling
In most existing (noMMU) PetaLinux systems, the root filesystem is either ROMFS or CRAMFS, hosted on an MTD partition.
Currently in the MMU kernel, only the INITRAMFS approach is supported. The root filesystem image is provided to the kernel build process as a CPIO archive, and is statically linked into the kernel image itself. This is why, in the instructions above, you were specified to download the linux.bin (kernel image), not image.bin.
The -MMU PetaLinux build infrastructure has been extended to support automatically building such root filesystems. The top level menuconfig -> user/vendor settings -> system settings menu option has been extended to add INITRAMFS as a supported root filesystem type. When selected, the build system will automatically create and insert the root FS CPIO archive into the final linked kernel.
It is expected that support for more familiar root filesystem management techniques will follow.
Kernel MMU vs noMMU
Enabling or disabling the MMU is now a kernel configuration setting. MMU and NO-MMU kernels can be built from the same source tree.
Work to be done
- Port MMU support into uClibc for MicroBlaze, and build a standalone, multilib'd toolchain. Ideally, an extra multilib option (-mmu / -nommu) would be added to allow automatic choice of uclibc versions etc.
- Finalise the merge of the MMU and noMMU code, particular in arch/microblaze/kernel/entry.S (vs entry_MMU.S), and hw_exceptions.S
- Complete and verify MMU support for various xilinx device drivers. Not much effort is expected here.
- Re-implement kernel command line handling
- Support for SUZAKU series boards.
- Merge into mainline PetaLinux distribution
- Test, test, test
Attachments
- linux-2.6.x-petalogix-MMU.patch (1.2 MB) -
Patch to update PetaLinux-2.6.20 kernel to MMU support
, added by jwilliams on 03/05/08 11:22:54.
