Sunday, September 26, 2010

SCU on ARM11MPCore will not give you coherency

Well, we thought otherwise. But, that was not correct. This was a very interesting experience. We started writing the communication module to make two different cores of ARM11MPCore communicate and found that things are not going fine as we were expecting them to. We write from one core and we cannot read it back from other. First suspect was the new virtual addresses that had happened in VxWorks. However, that was not the issue. After reading about it a bit, we were convinced that it must have been a linear mapping in our case. Now, what was the reason? The next suspect was the cache. However, the process was not simple. No one except me in the whole group believed that it can be caused by cache. Also, I myself was doubtful as I felt SCU should take care of it.

To clear our doubt, we talked to a manager in our company who was an expert in JTAG. He appeared completely assured of the fact that we are doing something dumb with JTAG as we cannot see this memory even in JTAG. When I asked about cache coherency issues, he brushed aside my doubts saying that it can never happen.

Well,  after giving the advice, he walked away without turning back. But, I was the tech lead for this project and I had to get this working somehow. And, something kept telling me that this is a cache issue. So, I decided to keep hammering at that point. Now, we were writing from VxWorks and reading from Linux. I decided to look for code which will flush cache. But, being a noob in VxWorks, I could not find this code. We tried some silly tricks in the beginning like increasing the memory size in the hope that cache will get flushed auto-magically. Fortunately or unfortunately, these tricks did not work. However, one guy in our team was able to dig out VxWorks function to flush cache. It was a simple function that took the cache type, address and length as the arguments and it did its job! (Yes that was simple compared to what I found for Linux. We had to get physical address of the memory, get page structure and then flush the page from cache!) Yes, after flushing the cache, we were able to see what was being written by the second core into the memory location from the code that was running in first core. Later, another member in my team found that SCU will not do this in case of ARM11MPCore. It does this in case of some other newer chips (Cortex-A9). We also read that allocating DMA memory might do the flushing directly. We are yet to try this.

Linux IPI handling for ARM11MPCore (ASMP)

We have been struggling for a while with this. Last Friday, I nailed him down.Ok, the background story...

We knew that IPI (Inter Processor Interrupt) can be used to communicate with other processor. Linux has support for this in SMP mode. However, we are doing ASMP. We wanted to use it slightly differently to device a custom communication module with another core running VxWorks. Now, the first hurdle came in the form of not being able to write to some registers. That was a dumb mistake of not ioremapping the register addresses. After that we faced another problem of not being able to register an interrupt. After a bit of debugging, we found that the reason is that there is no chip descriptor registered for interrupts 1-16 (They are the interrupt numbers for IPI). Well, the init code for interrupt was doing it for interrupts >= 29. But why?

It is this question that forced us to spend a week to resolve. There was one guy working on it continuously and I will break my head whenever I get time. Now, we tried the most obvious. We changed 29 to 1 in init code for interrupts. This enabled us to register the interrupt. However, this did not cause our interrupt function to be called when we wrote to the register. Last Friday, I decided to look at realview code. And it paid off. I could see that, they are also registering the interrupt from 29 onwards in the initialization code. Now, what was the problem? To know that, I had to delve much deeper. The answer came from the low level vector interface routines. The do_IRQ was not responsible for handling IPI. Instead, there was a do_IPI function. We immediately reverted the changes done in the irq initialization code. Then, we put some code into do_IPI

Well, thats it! our interrupts started working. We did face some issues while writing to the shared memory. All about that in another post.

Sunday, September 12, 2010

$35 tablet

Well, today I saw this news about $35 tablet

As per that page, governments claim of developing a tablet here in India is false. The blogger claims that the tablet is imported from China. But, the government claims that it is developed by a student in Vellore. Now, have a closer look at the Chinese one

If you see that closely, this device is based on ARM11. It has 256MB RAM. Well, I have been looking for the specs of the Indian tablet. Guess what I found:

The device seen there is very much speculated to be the Indian device that is priced at $35. However, that seem to be something made by a private company and not by universities or government. More details of this can be found here:

If that were the device which Mr. Sibal was talking about, then it is pretty clear that there is a difference in the processor itself (this one uses ARM9, i.MX233) and they are indeed different apart from the plastic out side. Sadly, I could not find more details on the stuff Mr. Sibal was talking about. The best I could get was this:

Well, now I am confused. What is the spec of the stuff that government is going to bring out? Who is this AllGo guy? Did the student after making it at campus go and join this AllGo? Was this a reference design that Freescale or someone like that floated and everyone copied? Did the student who designed it, copy the stuff from somewhere else?

The government tablet seems to have 3G support and 2G RAM. The AllGo one does not have 3G and the RAM is only 128MB. Well, I really doubt 2G RAM is a mistake. Else that itself will cost > $35. May be its 2GB flash.Well, I think I will wait for a while till more information is available.