Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

NAND Flash drive in CE 6.0

17 views
Skip to first unread message

B-Dawg

unread,
May 27, 2009, 4:15:01 AM5/27/09
to
I have a Samsung SMDK2440 based system with 64MB of RAM and 64MB of NAND
Flash. I have a smartmedia driver that formats the NAND space not used by
the OS into a flash partition. This works OK and I can put files onto it etc.

However, when creating the partition it overwrites the bootloader that is
also situated in the NAND flash so that the device will not boot the second
time. The bootloader is not part of the CE OS and so CE will not know about
it and therefore I presume does not protect those sectors. If I reflash the
bootloader back on the OS is then able to start up and is not corrupted but
the new partition that I had created is gone. This is what leaves me to
believe the NAND storage partition and the bootloader are occupying the same
sectors somewhere on the NAND.

Can someone point me in the right direction about how to resolve this? Do I
put a reserved entry into Config.bib, or do I need to code this into my
driver? Any help would be appreciated.

harry

unread,
May 28, 2009, 1:29:51 AM5/28/09
to
Hi,

I assume that you are using FAL-FMD (FTL) structure to use your NAND.

The Blocks for the Boot-loaders are needed to be reserved, so as no
other application can Write or Erase these blocks.
However it looks like that Blocks where Boot-loader resides are not
reserved hence OS image is getting written onto it.

You can verify the EBOOT, which is responsible for writing the OS
image onto the Flash.
EBOOT should check that it is not writing or erasing any reserved
block.

Kindly furnish the FTL details so as you can get the precise
answer. :)

Regards,
Harsh

B-Dawg

unread,
May 28, 2009, 2:31:01 AM5/28/09
to
Hi,

I am using the FAL-FMD structure for my NAND driver. Do you want more info
about it / source code etc?

I am not using EBOOT or any part of the CE OS as my bootloader. I am using
a bootloader called Vivi. The nk.nb0 OS image itself is not being written
over the bootloader it is just the flash drive partition that I make using
Storage Manager in CE 6 Explorer, Control Panel on which I want to store my
files.

Bevan

Andrew at Plextek (www.plextek.co.uk)

unread,
May 28, 2009, 4:53:50 AM5/28/09
to
Bevan,

When the OS mounts the flash filing system, it will attempt to format
the NAND Flash if you have the auto-format option enabled in the
registry. When it formats the Flash for the first time it will erase
all blocks that it finds, providing that they are not marked as bad,
or marked as reserved.

Blocks are marked as bad by the manufacturer of the NAND part. These
markers are located in the "spare" area of one (or more) of the NAND
flash pages in the block. Unfortunately, how this is done varies
between manufacturer and the page size of the NAND part. What the MS
code expects is that Byte offset 5 in the spare area is used as the
bad block mark (which is where many manufacturers put their bad block
marks).

In fact, the MS code overlays a structure called "SectorInfo" into the
spare area of each page of the NAND (a page is synonimous with a
sector). This can be found in PUBLIC\COMMON\OAK\INC\FMD.H. As well as
defining byte offset 5 as bBadBlock, it defines byte offset 4 as
bOEMReserved. If this byte is zero, then the Flash filing system will
detect the page as reserved and will skip over it.

So, to protect your bootloader from being erased, you need to ensure
that when the bootloader is written into the NAND, that byte offset 4
in the spare area of the NAND is programmed as zero. (There may be
other tricks to make this work fully, but this is the gist of it.)

Another way of doing this which doesn't involve modifying the spare
area is to add a shim driver (or hook) into the FMD which does a
simple block number translation, so that when the MS upper layers of
the driver call for sector 0, your shim adds an offset (sufficient to
protect the bootloader) before calling the lower layer. You will need
to override FMDHOOK_GetInfo, FMDHOOK_GetBlockStatus,
FMDHOOK_SetBlockStatus, FMDHOOK_ReadSector, FMDHOOK_WriteSector,
FMDHOOK_EraseBlock, FMDHOOK_OEMIoControl(IOCTL_FMD_LOCK_BLOCKS). The
GetInfo function will have to read the flash info from the lower
layer, and reduce the reported size of the NAND device by the size of
the bootloader. Example shim drivers for the FMD are in PUBLIC\COMMON
\OAK\DRIVERS\BLOCK\MSFLASHFMD\HOOK.

Good luck,
Andrew.

> > > driver?  Any help would be appreciated.- Hide quoted text -
>
> - Show quoted text -

B-Dawg

unread,
Jun 1, 2009, 8:37:01 PM6/1/09
to
Does no one out there no anything about CE Flash partitions?
...................

Bradley Remedios

unread,
Jun 2, 2009, 1:11:01 PM6/2/09
to
On Jun 1, 5:37 pm, B-Dawg <BD...@discussions.microsoft.com> wrote:
> Does no one out there no anything about CE Flash partitions?

Both Harsh and Andrew have told you what is most likely wrong. No one
likely responded after Andrew's post because he told you exactly what
you need to do to verify your reserved block settings (as Harsh
mentioned earlier you should check.)

There is likely two (2) likely culprits that you need to confirm are
not the problem before going any further. That your Reserved Blocks
are correct and that your actual layout is not the problem. There is
nothing that anyone can do to help you until your check those.

I would say that more likely than not you have a problem in your
Reserved Blocks and I would concentrate on that first.

Regards,
Brad.

B-Dawg

unread,
Jun 2, 2009, 5:52:01 PM6/2/09
to
Hi Bradlry,

Thanks for your reply. But I want to say that Harsh's reply didn't really
have anything to answer my question and there is no reply by anyone called
Andrew to my thread. Where is these posts? In my list Harsh only replied
once in a very general way asking for more info.... Is there a reason these
other replies you say are there are hidden from me? Perhaps you can copy
them into your next reply to me.

So this hasn't left me anything yet to go by. When you say reserved blocks
are you meaning in Config.bib?

Bradley Remedios

unread,
Jun 2, 2009, 6:40:54 PM6/2/09
to
On Jun 2, 2:52 pm, B-Dawg <BD...@discussions.microsoft.com> wrote:
> Hi Bradlry,
>
> Thanks for your reply.  But I want to say that Harsh's reply didn't really
> have anything to answer my question and there is no reply by anyone called
> Andrew to my thread.  Where is these posts?  In my list Harsh only replied
> once in a very general way asking for more info....  Is there a reason these
> other replies you say are there are hidden from me?  Perhaps you can copy
> them into your next reply to me.
>
> So this hasn't left me anything yet to go by.  When you say reserved blocks
> are you meaning in Config.bib?

I use groups.google.ca to access the newsgroups and andrews post shows
up there so you can always take a look at that interface. A Link is
here:
http://groups.google.com/group/microsoft.public.windowsce.platbuilder/browse_thread/thread/130f36aa03c6ecc8/f67c9593185a0e39#f67c9593185a0e39

To summarize there are basically two ways to do a FAL/FMD driver (that
I am aware of, there could be more)

One method shows the FAL all blocks (including those occupied by non-
FS data such as Kernel and Bootloader (should they be on the same
flash device as your FS)) but marks blocks that the FAL should not
access (and is not allowed to touch) as RESERVED. This is what Harsh
is telling you to check and it has nothing to do with the config.bib
or any other .bib file.

The second method is to re-map the blocks in your FMD driver so that
there are no reserved blocks. In this case Block 0 as reported to the
FAL may not be Block 0 but be say Block XYZ.

To solve this problem you will have to read up and understand how the
FMD/FAL drivers work, andrew gave lots of hints (and a long post) so
please read that, you may have to try an online newsreader or even
check the microsoft interface.

If you look at your FMD_GetInfo function, then look into the functions
it calls you should eventually understand how it is all laid out.

Regards,
Brad.

Bradley Remedios

unread,
Jun 2, 2009, 6:57:03 PM6/2/09
to
Andrew,

I hope you don't mind but your posts don't seem to show up at
discussions.microsoft.com. To help others I am re-posting it in the
hopes that it will show up.

-- Newsgroup post from Andrew at Plextek follows.

From: "Andrew at Plextek (www.plextek.co.uk)" <a...@plextek.com>
Date: May 28, 1:53 am
Subject: NAND Flash drive in CE 6.0
To: microsoft.public.windowsce.platbuilder


Bevan,

When the OS mounts theflashfiling system, it will attempt to format
theNANDFlashif you have the auto-format option enabled in the
registry. When it formats theFlashfor the first time it will erase


all blocks that it finds, providing that they are not marked as bad,
or marked as reserved.

Blocks are marked as bad by the manufacturer of theNANDpart. These


markers are located in the "spare" area of one (or more) of

theNANDflashpages in the block. Unfortunately, how this is done varies
between manufacturer and the page size of theNANDpart. What the MS


code expects is that Byte offset 5 in the spare area is used as the
bad block mark (which is where many manufacturers put their bad block
marks).

In fact, the MS code overlays a structure called "SectorInfo" into the

spare area of each page of theNAND(a page is synonimous with a


sector). This can be found in PUBLIC\COMMON\OAK\INC\FMD.H. As well as
defining byte offset 5 as bBadBlock, it defines byte offset 4 as

bOEMReserved. If this byte is zero, then theFlashfiling system will


detect the page as reserved and will skip over it.

So, to protect your bootloader from being erased, you need to ensure

that when the bootloader is written into theNAND, that byte offset 4
in the spare area of theNANDis programmed as zero. (There may be


other tricks to make this work fully, but this is the gist of it.)

Another way of doing this which doesn't involve modifying the spare
area is to add a shim driver (or hook) into the FMD which does a
simple block number translation, so that when the MS upper layers of
the driver call for sector 0, your shim adds an offset (sufficient to
protect the bootloader) before calling the lower layer. You will need
to override FMDHOOK_GetInfo, FMDHOOK_GetBlockStatus,
FMDHOOK_SetBlockStatus, FMDHOOK_ReadSector, FMDHOOK_WriteSector,
FMDHOOK_EraseBlock, FMDHOOK_OEMIoControl(IOCTL_FMD_LOCK_BLOCKS). The

GetInfo function will have to read theflashinfo from the lower
layer, and reduce the reported size of theNANDdevice by the size of


the bootloader. Example shim drivers for the FMD are in PUBLIC\COMMON
\OAK\DRIVERS\BLOCK\MSFLASHFMD\HOOK.

Good luck,
Andrew.

Michel Verhagen [eMVP]

unread,
Jun 2, 2009, 7:28:37 PM6/2/09
to
Andrew,

You may be blacklisted on the newsserver. I've been blacklisted before
as well. Change your return email address and display name in your
newsreader client.

Good luck,

Michel Verhagen, eMVP
Check out my blog: http://GuruCE.com/blog

GuruCE
Microsoft Embedded Partner
http://GuruCE.com
Consultancy, training and development services.

Andrew at Plextek

unread,
Jun 3, 2009, 5:44:29 AM6/3/09
to
--TESTING--
Thanks for the tip Michael, I've done what you said. I normally post
to the group through Google, and I have with this post, so I'll now go
and check the MS group server to see if it turns up.
Apologies to everyone else for this post.
Bevan, hope you've now got my reply.
Andrew.
--TESTING--

On Jun 3, 12:28 am, "Michel Verhagen [eMVP]"

> >>> Brad.- Hide quoted text -

B-Dawg

unread,
Jun 15, 2009, 8:53:02 PM6/15/09
to
Hi Andrew,

Thanks for your help. I implemented your suggestion of using block number
translation and it works well. I implemented it direcly in the driver
rather than using a hook but the principle is the same. Since I didn't write
the NOR bootloader which is in turn used to write the NAND bootloader I
didn't think I'd have much success trying the other byte offset method.

Thanks again,

Bevan

0 new messages