To get started, my environment is QEMU using the versatilepb model. I used a couple blog posts from Balau, who is great and you must go through his stuff to get setup. He uses the CodeSourcery toolchain, so I do as well. I’d also recommend setting up Linux under ARM to get a feel for QEMU and what is going on. I begin this after Balau leaves off. He has already written the setup instructions better then I could.

So to start, the goal is to setup a very small multitasking OS (peenix) using the ARM processor(peenix – the ARM). After much reading, step one is to setup the Vectored Interrupt Table.
Step 1
read the ARM PL192 Manual
The Vectored Interrupt Table is typically located in memory at 0×0. The table contains instructions that branch to handler functions. The CPU will execute the proper instruction when an interrupt is received.

1. 0×0 – Reset
2. 0×4 – Undefined Instruction
3. 0×8 – SoftWare Interrupt (SWI instruction)
4. 0xc – Prefetch Abort
5. 0×10 – Data Abort
6. 0×14 – Reserved
7. 0×18 – IRQ
8. 0x1c – FIQ

When the system gets the Reset interrupt, the instruction at 0×0 is run. When the system gets the SWI instruction, the instruction at 0×8 is run, etc. Here is the startup code that I have for the first few interrupts

.section INTERRUPT_VECTOR, "x"
.global _Reset
_Reset:
 B Reset_Handler
 B .
 B SWI_Handler
 B .
 B .
 B .
 B .
 B .
 
Reset_Handler:
 LDR sp, =stack_top
 BL c_entry
 B .

The first thing that happens on load is _Reset is called. Then we branch to Reset_Handler, which sets up the stack and calls our entry point. This will work because of our linker script, but the table isn’t located at 0×0 yet! When we load with QEMU, our code is located at 0×00010000. When we get an exception, the processor is not going to know where our table is. We have to move it.

I do this by reading each branch instruction from our table, increasing the offset, and writing that instruction the new table’s location (at 0×0+offset).

void vic_remap()
{
        unsigned int* vit = (int)0x010000;      // Code start
        unsigned int* new = 0x0;                // Destination
        unsigned int instruct;
        int q;
 
        /* Increase the B offset to reach our table at 0x010000 */
        for(q=0;q<8;q++)
        {
                instruct = (int)*vit;
                instruct += 0x4000;
                *new = instruct;
                vit++;
                new++;
        }
}
 
// c_entry is called on startup
void c_entry() {
 vic_remap();
}

Now if you startup QEMU and use GDB, you can see that the table has been moved to the proper location.

Lets try to do something useful with this. We’ll catch SWI instructions. Let’s create a simple SWI handler. When the SWI is fetched and decoded, the processor will branch to memory address 0×08. Since we moved our table, 0×8 contains a branch instruction to the SWI_Handler function. Lets create that function now:

void __attribute__((interrupt("SWI"))) SWI_Handler()
{
   volatile unsigned int r0;
   volatile unsigned int stackp;
 
   /* The SWI interrupt number will be part of the instruction.
       LR points to the instruction after SWI, so load we load
       the instruction right before LR, then mask out the SWI
       leaving us with the number */
   asm("LDR r0, [lr, #-4]");
   asm("BIC r0, #0xFF000000");
   asm("MOV %0, r0":"=r"(r0):);
   asm("MOV %0, sp":"=r"(stackp):);
 
   printf("SWI %x\n", r0);
   printf("Stack: %x\n", stackp);
}

By adding a small bit of code to c_entry() we can call this function using SWI 0xab, and get that 0xAB call number.

This becomes important later on when we need to change processor modes. With the current demonstration we are always running in SVC mode. In part 2 we will change to USER mode. This means that we have to generate an exception (swi, interrupt, etc) in order to get back into SVC mode.

Relevant Links
http://www.13thmonkey.org/documentation/ARM/HAI.pdf
http://git.savannah.gnu.org/cgit/qemu.git/tree/hw/versatilepb.c
http://www.heyrick.co.uk/assembler/swi.html

But I am just too slow to justify using it at work. When I’m home I am just too uninterested in letting a new keyboard layout get in the way of the work I’m trying to accomplish. I had mentioned before that its not the layout, its the muscle memory that I have to relearn. I usually end up damaging code in VI because I just happen to not think for a second and hit all the wrong keys, then I have to go back and I end up taking twice as long to edit some function.

Trying to do anything sys admin related is horrendous. I got some perspective though, I now know what it must feel like for Windows people to have to use the keyboard. I really take for granted that I just grok Linux and can do things very quickly from the keyboard. Well, try changing the location of all your keys. You slooooow down. All of a sudden what used to be a simple thing becomes work that I’d rather not do. Try to bang out a quick database query in SQL? Hell no.

So I have to admit failure with dvorak. It was neat, and I had hoped for good things. Maybe when things are slower I’ll have more time.

I’m reminded of my quick productivity rant about how having to learn all these little tricks to increase speed just dont cut it. Even if I get better with dvorak then qwerty, how much will it really help? Im going to keep trying though.

Anyways, tomorrow I go to work and try it out there. So we shall see how low my productivity is.

Watch dog error: Tsk {29,31,32,35,36}

From what I’ve seen this has nothing to do with the Watchdog. Certainly not the application Watchdog, and I am able to generate these errors without executing any tasks that take long enough to trip the firmware watchdog. I will assume that there is a double secret memory watchdog that I haven’t seen documented anywhere, and this is the watchdog reporting these errors.

• Tsk 30/31 – Memory read/write errors. I can not reliably reproduce these, but if you have heap overflows and release memory you tend to get these errors. Also if you try to read/write from a bad address you get these errors, but again, not reliably.
• Tsk 35 – I was able to reproduce this error by sending too many messages to a task with the adl_msgSend() function. I was getting events that would cause my code to send a message faster then I was processing those messages. I would reboot with Tsk 35 quite frequently. After I refactored the code and removed that messages part, I haven’t seen this error.
• Tsk 38 – I got this error a lot when my reserved stack space was above 64k. If you go just a little above, probably not an issue. But I was way over, and would reboot with this error frequently. If you do see this, adl_memGetInfo to see how much stack you are reserving. Note: If you get RTK 190 errors, you probably aren’t reserving enough stack space. Although I haven’t seen RTK 190 documented anywhere, its pretty easy to test, and I can reliably reproduce it.

I have seen every error from Tsk 29 to Tsk 38. I can’t reproduce many of them reliably, which probably indicates that multitasking memory problems are the cause. Not necessarily the Q64 firmware being the problem, its usually something I can fix in my code without having to refactor much, but it would be nice to know what actually happened last time I rebooted. I’ll keep updating the list as I am able to narrow down the causes of additional errors.

Steve gives advice on rearranging your keyboard layout to not move you fingers of home row. Many vim guides tell you to use the home row keys instead of the arrows to move through text to avoid the extra hand motions.

Srsly you aren’t that productive.

I am imagining cubes of coders where the typing never stops. All day long they just bang out code, they never leave home row unless the absolutely need to type a Q. They think in C, and artfully paint LISP all over their screens and all the other crap that people say to pretend that real world problems always have elegant A+ compsci solutions.

Am I really the only one that has to alt-tab back to the email to remember the process outlined in whatever spec I’m implementing?

Is it just me that needs to IM somebody about why bug 69 was resolved the way it was and explain why that impedes my ability to implement customer request 7?

I refuse to believe that nobody else looks at the last three functions they wrote and actually stops to think “Could I do this better?”

I’m just saying the stuff that slows me down while I code is thinking. Not the 1.5 centimeters between my shift key and my arrow keys. Or the difference between moving my left pinky .5cm left, over 2cm down. I think the time/mistakes it would take me to get used to using hjkl as movement keys instead of the arrow keys would be more then the time saved from reducing the extra miniscule movement.

I read this post by Yehuda Katz and, while I find it interesting that using his mouse lead him to the ‘/’ and ‘o’ and ‘ci’ commands, he is right. Don’t sacrifice the ability to code comfortably for these silly little “performance gains”. You are optimizing the wrong part of your algorithm. If you really need to speed up your ability to copy/paste, maybe you should slow down and think about what your doing.