我可以创建可通过 CE 6.0 和我的引导加载程序访问的文件系统吗？
我在 PXA310 上有一个 CE 6.0 项目，我需要能够通过 Wi-Fi 下载操作系统更新 (nk.bin) 并将新操作系统安全地刷新到我的设备。 我愿意接受有关如何执行此操作的其他建议，但我正在考虑将 nk.bin 保存到 NAND 闪存中的文件系统中，然后重新启动并让引导加载程序在文件系统中找到该文件并将其闪存到 BINFS分割。 这可能吗？如果可以，您能给我一个我需要做什么的概要吗？
需要注意的是，这需要非常稳健，因为这些设备是在现场部署的并且不可现场维修。 我需要确保如果操作系统闪存失败（由于电源故障等），引导加载程序可以在重新启动后重试。 这就是为什么我想将下载的图像存储在持久闪存中，以避免重新下载图像。
I have a CE 6.0 project on a PXA310 where I need to be able to download OS updates (nk.bin) via Wi-Fi and safely flash the new OS to my device. I'm open to other suggestions about how to do this, but I'm considering saving the nk.bin to my file system in NAND flash, then restarting and have the bootloader locate the file in the file system and flash it to the BINFS partition. Is this possible, and if so, can you give me an outline of what I'd need to do?
One caveat is that this needs to be very robust since the devices are deployed in the field and are not field serviceable. I need to be sure that if the OS flash fails (due to power failure, etc.) that upon reboot the bootloader can try again. That is why I'd like to store the downloaded image in persistent flash and avoid having to re-download the image.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
从技术上讲，一切皆有可能。 对于此策略，您需要的是引导加载程序的代码，用于将 NAND 闪存安装为驱动器并具有 FAT 驱动程序，以便它可以遍历该文件系统并查找映像。 如果您还没有的话，这将是一项艰巨的工作。
另一种选择是将其存储在文件系统之外的闪存中的已知地址位置。 从引导加载程序的角度来看，这要容易得多，因为您所要做的就是映射到地址并复制。 当然，这使写入更具挑战性，因为您是从操作系统执行此操作，并且在执行写入时必须完全禁用任何其他闪存访问，以防止两个线程同时向芯片发送闪存命令而导致损坏。
无论哪种情况，如果您有空间，最好在其他地方也存储“已知良好”的图像，这样，如果新图像有问题（校验和失败或 x 次加载尝试失败），那么您就会有一个引导加载程序可以回退到的工作操作系统。
Technically just about anything is possible. For this strategy what you would need is code for your bootloader to mount the NAND flash as a drive and have a FAT driver so that it can traverse that file system and find the image. That is a lot of work if you don't already have it.
THe other option is to just store it in flash outside of the file system in a known address location. That's a lot easier from the bootloader perspective as all you have to do is map to the address and copy. Of course it makes the writes more challenging because then you're doing it from the OS and you have to disable any other flash accesses completely while you do your write to prevent corruption by two threads sending flash commands to the chip at the same time.
In either case, if you have the space it's a good idea to store a "known-good" image elsewhere too, so that if the new image has a problem (fails a checksum or x number of load attempts fails) then you have a working OS that the bootloader can fall back to.
显然，很大程度上取决于您的硬件设置，但我们在没有使引导加载程序支持闪存文件系统的情况下完成了这一点。
在我们的产品中，操作系统映像从闪存加载并从 RAM 执行——我认为现在大多数 WinCE 设备都是这样工作的。 因此，为了更新操作系统，我们使用一个特殊的闪存驱动程序，它允许在 WinCE 下运行的应用程序更新闪存中的操作系统块 - 然后您所需要的只是硬重启，引导加载程序将新的闪存映像加载到 RAM 中，以便执行它。 我们发现这在现场非常可靠（对于一些技术不太熟练的最终用户！）。
需要特殊的闪存驱动程序，因为 MS Flash 文件系统驱动程序无法访问闪存的操作系统映像扇区，以防止意外损坏操作系统。
您确实需要将 NK.BIN 加载到操作系统编程应用程序可以读取的内存中，通常是 NAND 闪存，但如果您有足够的 RAM，它可以直接进入文件存储的根目录。 但是，无论哪种方式，您都可以在重新启动之前完成操作系统扇区编程后将其删除，因此这只是临时要求。
Clearly a lot depends on your hardware setup, but we've done this without making the Bootloader support the Flash Filesystem.
In our product, the OS image is loaded from Flash to execute from RAM -- I think most WinCE devices work this way nowadays. So to update the OS we use a special Flash driver which lets an application, running under WinCE, update the OS blocks in the Flash -- then all you need is a hard reboot and the Bootloader loads the new flash image into RAM in order to execute it. We've found this pretty reliable in the field (with some not-very-technical end-users!).
A special Flash driver was needed because the MS Flash Filesystem drivers have no access to the OS image sectors of the Flash, in order to prevent trashing the OS by accident.
You do need to load the NK.BIN into some memory which the OS programming application can read, normally the NAND Flash, but if you had enough RAM it could just go into the root of the filestore. However either way you can delete it when you've finished programming the OS sectors before the reboot so it's only a temporary requirement.