caolina1128

引用 39 楼 flyalice 的回复:
建议你研究一下微软的源码，从WINCE500\private\winceos\coreos\storage\storemgr中的Storemain.cpp里的InitStorageManager开始看起，跟踪整个流程，你就会清楚BinFS以及FAT文件系统的建立流程以及文件系统和分区驱动、块设备驱动之间的关系。

你也没有休息啊。谢谢

我前几天看了，不过还搞不懂流程。搞定SD卡先，然后花半个月看文件系统。到时候wince就会越来越顺了。

kjpioo

好帖!

luyongcai

SDI Response Register 0 (SDIRSP0)
Register Address R/W Description Reset Value
SDIRSP0 0x5A000014 R SDI response register 0 0x0
SDIRSP0 Bit Description Initial Value
Response0 [31:0] Card status[31:0](short), card status[127:96](long) 0x00000000

----2440的数据手册不够详尽啊。充其量是个寄存器地址表达表。有些东西说的不清不楚。唉，害惨我了。

syfl88

http://topic.eeworld.net/u/20080715/11/699a5dd0-5076-4db6-a85e-a8b233112352.html?seed=1042151893---------这个帖子和这个有点关系大家可以来看看。最近shuiyan牛人都不来了。哈哈。项目忙吧，有半个月没有见到他了。

cjp0604

http://topic.eeworld.net/u/20080704/09/5A59B7C6-0529-481C-85A7-F1BB3EF9A035.html---------这个帖子也相当不错。唉，继续奋斗！

jinian601

http://topic.eeworld.net/u/20071116/14/A3852A4D-49F9-4BC6-A94E-7C15DC6E1565.html-----wince5如何实现Flash 剩余空间自动分区格式化并加载

一起拿shuiyan牛人发的帖子。看着shuiyan的老帖子，感觉到他的牛人成长历程。

傻砖头

终于完成SD卡的裸机程序了，今天继续。有谁比较了解文件系统的，好想找个人来请教

wangyifei

我在MDOC上实现Binfs根本就没调用Eboot里面的函数去创建分区，而是直接调用MDOC提供的格式化Image分区为FAT格式，然后把标志改成BINFS
以前用2440的时候实现Binfs是用PocketStoreII的代码格式化分区，然后修改BINFS分区的标志的，这样看起来其实只需要把存放Image的分区标志位置成BINFS就OK了，关键部分还是在Image的制作上面。

mukden

引用 47 楼 hzdysymbol 的回复:
我在MDOC上实现Binfs根本就没调用Eboot里面的函数去创建分区，而是直接调用MDOC提供的格式化Image分区为FAT格式，然后把标志改成BINFS
以前用2440的时候实现Binfs是用PocketStoreII的代码格式化分区，然后修改BINFS分区的标志的，这样看起来其实只需要把存放Image的分区标志位置成BINFS就OK了，关键部分还是在Image的制作上面。

----------------这个和优龙的办法相似啊。优龙的BIOS是ADS写的，根本不可能像在eboot下面那样，创建分区。我再仔细看看这些东西。

gundan

其实把Eboot下面的代码拿出来，写个MBR到最前面也是可以的，我们实际也这样使用过
根本的原理就是Binfs起动的时候要去检查Image这个分区的MBR，看它的标志是不是BINFS的
现在Binfs文件系统实现的代码已经全部公开，有兴趣可以仔细研究一下，也可以Debug一下看看，很容易找出问题的所在

010203www

我看到网上的资料说使用FAL+FMD的结构时透过文件系统访问Nand时会先透过FAL层，之后才调用FMD的操作对Nand进行操作。这里有个问题不太明白，对于BINFS来说不需要透过FAL而是直接从Nand上读取，而底层的驱动就只有一个，那么对于BinFS的操作是如何解析的？还是说BINFS直接作为RamImage直接加载到RAM？

yangjie050322

BINFS肯定是要直接加载到RAM的
从代码来看BINFS对Flash的访问有两种方式，一种是驱动支持DSK_IOCTLS＿XXXX的，这会通过Storage来调用驱动的IOCTL接口来读写Flash，我们用的MDOC的驱动就是这样的;另一种是驱动不支持DSK_IOCTLS＿XXXX的，它应该是通过文件系统的API（ReadFile，WriteFile）来实现读写Flash，所以我觉得你们用的FAL＋FMD架构的驱动，BINFS需要透过FAL层来对Flash的读写。

benpao_life

C:\WINCE500\PRIVATE\WINCEOS\COREOS\FSD\BINFS\SRC---------这是BINFS的源码，
这个BINFS也是由文件管理器管理的吧，通过文件系统过滤器。今天好累，明天上班再看了

nddz

WinCE Storage Manager 分析这篇文章不错，哎总算搞懂一些了

zheng_qs

根据文件系统的结构，在文件管理器的最上层是file system filter（文件系统过滤器，作用是识别加载的文件系统类型？），那这部分的代码在哪个地方呢？

wtf

我找了好久也没有找到BINFS+FAT的分界点，
现在最终回到原点

我查到loader.h所在
C:\WINCE500\PLATFORM\smdk2440\INC\loader.h(21):    loader.h   Catfish Boot Loader definitions
C:\WINCE500\PLATFORM\smdk2440\eboot\ether.c(15):#include "loader.h"
C:\WINCE500\PLATFORM\smdk2440\eboot\flash.c(35):#include "loader.h"
C:\WINCE500\PLATFORM\smdk2440\eboot\fmd.cpp(30):#include "loader.h"C:\WINCE500\PLATFORM\smdk2440\eboot\main.c(52):#include "loader.h"
C:\WINCE500\PLATFORM\smdk2440\eboot\usb.c(16):#include "loader.h"

-------------很显然这个BINFS和FAT的分界是在loader.h中完全实现了。这个topic完全只是和驱动相关的东西，我居然跑到上层去找答案，什么文件管理器什么的，奶奶的，其实上层只是弄个接口而已，到最终还不是要靠驱动来实现？！日，真是愚不可及！
-------------不过这个问题是我阴差阳错的看懂了不少注册表以及文件系统的架构，冥冥之中，自有因果。

lijun0209

引用 39 楼 flyalice 的回复:
建议你研究一下微软的源码，从WINCE500\private\winceos\coreos\storage\storemgr中的Storemain.cpp里的InitStorageManager开始看起，跟踪整个流程，你就会清楚BinFS以及FAT文件系统的建立流程以及文件系统和分区驱动、块设备驱动之间的关系。

-------------照着这样看下去，确实有些帮助，但是我看的很迷惑。
=============================================================

文件系统在哪里调用了flash驱动？怎么我搜索这些函数都找不到在哪里调用的？
我估计这些代码微软没有开源 有很多代码你找不到


还有，微软本来自带一套flash驱动，是不是要修改makefile才能去掉它，修改成BSP下的flash驱动？

现在觉得这些微软的不爽了，看到一些代码，一直往下看，突然没有了，唉。

还不是因为爱

还有，微软本来自带一套flash驱动，是不是要修改makefile才能去掉它，修改成BSP下的flash驱动？

Public下面的Flash的驱动拿出来用的话不需要修改makefile的，而是修改Sources文件，基本上只是把lib文件改成DLL文件输出就可以了
而且那些代码基本上可以通过Sysgen来控制编译，微软只不过是把最后的lib文件生成DLL文件放在makefile里去做了

蛋骗鸡

引用 57 楼 hzdysymbol 的回复:
还有，微软本来自带一套flash驱动，是不是要修改makefile才能去掉它，修改成BSP下的flash驱动？

Public下面的Flash的驱动拿出来用的话不需要修改makefile的，而是修改Sources文件，基本上只是把lib文件改成DLL文件输出就可以了
而且那些代码基本上可以通过Sysgen来控制编译，微软只不过是把最后的lib文件生成DLL文件放在makefile里去做了

非常感谢。
---------------我的意思是，存在两个flash驱动，会不会造成冲突？为了只能使用BSP下面的flash驱动，在那里做了设置，请指点。
---------------还有，我发现BSP下面的flash驱动并没有导出那些流接口驱动函数的EDF文件，这是怎么回事，不导出那些流接口函数设备管理器（device.exe）怎么加载这些流接口函数？

-------------这个帖子这么久，差不多该结了。

nibuhao123

songtitan牛人提示了我，就像个晴天霹雳——因为我一直认为BSP下的nand flash驱动是单层的！我按照你的提示，找到了flash块驱动，路径如下C:\WINCE500\PUBLIC\COMMON\OAK\DRIVERS\BLOCK\MSFLASHFMD\FASL，的确，这里导出了以DSK开头的函数的EDF文件，和注册表相吻合。，但是我发现这个文件夹下的FMD.cpp文件并没有DSK开头的函数，这又是怎么回事？反而，这个fmd.cpp里面有FMD_ReadSector等和BSP flash驱动中相同的名字，我真的很迷惑。难道是我找的nand flash块设备驱动不正确。

我以前之所以认为BSP下面的flash驱动是单层的，除了有人说单层的以外，我看里面的函数FMD_ReadSector、FMD_Init完全是是单层驱动的标准写法啊，——我看过串口多层驱动，里面的PDD并不是这么写的。
但是BSP下面的flash驱动又不导出EDF文件，它是怎么加载的？
如果按照你的说法是多层的，那BSP下面的flash驱动是怎么被微软的代码调用的？我使用了PB的find in files功能，并没有找到被调用的地方。
------------------------
这些问题，我看了一周多，不得已才麻烦前辈，希望指点一下子。论坛里面只有你这些少数人才有能力回答这些了。谢谢。