Marvell India Technology Day (MITD), held on 10th Nov 2009 is Marvell’s first effort in showcasing its might in landscaping in the Consumer Electronics and Communication domain.

In fact, this is the first program organized by Marvell to bring together its design partners and its own technological solutions under one roof. This assumes great significance after its acquisition of XScale Application processor line from Intel, which is immensely popular with design houses and end-customers in India. Intel slowly built customer base in India by conducting Intel Developer Forums and other events where the Embedded Xscale line was given adequate focus and that has proved to be successful. Now its Marvell’s turn take it forward to the next level.

The MITD 2009 had an appropriate tagline “Moving 3G Forward Faster”, given that world’s largest growing mobile phone market India is entering to 3G next year and 3G spectrum auctioning is scheduled in Jan 2010. Though Marvell does not manufacture chips or solutions involving the 3G modems, Marvell brings in other solutions that can enhance the 3G usability scenarios. Technology and Applications using that Technology have to grow in parallel. Just growing the technology alone, without proper Applications (utilizing that Technology), is not going to be fruitful and in fact not feasible beyond a point. Marvell understands this and concentrated on solutions that can enhance the 3G usability.

The first such solution was 3G Mobile Hot Spot reference design. Assume that you are organizing an outdoor management or board meeting, may be in the lawn of the hotel or a on the beach or so and you want to give an Internet access to all the participants. Imagine a small battery-powered handheld device with an integrated or pluggable 3G data modem and a WiFi access point.

Wouldn’t it be great for all the participants to get connected to this access point and get connected to the Internet through 3G backbone? Marvell displayed such reference design that costs USD99 (not sure of the volumes) excluding the 3G modem. Marvell also showcased a product that is already in the market using Marvell’s wireless chipset. The Marvell Mobile Hotspot (MMH, as they call) is basically a low-power, standard 802.11 Access Point implemented on a chip. They claim that this firmware based Access Point is requires 75% less MIPS, 50% less memory (from the host) compared to the SoftAP implementation.

According to Marvell, The SoftAP implementation relies on the host PC performing the AP functionality, while MMH implements the AP functionality in firmware. The MMH does have a limitation that up to 8 stations can be connected to it, beyond which the throughput drops below usability level. Large OEMs and even cell phone manufacturers can make use of this MMH for their products. Imagine Nokia or Samsung releases a 3G mobile with Access Point, using this MMH technology and that enables you to set up a make-shift wireless network on-the-go in minutes!!! Who knows that may be in the offing pretty soon. And Marvell prefers working closely with the very few large volume tier-1 customers rather working with a large number of mixed volume customers.

Marvell also demonstrated the single chip 802.11n solutions, which attracted us a lot. We, at e-con, use their hugely popular 88W8688 and 88W8686 WiFi/BT chipsets in our solutions. As a logical step, we were quite interested in their 802.11n solutions. Marvell offers 88W8786, a single-chip 802.11n 1×1 device capable of PHY rates and data rates of up to 150Mbps. Marvell claims that these chips are highly integrated, low power and low cost, in fact the price point is so attractive to upgrade the 802.11a/b/g installations to 802.11n. Marvell also demonstrated HD video streaming using their 802.11n chipset and also internet radio streaming over the Bluetooth co-existing. The 802.11n 3×3 solution (88W8366) supports 3 spatial streams with a 450Mbps PHY rate for best-in-class coverage. The 88W8366, an 802.11n 3×3 solution, enables high speed connectivity for rich multimedia experience. Marvell declared that solutions are production ready and supported with Linux drivers.

Another area Marvell concentrated was on the Plug computing using its GHz class Sheeva processors.  This Plug technology enables high-performance, in fact PC-class performance, always-on, always-connected, environment friendly computing readily available. The PC class performance from ARM core has been the buzzword of late, with TI OMAP35x and Freescale i.MX51 and Qualcomm SnapDragon, all eyeing for a bigger chunk in the Netbook business, dominated by Intel Atom. Marvell did not take that direct approach to that fiercely-competed Netbook market, rather combined the GHz Marvell Sheeva core with its Gigabit Ethernet technology at the power consumption of about 2watts to target a home computing market.

Marvell demonstrated the QDEO scaling technology and its application on Onida’s flat panel displays. The QDEO technology (which I believe, came to Marvell, as part of this acquisition of National Display Technology group) scales up incoming YouTube video (of much smaller resolution) to 1080p Full HD (1920×1080) resolution without any blocking artifacts. The QDEO technology takes advantage of some of the image/video properties of that particular frame, such as the dominant color in that frame,  etc., to make such a smooth scaling without visible blocks in the video. Marvell also demonstrated the Blyray player solutions and other optical reader solutions.

Another area of particular interest was ARMADA product line (that includes the PXA168 Aspen and Dove series of Application Processors) that is supposed to be the next successors of PXA3xx and PXA270 Applications Processors that Marvell acquired from Intel. E-con’s interest towards the PXA168 (codenamed Aspen) was very high during the Feb of this year (Feb 2009) when e-con wanted to design CPU modules based on PXA168 Aspen CPUs. Actually that was the time, when news about Aspen started reaching the media and everyone was excited about it. Originally designed for Digital Photo Frames, now, Marvell touts this as a general purpose Application Processor, as the Digital Photo Frame market burst this year after a rapid growth phase till the end of 2008. In fact Marvell developed on Digital Photo Frame Reference design called Teton based on PXA168 Aspen and also an Aspenite board (similar to Zylonite). Marvell told that the PXA168 Aspen chips shall be available for customers by Q1 of 2010.

Now Marvell supports and supplies the PXA168 chips only to tier-1 customers and they expect the software BSP/drivers to be ready for release to other customers by the end of Q1 2010. Marvell displayed the DPF reference design that can be used as Embedded Control Panel with full-fledged browser, multi-format video playback, eReader capability using EPD panels, Adobe Flash playback and rich GUI.

The only Intel product line that Marvell displayed was PXA900 series of Cellphone processors. Marvell particularly chose not to display PXQ270, PXA300, PXA310 or PXA320 CPUs on MITD, as they are originally from Intel and the only series from Intel that was displayed is PXA9xx. Marvell displayed TD-SCDMA mobile handset based on PXA920 for China Mobile and a 3G modem reference design based on PXA910.

On the whole, Marvell demonstrated its solutions that can move forward the 3G faster. Marvell also used this event to showcase its connectivity and Consumer Electronics solutions such as Qdeo processing solutions, Bluray Player using HD media processor SoC, etc. The Application Processors is an area where Marvell is concentrating a lot, but the results are yet to be seen!

3G Mobile · Intel Xscale · PXAx Processors · reference design · Windows CE · Windows Mobile

There are certain use cases – we may have to handle the non-standard custom interface to communicate between the processor and the hardware. An example is controlling the brightness of an LCD. The brightness controller is interfaced with the processor in a single GPIO pin. Communication will happen by just toggling the GPIO at a constant rate through software driver.

Since Windows CE is a multi-threading OS, task switching will happen between multiple threads. This task switching may prevent your driver to maintain the constant rate of GPIO toggling. This leads to malfunction.

How to manage this malfunction?

Windows CE supports real time task handling and this can be achieved by assigning the thread priority to high. If we need to have a real time task in Windows CE, then the thread priority has to be between 0 and 96. The function CeSetThreadPriority () is used to set the required thread priority.

Recently, we had to handle one such use case. We were interfacing a new LCD to our Regulus platform and we were developing the driver for LCD brightness control. Whenever we increase or decrease the brightness, we increased the thread priority of the function that was performing the control operation, to the highest and save the previous priority to restore back after finishing the task in the driver, but still the task switching was happening because of the existence of same  higher priority threads or the time slice got over.  Since  the task was getting switched, when the user controls the brightness from the control panel, there is a delay in the effect taking place making it very odd.   So we have to avoid the task switching and make the driver thread to complete the operation without interruptions.

Windows CE provides one more API to control the thread quantum.  CeSetThreadQuantum() is the API that will control the thread running time. Passing zero to this function will run the thread completely without interruption.  . In this case the driver task was completed without interruption.  After completion of  the task, the thread priority and the quantum was set to previous values. This allows the other processes to execute normally.

NOTE: This may not work out to generate higher clock speed for some device through software.

Windows CE · Windows CE BSP · Windows Mobile

Real Time Clock or RTC is an essential component in all embedded systems. Though all the modern day CPUs have inbuilt RTC, designers are comfortable with external RTC for some specific reasons such as to reduce the power burden, RTC alarms to wake-up the CPU etc. The power consumption of external RTC devices are extremely low and some of them offer additional battery-backed SRAM with tamper-detection etc. Designers interface these RTC chips through a common I2C bus shared by a lot of peripherals and sensors. Therefore a common I2C bus driver is needed to the developers.

Since an I2C interface is a shared bus, synchronization is needed between the devices to access the I2C bus. Windows CE supports synchronization objects like critical sections, semaphore and mutex etc.., to share the device or bus in driver level without conflict. But RTC related functionalities are implemented in the OAL.exe. Therefore it is not possible to use synchronization objects in the OAL part. This blog depicts – how to share I2C bus between OAL and driver without conflict.

RTC related OAL functions
Following functions are RTC related OAL functions.

a) BOOL OEMSetAlarmTime (LPSYSTEMTIME lpst );
b) BOOL OEMSetRealTime (LPSYSTEMTIME lpst);
c) BOOL OEMGetRealTime(LPSYSTEMTIME lpst);
d) Calling KernelIoControl with the IOCTL_HAL_INIT_RTC as a parameter.

These functions are called from the windows CE standard time functions. IOCTL_HAL_INIT_RTC resets the real-time clock by calling the OEMSetRealTime function during the booting. OEM is responsible for filling the stub inside these functions.

I2C Driver
I2C driver is a windows CE stream driver. Since the I2C bus is shared by the devices like camera sensor, temperature sensor, battery fuel gauge, Ambient light sensor etc. Therefore I2C bus driver is implemented with synchronization objects. For example, critical section is suitable for this case. This I2C driver will be utilized by other peripheral drivers. These techniques shall be effective to avoid races within the I2C driver. But the same I2C controller is shared between the OAL RTC code and the I2C driver code. This poses a different challenge.

Issue
Same I2C controller is shared between the OAL RTC and other peripheral drivers. Unfortunately, it is not possible to use synchronization objects between the OAL and the device drivers. Because “OAL.exe” is part of the Windows CE kernel. Device drivers are running on the top of the kernel. In order to synchronize the I2C bus access between OAL and driver, we need to maintain a sharable lock between these areas. The sharable lock can be achieved using the reserved memory region named DRVGLOB.

Solution
We can reserve a memory region with the known address in the config.bib file. A structure of sharable data between the OAL and the drivers can be maintained in the DRVGLOB reserved region. The following is the example of a config.bib that contains the DRVGLOB reserved region.

EBOOT                80000000               00100000           RESERVED
NK                        80100000               01F00000            RAMIMAGE
RAM                    82000000               0DF00000           RAM ;233MB
KITLUSB20      8FF00000               00010000            RESERVED ;For USB2.0 RNDIS Kitl DMA Buffer
LCDBOOTFRM 8FF10000                000D0000           RESERVED ;LCD FRAME BUFFER on EBOOT
DRVGLOB      8FFE0000            00010000           RESERVED ;Driver Globals

The following is a sample structure of DRVGLOB and it is declared in the DRVGLOB.H header file.

#ifndef __DRVGLOB_H
#define __DRVGLOB_H
typedef struct {
UINT32 Timeout; // RTCTime
UINT32 TouchWakeup; // Optional Wake up Source
.
.
.
UINT32 bI2CBusy; //Lock logic for sharing the I2C bus between OAL and Driver.
} DRV_GLOB, *P_DRV_GLOB;

#define DRVGLOB_BASE 0×8FFE0000
#define DRVGLOB_SIZE 0×10000

#endif

“bI2CBusy” is the variable used for maintaining the synchronization between the OAL and I2CDriver. We can access this reserved region in both the OAL and the driver. Following code snippet explains – how to access the structure in OAL and driver.

• Initializing the DRVGLOB structure in OAL
volatile DRV_GLOB* g_DrvGlob;

g_DrvGlob = (volatile DRV_GLOB*) OALPAtoVA(DRVGLOB_BASE, FALSE);
if ( !g_DrvGlob )
{
RETAILMSG(1, (_T(“RTC::DRVGLOB Mem Alloc Failedrn”)));
return FALSE;
}

• Initializing the DRVGLOB structure in I2C Driver
volatile DRV_GLOB* g_DrvGlob;
PHYSICAL_ADDRESS Drv_Glop_Base = {DRVGLOB_BASE};
g_DrvGlob = (volatile DRV_GLOB*) MmMapIoSpace(Drv_Glop_Base, sizeof(DRV_GLOB), FALSE);
if ( !g_DrvGlob )
{
RETAILMSG(1, (_T(“I2C::DRVGLOB Mem Alloc Failedrn”), GetLastError()));
return FALSE;
}
• Synchronizing OAL RTC lib and I2C Driver

Following procedure explains the implementation.

I2C Read/Write Function in OAL RTC

a) Check I2C is busy with I2C driver. You can add some timeout, instead of waiting infinitely to avoid accidental hanging. If it is busy, wait in the loop until the bus is free. Following code snippet explains this.

while (g_DrvGlob->bI2CBusy)
{
Millisecond Delay function with 1 ms delay.
}
b) If it is free set the “bI2CBusy” as 1 to make it busy.

g_DrvGlob->bI2CBusy = 1;

c) Perform I2C bus access.

//I2C Read or Write operations
.
.
d) Clear the “bI2CBusy” to assure that the bus access is finished.

g_DrvGlob->bI2CBusy = 0;

I2C Read/Write Function in Driver

a) Enter Critical section to deny other peripheral driver accessing the I2C driver.

b) Check I2C is busy with OAL RTC. You can add some timeout, instead of waiting infinitely to avoid accidental hanging. If it is busy wait, in the loop until the bus is free. Following code snippet explains this.

while (g_DrvGlob->bI2CBusy)
{
Millisecond Delay function with 1 ms delay.
}
c) If it is free set the “bI2CBusy” as 1 to make it busy.

g_DrvGlob->bI2CBusy = 1;

d) Perform I2C bus access.

//I2C Read or Write operations
.
.
e) Clear the “bI2CBusy” to assure that the bus access is finished.

g_DrvGlob->bI2CBusy = 0;

f) Exit Critical section to allow other peripheral driver to access the I2C bus.

In this way, we can share the I2C bus with OAL part and the driver part.

Windows CE · Windows CE I2C Driver · Windows CE OAL · Windows Mobile