WinCE

Ok, so for implementing access to a SD Card from boot loader what all we need to implement? Here goes:

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

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:

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

While going into low power modes of windows while coming back up, restore the processor and peripherals back to the state it was before.

One problem that we had faced in our project was regarding the restoration of PCCARD timings. Although we were using the original MainstoneIII BSP in Wince6, we had to modify the boot loader and other startup initializations to match the new board which we were designing. On doing so, we commented out the PCCARD timing initializations in xlli_low_level_init.s file.

On PCCARD socket, we had a Wireless LAN card, which was working properly. But after a suspend-resume cycle, the network adapter was shown as down in the drivers. We couldn't figure out what was the reason for this behaviour. Wasted a lot of precious time in debugging the issue. Using a debug version of the driver from vendor, we were able to figure out that after a suspend-resume cycle, the driver was not able to access the card.

So we decided to try a reinitialization of the full PCCARD driver. On trying the pccard and wlan was back up in working state. But the entire driver initialization was slowing down the resuming of the system.

We again analyzed the reinitialization process, then it hit me. I decided to access the pccard attribute memory immediatly after the resuming in OAL. There I came to realize that the problem is way before the OS.

We did a walk though of the Boot loader code, i.e. the path followed during a sleep reset and found out that the section of code for re-initialization of pccard was commented.

Although we fixed the problem, we had to waste a lot of precious project development time in debugging the issue.

So when dealing with low level initializations in bootloader or restoration code, be careful what you are modifying. One way or the other that will come back to haunt you :)