Powered By Blogger

Ok, so for implementing access to a SD Card from boot loader what all we need to implement? Here goes:
  • SD Card block read, identification routines
  • Routines to identify, validate and read the partition information from MBR
  • Routines to perform the FAT (VFAT) data from card.
If you check out the sources code in U-boot, these functionalities has been divide in to the following modules:
  • pxa_mmc.c (/drivers/mmc/)
  • part.c (/disk/)
  • part_dos.c (/disk)
  • fat.c (fs/fat)
  • file.c (fs/fat)
If you directly take the relevant headers and these source files and compile it along E-Boot, of course, you will end up in lot of error, mostly related to
  • data types
  • use of __attribute__
  • structure and macros which are present in Linux headers
Once the errors have been resolved (of course, I am going to leave it up to you), I first enabled and invoked the SD CARD detection routines, I was able to detect the SD CARD, but seemed to failing in reading the MBR, on dumping it, I observed that some bits are not the same as the actual data on SDCARD. So I posted the same on to U-boot mailing list.


Then I figured out that the GPIO configuration was getting overridden in another place in code. Corrected it and there it was working like a charm.

Now I enabled, the FAT access module, here again I was stumped with another problem, the compilation was happening properly, but the Flash Image (Eboot.Nb0), was not generating properly. I.e., I observed that there was no change in behavior if I flash the image, with new functionality, also the time stamp on the file was not updating for NB0 file after compilation.

If I disable the new code added, the Image generation was happening properly. So there I was stuck again with another strange problem. So I went through the code again. After some pain staking and careful analysis, I noticed on thing, there were some array declarations like the following, through out the code:
__u8 get_vfatname_block[MAX_CLUSTSIZE];
The macro MAX_CLUSTSIZE, was having the value 65536 . So it is creating an array of very huge size.

So why didn't it create a problem in BIN file creation, instead the problem is showing up NB0 file creation? Answer is very simple:
BIN files are something similar to a loader, i.e. they will have a predefined record format, and will a piece of loader code to unpack the same. On the other hand, NB0 or ROM Image files are like how the Program will be present in memory, when it is loaded.

What happened was that, when trying to create spaces for all the arrays that had been declared in code, the NB0 file creation was failing (Although it was not shown as a warning or error while building). The size of Rom Image for boot loader is restricted to 256KBytes in Eboot.bib.

Now to work around this problem, I used the free memory in RAM and changed these arrays to pointers and initialized them to some addresses in RAM. Now, I had the module working , with reading of any content in an SD Card.

Now moving on to USB Client Upgrade implementation, I will explain the things later on in the next post

Sometimes it becomes required to extend the existing boot loader, mostly for implementing functionalities like firmware upgrade over a variety of medium like USB Pen Drive, USB Client or even a Micro SD Card. In most of the cases, the dead lines (of course always it will be like it) will be very close too.

For the current project, which I am working now, I had to implement such an upgrade over USB Client (which would be used in production team) and a Micro SD Card based upgrade(which will be used by the end users) in the Windows CE Boot loader(E-Boot).

Previously I was able to port, DAS U-boot and Embedded Linux on the same hardware. Anyone who had worked on U-boot, will definitely know about the advantages and the amount of features that it exports for working on an embedded system hardware. It had the implementation of SD Card access with FAT file system. Now for getting around with the task of firmware upgrade assigned to me, within the time limit, was to make use of the code present in U-boot for MMC Card read operations.

Now that I had chosen what I had to do, I started the analysis of what needs to be done for porting. These were the major difference that I was able to observe between the two systems - Windows CE Boot loader and U-boot:
  • Compilers used for building both of them were completely different. E-Boot was using Microsoft's Cross compiler for ARM. While U-Boot was using GNU C Compiler. This itself is one of the major bottlenecks as the constructs used in one compiler might not be available in the other one. For instance, __attribute__ which was used a lot in U-Boot, was specific to GCC.
  • The source code of U-Boot was tightly coupled with Linux. The headers that were being used, data structure (for maintaining list etc), were taken from Linux source code.
  • The data types (typedefs mostly), available and used were a lot, for the same unsigned char, there were lot of typedefs like uint8_t, u8. Same goes for other types too.
  • There were intelligent mechanisms using macros in U-Boot through various header files for almost every platforms that were available today. That made writing new source code virtually easy.

Then again the objective of my task was to, integrate the module from U-Boot on to E-Boot.
So how do I achieve this? Will explain the details in next post

Tuesday, September 22, 2009

Windows CE 6.0 R3

Microsoft has announced the release of Windows CE 6.0 R3 in market. The major enhancement is going to be in terms of UI by bringing in native support for Mircosoft Silverlight.

Downloads will be available by 10/2009. So get ready for an upgrade.

I am waiting for the release for giving it a try.

Check the following links for more information
Mircosoft Page

Post about BSquare BSP support for WINCE6.0 R3 in WindowsFordevices.

Monday, July 20, 2009

Social Bookmarking

Guys,

I am putting together a social bookmarking page @ delicious.com. Here I will keep on posting whatever useful information that I will find on Windows CE in internet. Hope it would be useful for you guys :). Here is the link

http://delicious.com/vaisakhps/windowsce

Sunday, June 28, 2009

Porting of a BSP - SDRAM

While working on BSP of Windows CE, we will come across cases when we have to port an existing BSP to another hardware. This hardware may have only minor changes like certain peripherals and reducing and/or increasing of memory. I will explain what needs to be done for some of the scenarios involving porting in the upcoming post.

In thos post, I will explain how to systematically change the software when the SDRAM in a hardware is changed. For example, the original BSP had a 32-bit SDRAM interface. But the new hardware is having a 16-bit interface instead.

Before jumping on to changing the code (as the hardware guys will always say, "you just change this bit, it will work straight away...", no pun intented, because it was always like that in my experience and ended up doing a lot of rework ), you need to prepare somethings before doing that.

If you are having a ICE (In Circuit Emulator), that would be of great help, as you can test and troubleshoot a lot of key aspects involving this change.

Do some ground work before jumping in:
  • Familiarize yourself with the datasheet of the processor which you are using (I have been working on PXA27x on sometime, so will explain based on that).
  • Prepare some assembly level (or C if you are not familair with assembly routines), which you can run on ICE and check the hardware. Especially whether you are able to access the new SDRAM.
  • Run some preliminary tests on the SDRAM like writing certain portions of and verifying it.
  • Scrutinize and tune the SDRAM timing values as they play a very important role in system's performance.


Now lets get on to the practical side. In PXA27x processor, for changing the sdram access from 32-bit to 16-bit and vice-versa can be done by clearing and setting the DWID0 and DWID2 bits in MDCNFG register depending on which bank the SDRAM located.

Once you are through with these steps, you are confidently start the modification involved in OS. Till now what I explained, looks good in theory, but needs a lot of analysis and patience.


While putting together the changes required in the Windows CE BSP, these are the aspects that you need to concentrate on :
  • The memory initialisation for 16-bit interface
  • The oem address table change (if required to change the SDRAM size)
  • Memory parameters in the BIB files (especially config_cebase.bib)
In the mainstone platform the switch to 16-bit mode can be done by setting the macro xlli_SDRAM_16BIT. Check the related code in WINCE600\PLATFORM\COMMON\SRC\SOC\PXA27X_MS_V1\XLLP\SOURCE\xlli_lowlev_init.s.

In config_cebase.bib, change the memory size considering the new ranges and change the address mapping in oemaddrtab_cfg.inc.

With these changes, the bootloader and operating system should move into 16-bit SDRAM mode.


Consider any XScale PXA27x BSP based which is based on the Mainstone III platform. Thanks to the Mainstone BSP developers ofcousrse,

Thursday, June 18, 2009

Accessing DrvEscape

In display drivers, DrvEscape is a function to retrieve information from a device that is not available in DDI for example, issuing a DrvEscape to the PXA27X display driver with GETGXINFO parameters will fill in the GAPI data structure.

For accessing the DrvEscape routines, the following code segment can be used:


{
HDC hDC = NULL;
DWORD Status;
CEDEVICE_POWER_STATE pwrState = D0;
hDC = CreateDC(NULL, NULL, NULL, NULL);
if (NULL != hDC)
{
pwrState = D0;
Status= ExtEscape(hDC, IOCTL_POWER_SET,
0, NULL,
sizeof(pwrState), (LPSTR)&pwrState );
ReleaseDC(NULL,hDC);
}
}


This code will open the display driver and will issue a IOCTL_POWER_SET command to make the display ON. In the PXA27X display driver, uses two display buffers, one for the filling in of graphic data, another a blank buffer , which will be used during D2 to D4 modes.

So if the display driver is in D2-D4 mode, this DrvEscape will bring the driver into D0. This will be equivalent of using SetDevicePower, but Microsoft is not recommending the usage of such APIs as it restricts the device self-management.

For checking whether the bluetooth stack is up and initialised, you can make use of the manual reset event BTH_NAMEDEVENT_STACK_INITED (L"system/events/bluetooth/StackInitialized").

You can get more information on this page.

If you are experiencing system performance issues in ROM based File systems, here is a nice tweak to boost up the performance. Most of the times, this slowdown will be due to constant registry flushing in to ROM in background.

[HKEY_LOCAL_MACHINE\init\BootVars]
"RegistryFlags"=dword:2
If this variable is set to 1, it will enable aggressive flushing of registry on to ROM. Setting it to 2 will disable background flushing and can improve performance of system significantly.

Reference: http://msdn.microsoft.com/en-us/library/aa914382.aspx

In one of my previous posts, I mentioned about cloning OALIOCTL, was thinking of writing about it. But Bruce have already written about. And it was my reference too. So check it out

It is assumed that , the OAL code is cloned to the BSP under development, including the ioctl code. For the purpose of explaining the process, the Mainstone III reference platform will be used.

The BSP specific, ioctl will be located under the directory, MAINSTONEIII\SRC\OAL\OALLIB\ioctl.c.

Now lets assume that we need to implement an ioctl to flag the backing up of system alarm setting during shutdown.

  • Define a new function in ioctl.c as:
BOOL OALIoCtlHalAlarmSet
( UINT32 code, VOID *pInpBuffer,
UINT32 inpSize, VOID *pOutBuffer,
UINT32 outSize, UINT32 *pOutSize)
{
g_oalIoCtlUserAlarmSet = TRUE;
return(TRUE);
}

  • Define a macro for the new IOCTL.
#define FILE_DEVICE_CUST_OEM   32806

#define IOCTL_DDK_SET_ALARM_FLAG \
CTL_CODE(FILE_DEVICE_CUST_OEM, 0x0100, METHOD_BUFFERED, FILE_ANY_ACCESS)
  • Modify g_oalIoCtlTable variable in ioctl.c to add the new ioctl mapping:
const OAL_IOCTL_HANDLER g_oalIoCtlTable[] = {
.....
{
IOCTL_DDK_SET_ALARM_FLAG,
0,
OALIoCtlHalAlarmSet
},
#include
.....
}

Now we have a kernel ioctl, which can be invoked from any section coming under kernel address space. For making this IOCTL accessible from User space, we need to customise (clone) OALIOCTL, which will be described in another post in detail

On resuming from sleep mode of PXA27X, the usb client wont be working straight away. No insertion events will be detected and the device will be shown as an uknown device in PC.

For overcoming this situation, we have to clear the OTGPH bit in PSSR (Power Manager Sleep Status Register). This is a write to clear bit.

OTGPH will be set when entering sleep mode when writing the PWRMODE register and indicates that the OTG pad is retaining state. So after resuming, the USB OTG, UDC and UHC should be configured, then only clear the OTGPH bit.

Referece : Marvell PXA27X Processor Developer Manual, November 3 , 2006

For monitoring events for a network interface, the notification request ioctl IOCTL_NDISUIO_REQUEST_NOTIFICATION in NDISUIO driver can be used.

By using this Notification mechanism, we can capture events for each network interface in Windows CE such as

  • Bind
  • Unbind
  • Power Up
  • Power down
  • etc...
A sample implementation is provided in the NDISPWR driver in PUBLIC code
(WINCE600\PUBLIC\COMMON\OAK\DRIVERS\NETSAMP\NDISPWR)

Sunday, June 7, 2009

Keeping system alive

In power manager, the PDD has a certain set of events that it monitors. For eg:

  • PM_BOOTPHASE2_EVENT
  • PM_SYSTEM_API_EVENT etc
For more information on events each PDD handles, check the Power manager code available in PUBLIC code (WINCE600\PUBLIC\COMMON\OAK\DRIVERS\PM\PDD).

In those events there is event PM_SYSTEM_TIMEIDLE_RESET (PowerManager/SystemIdleTimerReset), which can used to reset the system activity timer. Check out the following piece of code for doing so.


HANDLE hSysTmrReset = CreateEvent(NULL, FALSE, FALSE, _T("PowerManager/SystemIdleTimerReset"));
BOOL bExit = FALSE;
if (INVALID_HANDLE_VALUE != hSysTmrReset )
{
while (FALSE == bExit)
{
ResetEvent(hSysTmrReset);
Sleep(1000);
SetEvent(hSysTmrReset);

RETAILMSG(TRUE, (TEXT("Reset\r\n")));
Sleep(20000);
}
CloseHandle (hSysTmrReset );
}
return 0;

This system, code will keep the system alive by resetting the timer every 20 seconds. I have tested this code and seems to be working. But needs to analyze the system performance on doing so.

Wednesday, June 3, 2009

Enabling agressive scanning for Wifi

To enable aggressive scanning for wifi network (preferred or non-preferred ones) in Wireless Zero Configuration in Windows CE, use this registry setting:

[HKEY_LOCAL_MACHINE\Comm\WiFi]
ScanInterval: dword:5
This will set WZC to scan for network every 5 seconds. By default, it is set to 60 seconds. Try tuning this value as per your requirement.

Thursday, April 23, 2009

Creating Cab Files

I found a really cool utility for creating CAB files for a windows ce device - Quick Cab.
Check it out.

http://forum.xda-developers.com/showthread.php?t=400221

Wednesday, April 15, 2009

War of the worlds

Guys check out the heated arguement in this post :)

http://blogs.msdn.com/mikehall/archive/2005/01/13/352470.aspx

Wednesday, April 8, 2009

Keyboard Hooking in Windows CE 6.0

If you want to monitor system wide keyboard events from an application, then we need to use keyboard hooking using the SetWindowsHookEx & UnhookWindowsHookEx functions. Since we need a system wide hook, we need to place the callback functions in a DLL.




typedef struct {
DWORD vkCode;
DWORD scanCode;
DWORD flags;
DWORD time;
ULONG_PTR dwExtraInfo;
} KBDLLHOOKSTRUCT, *PKBDLLHOOKSTRUCT;
.....

VOID InitHook ()
{
.....
SetWindowsHookEx(WH_KEYBOARD_LL,hookproc,hinstance,NULL);
.....
}
....
HOOKDLL_API LRESULT CALLBACK hookproc(int ncode,WPARAM wparam,LPARAM lparam)
{
UINT uMsg = 0;
if(ncode>=0)
{
if((lparam & 0x80000000) == 0x00000000)//Check whether key was pressed(not released).
{
switch((((KBDLLHOOKSTRUCT*)lparam)->vkCode))
{
case VK_F1:
RETAILMSG(1,(TEXT("TRAPPED, F1\r\n")));
uMsg = WM_USER+755;
break;

case VK_F2:
RETAILMSG(1,(TEXT("TRAPPED, F2\r\n")));
uMsg = WM_USER+756;
break;

case VK_F3:
RETAILMSG(1,(TEXT("TRAPPED, F3\r\n")));
uMsg = WM_USER+757;
break;

case VK_F4:
RETAILMSG(1,(TEXT("TRAPPED, F4\r\n")));
uMsg = WM_USER+758;
break;
}

}
}
return ( CallNextHookEx(hook,ncode,wparam,lparam) );//pass control to next hook in the hook chain.
}


But in Wince 6.0, these APIs have been removed, but is still present in coredll. Hence, they can be accessed using LoadLibrary and GetProcAddress functions.


N.B: Special Thanks Prathamesh S Kulkarni on his article on keyboard hooking in code project.

Hi :)
First of all sorry guys, for the leave of absence, I have been busy lately.

In one of the tasks assigned for me, I had to bring the system back in to ON mode from idle, when any bluetooth activity happens. Activity in the sense, authentication request or a file transfer start etc.

File transfer or any other requests (except for pin request), can be tackled my monitoring the bluetooth stack events. But an authentication request cannot be obtained using the same. The the authentication ui for bluetooth is located in

WINCE600\PUBLIC\COMMON\OAK\DRIVERS\BLUETOOTH\SAMPLE\BTSVC

Its a service (BTSVC), and can modified directly or cloned By AuthenticationDlgProc and the corresponding dialog in the resource file, we can easily modify the behaviour during a bluetooth authentication request. Or a new application can be provided with the same functionality, do doing so , this service must be removed first as only one type of authentication ui will be allowed at a time.

Wednesday, February 25, 2009

Monitoring for bluetooth events

Here is a sample code for monitoring incoming connection and authentication requests on a microsoft bluetooth stack:



DWORD BTActivityMonitor ( LPVOID lpParam )
{
MSGQUEUEOPTIONS mqOptions;
memset (&mqOptions, 0, sizeof(mqOptions));

mqOptions.dwFlags = 0;
mqOptions.dwSize = sizeof(mqOptions);
mqOptions.dwMaxMessages = 10;
mqOptions.cbMaxMessage = sizeof(BTEVENT);
mqOptions.bReadAccess = TRUE;

// Create message queue to receive BT events on
HANDLE hMsgQ = CreateMsgQueue(NULL, &mqOptions);
if (! hMsgQ) {
wprintf(L"Error creating message queue.\r\n");
goto exit_bt;
}

// Listen for all Bluetooth notifi cations
HANDLE hBTNotif = RequestBluetoothNotifications(
BTE_CLASS_CONNECTIONS | BTE_CLASS_DEVICE | BTE_CLASS_PAIRING,
hMsgQ);
if (! hBTNotif) {
wprintf(L"Error in call to RequestBluetoothNotifications.\r\n");
goto exit_bt;
}

wprintf(L"Waiting for Bluetooth notifications...\r\n");

while (FALSE == bStop) {
DWORD dwWait = WaitForSingleObject (hMsgQ, INFINITE);
if (WAIT_OBJECT_0 == dwWait) {
//
// We have got a Bluetooth event!
//

BTEVENT btEvent;
DWORD dwFlags = 0;
DWORD dwBytesRead = 0;

BOOL fRet = ReadMsgQueue (hMsgQ, &btEvent, sizeof(BTEVENT), &dwBytesRead, 10, &dwFlags);
if (! fRet) {
wprintf(L"Error - Failed to read message from queue!\r\n");
goto exit_bt;
} else {
wprintf(L"----------------------------------------\r\n");
wprintf(L"Got event with id=%d.\r\n", btEvent.dwEventId);
}
} else {
wprintf(L"Error - Unexpected return value from WaitForSingleObject!\r\n");
goto exit_bt;
}

}


exit_bt:
// Stop listening for Bluetooth notifications
if (hBTNotif && (! StopBluetoothNotifications(hBTNotif))) {
wprintf(L"Warning! StopBluetoothNotifications returned FALSE.\r\n");
}

if (hMsgQ) {
CloseMsgQueue(hMsgQ);
}

return 0;
}

Tuesday, January 6, 2009

Cloning Public Code

Here is a nice article by Bruce Eitman for cloning public code

https://geekswithblogs.net/BruceEitman/archive/2008/07/02/platform-builder-clone-public-code.aspx