MACH_TYPE

I’ve had this happen a couple of times now when testing kernels. When the kernel is starting you get an error like “Error: unrecognized/unsupported machine ID (r1 = 0×0000034e)”. The reason you get an error is because the bootloader is supposed to pass the MACH_TYPE to the kernel, and if it doesn’t match what the kernel was compiled with then the kernel won’t start. This time I knew what was going on, but I didn’t remember where the ID was defined. So I did a few fgreps for 34e, with no luck. This is because MACH_TYPE is defined in decimal not hex. Once you figure out to look in include/asm-arm/mach-types.h everything makes sense.

u-boot & gdb

U-boot is a full featured bootloader that is often used to load Linux on non-x86 platforms. Recently I’ve been messing with u-boot some. I’ll go through how to quickly get started with u-boot and a simple gdb + JTAG setup. I’m using the signalyzer JTAG with openocd software. First grab a copy of u-boot. Either a released version from ftp or if you want the latest git testing version do “git clone git://git.denx.de/u-boot-testing.git”. Now building u-boot is really very easy all you have to do is choose a config by doing “make xxx_config”  to look at the different configs look at include/configs/. So for example “make imx27lite_config”. Now just run make specifying the cross compiler “make CROSS_COMPILE=compiler_prefix”. This creates two output files u-boot and u-boot.bin. u-boot is the the elf file that we will want to use with gdb. First we need gdbinit file, the following works fine:

# SETUP GDB :
#
# Common gdb setup for ARM CPUs
set complaints 1
set output-radix 10
set input-radix 10
set prompt (arm-gdb)
set endian little
dir .

# CONNECT TO TARGET :
target remote 127.0.0.1:3333

#  LOAD IMAGE :
#

# Load the program executable called "u-boot"
load u-boot

# Load the symbols for the program.
symbol-file u-boot

# RUN TO MAIN :
#
# Set a breakpoint at _start.
b _start

Now openocd needs to already be running to allow the gdb connection, then running a command like “arm-unknown-linux-gnu-gdb –command=gdbinit” will start gdb. The gdb prefix should be the same as the compiler prefix. Now there should be a command prompt like (arm-gdb) before we can start stepping through u-boot we need to issue 1 continue just using the letter “c” works for this. Now we can start stepping through u-boot using the step or “s” command. You’ll notice that u-boot begins in start.S. If you look back at the source code you’ll notice that there is a start.S for each CPU architecture. Now we can go to town stepping and adding break points.

Using a multi-core design to acheavie hard real-time

Traditionally there are two types of multi-core designs, Symmetric & dedicated. Let me give a couple of examples. A symmetric design would be what you have in your multi-core x86 desktop. The term SMP “symmetric multiprocessing” is used to describe these designs. In symmetric designs the cores are functionally identical. A dedicated design would have a general purpose core as well core(s) dedicated to a specific task(s). A good example would be the TI OMAP 3525. The application core is an ARM Cortex-A8, but is also incorporates a DSP core for video processing.

The advantage of the symmetric design is that the OS is aware of and uses all of the cores for general processing. Both kernel processes and user processes can run on all of the cores. The advantage of the dedicated core is that it can preform it’s specific task very fast, and without interruption from the OS.

I wonder if the best of both worlds couldn’t be combined. Could the SMP interface of the Linux kernel be modified so more control is exerted over the use of specific cores. For instance you could say that only a specific process could be run on a specific core. I think the trick comes in how the kernel interface is handled. Some functions you would just want to call and let the kernel run it on a different core (like a networking function). It might be possible using this strategy to obtain hard real-time operation within the kernel.

Thoughts on Sparc

So easic is now advertising their capability to produce ASICs based on the Leon3 processor. The Leon3 is a 32-bit open source Sparc processor. To my knowledge no one has taken advantage of this to create a general purpose processor available to the public.

So there are now 4 open source Sparc implementations, and not a single part you can buy at digikey. The first implementation is the T1 processor from Sun. The T1 is an 8-core 64-bit chip, and it is an actual part that Sun uses. However, it is not low cost, low power or available through standard distribution. The second implementation is the successor to the T1, the T2. The T2 is an impressive chip, Sun likes to call it a “server on a chip”, and it has many features built in including: dual 10 Gbe, 8x PCI express and memory controllers. The third implementation is the S1 which is a derivative of the T1 created by Simply RISC. The cool feature about the S1 is that it implements a wishbone interface, which is the SOC bus preferred by the folks at opencores.org. And the fourth implementation I mentioned earlier, the Leon3 from Gaisler Research. The nice thing about the Leon3 is that it uses the AHB (same bus that ARM uses), and they have an extensive IP library of peripherals to use with the Leon3.

I am fascinated by the activity we are seeing, buy I’m still waiting for the chips. Are there other people interested in a general purpose Leon3 processor (not an FPGA implementation)?

I2C fun with the AT91RM9200

So I was messing around with I2C on the AT91RM9200 when I ran into the i2c tools. These tools were very simple to compile and use. For cross compiling all I had to do was “make CC=arm-linux-gcc”. Then I had the i2cdetect, i2cdump, i2cget, i2cset tools. I used these to debug the RTC chip. To get the rtc driver to work I added the following lines to board-ecbat91.c:

static struct i2c_board_info __initdata ecb_i2c_devices[] = {
{
I2C_BOARD_INFO(“isl1208″, 0×6f),
},
};

And then in ecb_at91board_init I added

at91_add_device_i2c(ecb_i2c_devices, ARRAY_SIZE(ecb_i2c_devices));

Linuxstamp is going to Linuxworld

We will be part of the Linux Garage, a new section they are adding this year.  Linuxdevices.com had a good write up. Also you can check out the expo site here. We will be there August 5-7. We hope to have several demos up including: a GPS system, servo controller and audio device.

Linuxstamp modules available

We now have initial production quantities available. If you are interested in a Linuxstamp please email me pthomas8589 _at_ gmail _dot_ com. They are $120 plus shipping. Right now I can just accept paypal. Hopefully we will have a website up soon.

Power Over Ethernet working

I have the POE working on the Linuxstamp. I’ll go through all of the equipment that I am using. To supply the power I looked at POE injectors, but they didn’t seem that economical for one port so decided on the Trendnet POE switch. It has 4 POE ports and 4 regular ports. Next is the ethernet connector on the Linuxstamp. After much looking I found this Pulse Jack. The only thing I don’t like about it is that it is over an inch long. All the jack is doing is bringing out the centers of the primary transformers (where the 48v is). I then run the 48v to a prototype motherboard where I have the Ag9050. The Ag9050 is an isolated 48v -> 5v POE module. The only other component is a 470uF cap on the 5v output of the Ag9050 (Linuxstamp 5v input). Now the Linuxstamp can run without a wall wart.

Prototype boards

Here is a pic of one of the first prototypes. Things are going very well. U-boot is working, and we’re working on getting the rest of the system working.

Linuxstamp google group

http://groups.google.com/group/linuxstamp