Sunday, October 24, 2010
Wednesday, October 20, 2010
Has Linux lost the Desktop war?
http://www.techeye.net/software/linuxs-chance-has-gone
http://www.pcworld.com/businesscenter/article/207999/desktop_linux_the_dream_is_dead.html?tk=hp_new
Those are the two interesting links that I came across recently. They make the statement (rather convincingly) that the Linux has lost in the Desktop front. I look at it from a different perspective. I would say that Desktop has lost its place as a PC (personal computer).
Today, we can clearly see that Desktops are rapidly getting replaced with smart phones and MIDs. And, what are the two most interesting players in that domain? Though a subject of argument, Android is surely one of the forerunners for the title. Next, look at the cloud computing. Though in RC stage, Google chrome OS has made generated enough buzz among the tech community. I am sure that with the weight of Google behind these two distributions, Linux will stay close to you though the Desktop might not!
http://www.pcworld.com/businesscenter/article/207999/desktop_linux_the_dream_is_dead.html?tk=hp_new
Those are the two interesting links that I came across recently. They make the statement (rather convincingly) that the Linux has lost in the Desktop front. I look at it from a different perspective. I would say that Desktop has lost its place as a PC (personal computer).
Today, we can clearly see that Desktops are rapidly getting replaced with smart phones and MIDs. And, what are the two most interesting players in that domain? Though a subject of argument, Android is surely one of the forerunners for the title. Next, look at the cloud computing. Though in RC stage, Google chrome OS has made generated enough buzz among the tech community. I am sure that with the weight of Google behind these two distributions, Linux will stay close to you though the Desktop might not!
Thursday, October 7, 2010
http://www.documentfoundation.org
http://www.documentfoundation.org
Its only today I saw this. I am currently downloading this. Good move considering the way Oracle is going now. I am just waiting to see bytecodelangfoundation.org :)
Its only today I saw this. I am currently downloading this. Good move considering the way Oracle is going now. I am just waiting to see bytecodelangfoundation.org :)
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.
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.
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.
Subscribe to:
Posts (Atom)