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:
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,
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,
1 comments:
Hi Vaisakh,
we have a problem with wince6.0 for our i.mx233 cpuboard.
We are trying to download the OS image through USB Serial KITL from
Ethernet boot loader ( where boot loader is loading from NAND flash) it's
hanging in UfnPdd_Start( ) function in pdd.c file.
It's not hanging when we download the Ethernet bootloader directly into
SDRAM from Platfrom builder, and downloaded the OS image.
Below is the comment line in the serial_dl.cpp file before calling
UfnPdd_Start( ) callback fucntion.
// Give time for host to recognize device
// Sometimes we can hang without this delay
// msWait(1);
Target details:
i.MX233 CPU board with Micron 64MB DDR1, Micron 2Gb NAND flash
Post a Comment