the IXP1200 series (1200, 1240 and 1250) network processors are based on the Intel ARM SA1100 core. However, each is a different chip altogether.
the 1200 runs at 166 Mhz, the 1240 at 200 and the 1250 at 233.
The following boards have been built around these chips:
Intel IXP evaluation board (IXP12EB), based on the 166Mhz IXP1200.
There appear to be three revisions: A0, B0 and C0. the first two of these contain bugs that had to be circumvented in software. not all bugs have been fixed.Intel IXM1200 evaluation board (Spectacle), based on the 1240 and/or 1250 Radisys ENP 2505/2506 PCI daughterboard, based on the 1250, running at 233 Mhz.
the 2505 contains 10/100 MBit ethernet controllers the 2506 contains 2 Gbit ethernet controllers
In order to understand how much the IXP might resemble other ARMbased systems, and therefore how portable available software might be we tried to find out its family line. As said, the ARM SA110 was extended into the SA1100. Examples of boards based on the SA1100 are the Itsy and Brutis (I'm not making this up :) by Compaq research.
The SA1100 formed the basis of both the IXP1200 and the later xScale CPUs. IXP platforms based on xScale processors exist and have been named IXP2XXX (IXP2000, IXP2400, ...). The numbering scheme of the xScales appears to be PXA250/26X and IXP4XX. These SA1100 derivatives are marketed sometimes as StrongARMs?, although I couldn't find a technical reason for this namechange.
Lastly, there's another boardtype which is frequently mentioned online and that's the Footbridge. The clearest description of it was that it is the `PCI core logic device for the StrongARM?', whatever that may mean. In any case, the IXP has been mentioned with references to the Footbridge. I don't know how closely they are connected.
after looking at the different patches that have been applied to the linux-2.3.99 kernel the following seems to be the case:
the rmk patch series adds support for many ARM based systems. The patch therefore adds more than simple CPU support the rmk-np patch series adds support for the SA110(0) ARM based boards originally developed by DEC and later sold to Intel. the (rmk-)ds patch series adds support for the IXP4XX based boards, although a ds.ixp1200 patch for kernel 2.4.17-rmk5 has
floated around on the internet. It has currently been removed. We can always ask the developer for it, though. One note of caution: Deepak, who made it, mentioned that IXP12EB boards suffer from garbage of the network with this patch. The IXM1200 boards should be fine.
starting with kernel series 2.6, much of the rmk patch has been imported into the main kernel. As of version 2.6.2, the ds patches, for instance, no longer require the rmk patches to work. This might make porting IXP code more easy.
This kernel (kI) is based on the linux 2.3.99-pre3-rmk3-np2 patched kernel (kP). After inspecting a difffile with the changes between kP and kI we can say the following:
- there actually exists a `diffs' file in the root of the kI sources by some guy named Dirk. This can give us some help finding out how much of the changes are IXP specific.
- the bulk of the patch has to do with adding VMON support. VMON is a realtime debugging enviroment by Viosoft (viosoft.com). This company still sells development environments for various embedded ARMbased solutions, including one specific to the IXPs. Their environment contains a complete 2.4 kernel (based on the previously mentioned ds.ixp1200 patches) and best of all, you can order a 30-day trial version of the entire SDK for free.
It appears that Intel therefore applied a third-party patch. We can simply skip trying to port this.... unless the `VMON virtual ethernet support' option is needed to use ethernet over PCI. I don't think so, but it could be. More info can be found in drivers/net/vmon-eth-vd
the second largest part of the patch deals with adding true big-endian support to the kernel (see below for more information regarding endianness). This was written by someone at Intel, Uday Naik, so we won't be able to find a patch online. As of kernels 2.6, big endian support is integrated into the vanilla kernels. It is also marked as being NEW in linux 2.4.21. Again, we shouldn't need to have to recreate this part of the patch for newer kernels
Most of this fits neatly into a few special files. The writer has added the CONFIG_IXP1200 type under arch=ARM. They further make the subdivision between CONFIG_SPECTACLE_ISLAND (the IXM1200) and CONFIG_IXP1200_EVALBOARD for some small cases. Because of the CONFIGs, finding the IXP specific code is simple. Porting shouldn't be too hard.
when building IXP support, the options CONFIG_SERIAL_IXP1200 and CONFIG_SERIAL_IXP1200_CONSOLE become available. These are adaptations from the standard serial and console-over-serial options. Similarly, much of the sourcecode is copied from standard serial access. Porting this should be straightforward. The only tricky part is that besides the .c file there also exist .c.footbridge and .c.sa1100 files.
Also, the CONFIG_IXP1200_FLASH flag appears in the code. I have no idea what it does. The documentation mentions that it is a driver for programming the intel 28f80b3b flashROMs. Should this be ported?
Finally, there's a new subdirectory under /include/asm-arm called arch-ixp1200. This contains ixp1200 specific files. Only one of these, board.h, is expected to change between IXP1200 platforms. The rest should therefore not normally be touched.
-- ugly hack: linker/builder scripts and default configs. These can be ignored. (ref: config.opt.... and arch/arm/vmlinux-arm[o|v(.cored)?].lds.in) -- drivers/net/eepro100.c changes. I guess this deals with the ENP2505. In any case. The eepro drivers have probably changed so much, that we can forget about porting this, anyway. -- drivers/pci/pci.c : changes to the handling of the PCI bus. Those that I understand have to do with endianness and
bug workarounds for older (A0, B0) boards.-- include/linux/pci-ids: PCI IDs, simple stuff -- special ramdisks: CONFIG_LINK_RAMDISK_IMAGE is an extra option on top of the normal ramdisk. Some of the 4 default
configs are documented to use this. I think we can skip it, as it is mostly related to the SDK specific stuff. Not 100% sure, though.-- /include/asm-arm/proc-armv/uncompress.h : this is tricky stuff, most of it in assembly. I haven't a clue. -- there are more files under /arch/arm/special. These have to do with keyboard layouts mostly, so they don't seem important.
the following should be safe to ignore:
-- non hardware specific changes to net/core/sock.h and net/ipv4/tcp.c -- new usage of option CONFIG_KERNEL_DEBUG in /include/linux/init.h -- small changes in the SCSI subtree and to /fs/exec.c -- small changes to /scripts/split-include.c
It appears that the CPUs can work both in little and big endianness. However, the boards can also be wired in two ways. That gives us 4 possible configurations, as is discussed here:
http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2001-November/006141.html
It is mentioned here (http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2002-March/008000.html) that the boards' PCI busses are wired `backwards'. I don't know what it means, but apparently it's important when considering byte-ordering.
If you want to use the boards in big endian mode, you will need a big endian toolchain. An older version, based on GCC 2.95 is handed out with Intel's SDK. However, there are ways to build never versions. AFAIK a big-endian toolchain is normally referred to as 'armbe' or 'armv4b'. When discussing the big-endian chain with software emulation for floating point instructions, the term `armv5b' is used. The v4/v5 distinction might actually mean something completely different, though.
In any case, here are three ways to update the toolchain:
1) using uCLibc, with some patches. Supposedly works for GCC 3.3.2 (= recent) http://www.davehylands.com/linux/ARM-bigendian/ is broken, try google's cache, instead: http://www.google.nl/search?q=cache:ZKhVU0aSdhwJ:www.davehylands.com/linux/ARM-bigendian/+big+endian+arm&hl=nl&ie=UTF-8
2) using crosstool, a de-facto standard script for these tasks, based on the older crossgcc: This is probably the preferred solution, as crosstool will probably stay in development for some time to come. http://www.spinics.net/lists/arm/msg06662.html http://www.kegel.com/crosstool/
3) without help (notice that the linked message discusses IXP2400, but that shouldn't matter) https://lists.cs.princeton.edu/mailman/private/ixp1200/2003-May/000764.html
the IXPs have a bunch of different memory layouts. Coupled with ARM specific memory layout heuristics this can lead to some problems when moving linux about. The following document describes the IXP layout in fair detail: http://www.capsl.udel.edu/~fchen/projects/np/docs/manual/Pdf/BSP/IXM1200_NP_UG.pdf (it's by Intel and marked confidential, so it should be rather good). This document also describes how to add support for new IXP based boards to the kernel.... so it contain porting information as well.
![[Home]](/wiki.gif)