|
Dave Bott(deleted)
|
FAT32 filesystem on NAND ?
|
|
Dave Bott(deleted)
08/13/2009 5:08 PM
post35961
|
FAT32 filesystem on NAND ?
6.4.1 ARMLE
Customer wants to use a FAT filesystem on their NAND chips (on an Atmel ARM board), so that they can plug into a PC as a
USB device for uploads to the PC directly from the filesystem.
They want the FAT filesystem to support ECC and, ideally wear-levelling.
I have explained that it is not power safe and they're fine with that.
I don't think fs-dos can run on NAND, but is that true ?
They also want to boot from the NAND:
"
We have a requirement to boot from the NAND.
From the Atmel datasheet:
"The first block must be guaranteed by the manufacturer. There is no ECC check.
The NVM bootloader program (this is the ROM code running on power up) looks for a boot.bin file in the root
directory of a FAT12/16/32 formatted NVM Flash."
"
I'm guessing we could support this, in theory, by leaving the boot area free, and only running a QNX partition./
filesystem on part of the NAND. So, if there's already a filesystem on the first N blocks of the NAND, we can ignore it
and just run on the rest - is that reasonable ?
Thanks
Dave
|
|
|
|
|
|
David Sarrazin
|
RE: FAT32 filesystem on NAND ?
|
|
David Sarrazin
08/14/2009 10:26 AM
post36011
|
RE: FAT32 filesystem on NAND ?
> -----Original Message-----
> From: Dave Bott [mailto:community-noreply@qnx.com]
> Sent: August 13, 2009 5:08 PM
> To: general-filesystems
> Subject: FAT32 filesystem on NAND ?
>
> 6.4.1 ARMLE
>
> Customer wants to use a FAT filesystem on their NAND chips
> (on an Atmel ARM board), so that they can plug into a PC as a
> USB device for uploads to the PC directly from the filesystem.
Do we need to be able to read/write the FAT filesystem, or is it purely
for the benefit of the PC?
If the PC is mounting it, then the device only needs to provide a block
interface to the raw device, so that a umass-device controller can
access the requested blocks.
>
> They want the FAT filesystem to support ECC and, ideally
> wear-levelling.
> I have explained that it is not power safe and they're fine with that.
>
> I don't think fs-dos can run on NAND, but is that true ?
That's true. We don't have a NAND devb right now (which is required for
io-blk, which is required for fs-dos).
>
> They also want to boot from the NAND:
> "
> We have a requirement to boot from the NAND.
> From the Atmel datasheet:
> "The first block must be guaranteed by the
> manufacturer. There is no ECC check.
That's a standard guarentee from NAND manufacturers.
> The NVM bootloader program (this is the ROM code
> running on power up) looks for a boot.bin file in the root
> directory of a FAT12/16/32 formatted NVM Flash."
> "
>
> I'm guessing we could support this, in theory, by leaving the
> boot area free, and only running a QNX partition./filesystem
> on part of the NAND. So, if there's already a filesystem on
> the first N blocks of the NAND, we can ignore it and just run
> on the rest - is that reasonable ?
Pretty much. All the NAND solutions we've ever done leave a 1:1 area at
the front for boot code, and then start the filesystem some number of
blocks later. It depends on what their bootloader expects for
filesystem positioning, but I would assume the same as you: just put a
small raw area at the front that holds the bootloader, and then format
the rest with FAT.
For a PC to mount this, there's probably going to need to be a partition
table also, since the partition won't be starting at the very first
block.
>
> Thanks
>
> Dave
>
>
>
> _______________________________________________
>
> General
> http://community.qnx.com/sf/go/post35961
>
>
|
|
|
|
|
|
Dave Bott(deleted)
|
RE: FAT32 filesystem on NAND ?
|
|
Dave Bott(deleted)
08/14/2009 10:54 AM
post36013
|
RE: FAT32 filesystem on NAND ?
Thanks for your reply David !
The FAT file system does need to be read/written by QNX Neutrino, to generate the files that can be uploaded to the PC.
So, it sounds like we definitely don't support this today.
Hopefully, it is understood *why* they want to do this - any plans for us to support devb on NAND ?
Lots of devices get plugged in to PCs these days... it's such a convenient thing to do.
Thanks
Dave
________________________________
From: David Sarrazin [mailto:community-noreply@qnx.com]
Sent: Fri 14/08/2009 7:26 AM
To: general-filesystems
Subject: RE: FAT32 filesystem on NAND ?
> -----Original Message-----
> From: Dave Bott [mailto:community-noreply@qnx.com]
> Sent: August 13, 2009 5:08 PM
> To: general-filesystems
> Subject: FAT32 filesystem on NAND ?
>
> 6.4.1 ARMLE
>
> Customer wants to use a FAT filesystem on their NAND chips
> (on an Atmel ARM board), so that they can plug into a PC as a
> USB device for uploads to the PC directly from the filesystem.
Do we need to be able to read/write the FAT filesystem, or is it purely
for the benefit of the PC?
If the PC is mounting it, then the device only needs to provide a block
interface to the raw device, so that a umass-device controller can
access the requested blocks.
>
> They want the FAT filesystem to support ECC and, ideally
> wear-levelling.
> I have explained that it is not power safe and they're fine with that.
>
> I don't think fs-dos can run on NAND, but is that true ?
That's true. We don't have a NAND devb right now (which is required for
io-blk, which is required for fs-dos).
>
> They also want to boot from the NAND:
> "
> We have a requirement to boot from the NAND.
> From the Atmel datasheet:
> "The first block must be guaranteed by the
> manufacturer. There is no ECC check.
That's a standard guarentee from NAND manufacturers.
> The NVM bootloader program (this is the ROM code
> running on power up) looks for a boot.bin file in the root
> directory of a FAT12/16/32 formatted NVM Flash."
> "
>
> I'm guessing we could support this, in theory, by leaving the
> boot area free, and only running a QNX partition./filesystem
> on part of the NAND. So, if there's already a filesystem on
> the first N blocks of the NAND, we can ignore it and just run
> on the rest - is that reasonable ?
Pretty much. All the NAND solutions we've ever done leave a 1:1 area at
the front for boot code, and then start the filesystem some number of
blocks later. It depends on what their bootloader expects for
filesystem positioning, but I would assume the same as you: just put a
small raw area at the front that holds the bootloader, and then format
the rest with FAT.
For a PC to mount this, there's probably going to need to be a partition
table also, since the partition won't be starting at the very first
block.
>
> Thanks
>
> Dave
>
>
>
> _______________________________________________
>
> General
> http://community.qnx.com/sf/go/post35961
>
>
_______________________________________________
General
http://community.qnx.com/sf/go/post36011
|
|
|
|
|
|
Mario Charest
|
RE: FAT32 filesystem on NAND ?
|
|
Mario Charest
08/14/2009 11:15 AM
post36020
|
RE: FAT32 filesystem on NAND ?
> -----Original Message-----
> From: Dave Bott [mailto:community-noreply@qnx.com]
> Sent: Friday, August 14, 2009 10:54 AM
> To: general-filesystems
> Subject: RE: FAT32 filesystem on NAND ?
>
> Thanks for your reply David !
>
> The FAT file system does need to be read/written by QNX Neutrino, to
> generate the files that can be uploaded to the PC.
>
Wouldn't it be somewhat easier to write a Windows application that can read ETFS?
> So, it sounds like we definitely don't support this today.
>
> Hopefully, it is understood *why* they want to do this - any plans for
> us to support devb on NAND ?
> Lots of devices get plugged in to PCs these days... it's such a
> convenient thing to do.
Raw NAND devices are not typically plugged in to PC.
>
> Thanks
>
> Dave
>
> ________________________________
>
> From: David Sarrazin [mailto:community-noreply@qnx.com]
> Sent: Fri 14/08/2009 7:26 AM
> To: general-filesystems
> Subject: RE: FAT32 filesystem on NAND ?
>
>
>
>
>
>
> > -----Original Message-----
> > From: Dave Bott [mailto:community-noreply@qnx.com]
> > Sent: August 13, 2009 5:08 PM
> > To: general-filesystems
> > Subject: FAT32 filesystem on NAND ?
> >
> > 6.4.1 ARMLE
> >
> > Customer wants to use a FAT filesystem on their NAND chips (on an
> > Atmel ARM board), so that they can plug into a PC as a USB device for
> > uploads to the PC directly from the filesystem.
>
> Do we need to be able to read/write the FAT filesystem, or is it purely
> for the benefit of the PC?
> If the PC is mounting it, then the device only needs to provide a block
> interface to the raw device, so that a umass-device controller can
> access the requested blocks.
>
> >
> > They want the FAT filesystem to support ECC and, ideally
> > wear-levelling.
> > I have explained that it is not power safe and they're fine with
> that.
> >
> > I don't think fs-dos can run on NAND, but is that true ?
>
> That's true. We don't have a NAND devb right now (which is required
> for io-blk, which is required for fs-dos).
>
> >
> > They also want to boot from the NAND:
> > "
> > We have a requirement to boot from the NAND.
> > From the Atmel datasheet:
> > "The first block must be guaranteed by the manufacturer.
> There
> > is no ECC check.
>
> That's a standard guarentee from NAND manufacturers.
>
> > The NVM bootloader program (this is the ROM code running on
> > power up) looks for a boot.bin file in the root directory of a
> > FAT12/16/32 formatted NVM Flash."
> > "
> >
> > I'm guessing we could support this, in theory, by leaving the boot
> > area free, and only running a QNX partition./filesystem on part of
> the
> > NAND. So, if there's already a filesystem on the first N blocks of
> > the NAND, we can ignore it and just run on the rest - is that
> > reasonable ?
>
> Pretty much. All the NAND solutions we've ever done leave a 1:1 area
> at the front for boot code, and then start the filesystem some number
> of blocks later. It depends on what their bootloader expects for
> filesystem positioning, but I would assume the same as you: just put a
> small raw area at the front that holds the bootloader, and then format
> the rest with FAT.
>
> For a PC to mount this, there's probably going to need to be a
> partition table also, since the partition won't be starting at the very
> first block.
>
>
>
> >
> > Thanks
> >
> > Dave
> >
> >
> >
> >...
|
|
|
|
|
|
Dave Bott(deleted)
|
RE: FAT32 filesystem on NAND ?
|
|
Dave Bott(deleted)
08/14/2009 11:23 AM
post36022
|
RE: FAT32 filesystem on NAND ?
Hi Mario,
It certainly would be possible to write ETFS for Windows, but then you couldn't plug the device into practically *any*
Windows box without having to install extra software - this customer wants to use a generic approach, which has merit.
You're right that raw NAND chips are not plugged into a PC - no argument here. Their requirement is only a little
unusual; it is quite common to make the filesystem of a device visible over USB. They will have SD or SDHC card(s) (with
FAT), but also want the internal filesystem (the NAND chips) to be visible too.
I think *a* way to go here, assuming (and it's a big assumption) a read-only requirement from Windows, could be to
create an emulation layer, making the ETFS look like a FAT FS. If it's just reading files and directories, that should
be possible. Writing gets a lot more hairy...
Dave
________________________________
From: Mario Charest [mailto:community-noreply@qnx.com]
Sent: Fri 14/08/2009 8:15 AM
To: general-filesystems
Subject: RE: FAT32 filesystem on NAND ?
> -----Original Message-----
> From: Dave Bott [mailto:community-noreply@qnx.com]
> Sent: Friday, August 14, 2009 10:54 AM
> To: general-filesystems
> Subject: RE: FAT32 filesystem on NAND ?
>
> Thanks for your reply David !
>
> The FAT file system does need to be read/written by QNX Neutrino, to
> generate the files that can be uploaded to the PC.
>
Wouldn't it be somewhat easier to write a Windows application that can read ETFS?
> So, it sounds like we definitely don't support this today.
>
> Hopefully, it is understood *why* they want to do this - any plans for
> us to support devb on NAND ?
> Lots of devices get plugged in to PCs these days... it's such a
> convenient thing to do.
Raw NAND devices are not typically plugged in to PC.
>
> Thanks
>
> Dave
>
> ________________________________
>
> From: David Sarrazin [mailto:community-noreply@qnx.com]
> Sent: Fri 14/08/2009 7:26 AM
> To: general-filesystems
> Subject: RE: FAT32 filesystem on NAND ?
>
>
>
>
>
>
> > -----Original Message-----
> > From: Dave Bott [mailto:community-noreply@qnx.com]
> > Sent: August 13, 2009 5:08 PM
> > To: general-filesystems
> > Subject: FAT32 filesystem on NAND ?
> >
> > 6.4.1 ARMLE
> >
> > Customer wants to use a FAT filesystem on their NAND chips (on an
> > Atmel ARM board), so that they can plug into a PC as a USB device for
> > uploads to the PC directly from the filesystem.
>
> Do we need to be able to read/write the FAT filesystem, or is it purely
> for the benefit of the PC?
> If the PC is mounting it, then the device only needs to provide a block
> interface to the raw device, so that a umass-device controller can
> access the requested blocks.
>
> >
> > They want the FAT filesystem to support ECC and, ideally
> > wear-levelling.
> > I have explained that it is not power safe and they're fine with
> that.
> >
> > I don't think fs-dos can run on NAND, but is that true ?
>
> That's true. We don't have a NAND devb right now (which is required
> for io-blk, which is required for fs-dos).
>
> >
> > They also want to boot from the NAND:
> > "
> > We have a requirement to boot from the NAND.
> > From the Atmel datasheet:
> > "The first block must be guaranteed by the manufacturer.
> There
> > is no ECC check.
>
> That's a standard guarentee from NAND manufacturers.
>
> > The NVM bootloader program (this is the ROM code running on
> > power up) looks for a boot.bin file in the root directory of a
> > FAT12/16/32 formatted NVM Flash."
> > "
> >
> > I'm guessing we could...
View Full Message
|
|
|
|
|
|
David Sarrazin
|
RE: FAT32 filesystem on NAND ?
|
|
David Sarrazin
08/14/2009 11:33 AM
post36024
|
RE: FAT32 filesystem on NAND ?
> -----Original Message-----
> From: Dave Bott [mailto:community-noreply@qnx.com]
> Sent: August 14, 2009 11:24 AM
> To: general-filesystems
> Subject: RE: FAT32 filesystem on NAND ?
>
> Hi Mario,
>
> It certainly would be possible to write ETFS for Windows, but
> then you couldn't plug the device into practically *any*
> Windows box without having to install extra software - this
> customer wants to use a generic approach, which has merit.
>
> You're right that raw NAND chips are not plugged into a PC -
> no argument here. Their requirement is only a little unusual;
> it is quite common to make the filesystem of a device visible
> over USB. They will have SD or SDHC card(s) (with FAT), but
> also want the internal filesystem (the NAND chips) to be visible too.
>
> I think *a* way to go here, assuming (and it's a big
> assumption) a read-only requirement from Windows, could be to
> create an emulation layer, making the ETFS look like a FAT
> FS. If it's just reading files and directories, that should
> be possible. Writing gets a lot more hairy...
Filesystem-in-a-file. A FAT "filesystem" inside an ETFS partition. I
could envision starting ETFS, and then devb-loopback, and running the
umass_device code on top of the /dev/lo0 provided by devb-loopback, or
mounting the filesystem when NOT connected to a PC. Don't ask about
performance though.
>
> Dave
>
> ________________________________
>
> From: Mario Charest [mailto:community-noreply@qnx.com]
> Sent: Fri 14/08/2009 8:15 AM
> To: general-filesystems
> Subject: RE: FAT32 filesystem on NAND ?
>
>
>
>
> > -----Original Message-----
> > From: Dave Bott [mailto:community-noreply@qnx.com]
> > Sent: Friday, August 14, 2009 10:54 AM
> > To: general-filesystems
> > Subject: RE: FAT32 filesystem on NAND ?
> >
> > Thanks for your reply David !
> >
> > The FAT file system does need to be read/written by QNX
> Neutrino, to
> > generate the files that can be uploaded to the PC.
> >
>
> Wouldn't it be somewhat easier to write a Windows application
> that can read ETFS?
>
> > So, it sounds like we definitely don't support this today.
> >
> > Hopefully, it is understood *why* they want to do this -
> any plans for
> > us to support devb on NAND ?
>
> > Lots of devices get plugged in to PCs these days... it's such a
> > convenient thing to do.
>
> Raw NAND devices are not typically plugged in to PC.
>
> >
> > Thanks
> >
> > Dave
> >
> > ________________________________
> >
> > From: David Sarrazin [mailto:community-noreply@qnx.com]
> > Sent: Fri 14/08/2009 7:26 AM
> > To: general-filesystems
> > Subject: RE: FAT32 filesystem on NAND ?
> >
> >
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Dave Bott [mailto:community-noreply@qnx.com]
> > > Sent: August 13, 2009 5:08 PM
> > > To: general-filesystems
> > > Subject: FAT32 filesystem on NAND ?
> > >
> > > 6.4.1 ARMLE
> > >
> > > Customer wants to use a FAT filesystem on their NAND chips (on an
> > > Atmel ARM board), so that they can plug into a PC as a USB device
> > > for uploads to the PC directly from the filesystem.
> >
> > Do we need to be able to read/write the FAT filesystem, or is it
> > purely for the benefit of the PC?
> > If the PC is mounting it, then the device only needs to provide a
> > block interface to the raw device, so that a umass-device
> controller
> > can access the requested...
View Full Message
|
|
|
|
|
|
Mario Charest
|
RE: FAT32 filesystem on NAND ?
|
|
Mario Charest
08/14/2009 11:34 AM
post36026
|
RE: FAT32 filesystem on NAND ?
> -----Original Message-----
> From: David Sarrazin [mailto:community-noreply@qnx.com]
> Sent: Friday, August 14, 2009 11:33 AM
> To: general-filesystems
> Subject: RE: FAT32 filesystem on NAND ?
>
>
>
> > -----Original Message-----
> > From: Dave Bott [mailto:community-noreply@qnx.com]
> > Sent: August 14, 2009 11:24 AM
> > To: general-filesystems
> > Subject: RE: FAT32 filesystem on NAND ?
> >
> > Hi Mario,
> >
> > It certainly would be possible to write ETFS for Windows, but
> > then you couldn't plug the device into practically *any*
> > Windows box without having to install extra software - this
> > customer wants to use a generic approach, which has merit.
> >
> > You're right that raw NAND chips are not plugged into a PC -
> > no argument here. Their requirement is only a little unusual;
> > it is quite common to make the filesystem of a device visible
> > over USB. They will have SD or SDHC card(s) (with FAT), but
> > also want the internal filesystem (the NAND chips) to be visible too.
> >
> > I think *a* way to go here, assuming (and it's a big
> > assumption) a read-only requirement from Windows, could be to
> > create an emulation layer, making the ETFS look like a FAT
> > FS. If it's just reading files and directories, that should
> > be possible. Writing gets a lot more hairy...
>
> Filesystem-in-a-file. A FAT "filesystem" inside an ETFS partition. I
> could envision starting ETFS, and then devb-loopback, and running the
> umass_device code on top of the /dev/lo0 provided by devb-loopback, or
> mounting the filesystem when NOT connected to a PC. Don't ask about
> performance though.
>
Windows still wouln't be able to read it, right?
>
>
> >
> > Dave
> >
> > ________________________________
> >
> > From: Mario Charest [mailto:community-noreply@qnx.com]
> > Sent: Fri 14/08/2009 8:15 AM
> > To: general-filesystems
> > Subject: RE: FAT32 filesystem on NAND ?
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Dave Bott [mailto:community-noreply@qnx.com]
> > > Sent: Friday, August 14, 2009 10:54 AM
> > > To: general-filesystems
> > > Subject: RE: FAT32 filesystem on NAND ?
> > >
> > > Thanks for your reply David !
> > >
> > > The FAT file system does need to be read/written by QNX
> > Neutrino, to
> > > generate the files that can be uploaded to the PC.
> > >
> >
> > Wouldn't it be somewhat easier to write a Windows application
> > that can read ETFS?
> >
> > > So, it sounds like we definitely don't support this today.
> > >
> > > Hopefully, it is understood *why* they want to do this -
> > any plans for
> > > us to support devb on NAND ?
> >
> > > Lots of devices get plugged in to PCs these days... it's such a
> > > convenient thing to do.
> >
> > Raw NAND devices are not typically plugged in to PC.
> >
> > >
> > > Thanks
> > >
> > > Dave
> > >
> > > ________________________________
> > >
> > > From: David Sarrazin [mailto:community-noreply@qnx.com]
> > > Sent: Fri 14/08/2009 7:26 AM
> > > To: general-filesystems
> > > Subject: RE: FAT32 filesystem on NAND ?
> > >
> > >
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Dave Bott [mailto:community-noreply@qnx.com]
> > > > Sent: August 13, 2009 5:08 PM
>...
View Full Message
|
|
|
|
|
|
David Sarrazin
|
RE: FAT32 filesystem on NAND ?
|
|
David Sarrazin
08/14/2009 11:47 AM
post36029
|
RE: FAT32 filesystem on NAND ?
[snip]
> >
> > Filesystem-in-a-file. A FAT "filesystem" inside an ETFS
> partition. I
> > could envision starting ETFS, and then devb-loopback, and
> running the
> > umass_device code on top of the /dev/lo0 provided by
> devb-loopback, or
> > mounting the filesystem when NOT connected to a PC. Don't
> ask about
> > performance though.
> >
>
> Windows still wouln't be able to read it, right?
Windows isn't reading the NAND directly, it's over USB (from Dave's
original post), so Windows is talking UMASS to some umass device driver
on the board. The FAT code in Windows is driving what blocks to read,
and the umass_device on the target is pulling them from the
FAT-in-a-file. Devb-loopback is in there to allow the target to mount
the partition locally, when not connected to a PC.
>
> >
> >
> > >
> > > Dave
> > >
[snip]
|
|
|
|
|
|
Dave Bott(deleted)
|
Re: FAT32 filesystem on NAND ?
|
|
Dave Bott(deleted)
09/09/2009 4:44 PM
post37693
|
Re: FAT32 filesystem on NAND ?
So, after a few travails, I'm in a position to try this...
I have an Atmel ARM G45 running 6.4.1.
I have etfs on it, formatted and mounted.
However, there's no devb-loopback in 6.4.1. I can see the source in svn
- do I have to build it, or is there a prebuilt version I can grab ?
Then, if we don't ship devb-loopback as standard product, is it safe to
suggest its use to a customer ? This will be a production device, and
this element will be crucial...
Then, what is the procedure for using devb-loopback ?
Do you create a file first, then reference it with devb-loopback ?
Does the file need to be pre-grown ?
Any suggested options to devb-loopback ?
In this case, they have a 2GBit NAND (256MB) and want the DOS filesystem
to be ~230MB of it - so is there a way to grab that space for this DOS
filesystem ?
They are jumping up and down to try this ASAP...
Thanks
Dave
David Sarrazin wrote:
>
>
>
> > -----Original Message-----
> > From: Dave Bott [mailto:community-noreply@qnx.com]
> > Sent: August 14, 2009 11:24 AM
> > To: general-filesystems
> > Subject: RE: FAT32 filesystem on NAND ?
> >
> > Hi Mario,
> >
> > It certainly would be possible to write ETFS for Windows, but
> > then you couldn't plug the device into practically *any*
> > Windows box without having to install extra software - this
> > customer wants to use a generic approach, which has merit.
> >
> > You're right that raw NAND chips are not plugged into a PC -
> > no argument here. Their requirement is only a little unusual;
> > it is quite common to make the filesystem of a device visible
> > over USB. They will have SD or SDHC card(s) (with FAT), but
> > also want the internal filesystem (the NAND chips) to be visible too.
> >
> > I think *a* way to go here, assuming (and it's a big
> > assumption) a read-only requirement from Windows, could be to
> > create an emulation layer, making the ETFS look like a FAT
> > FS. If it's just reading files and directories, that should
> > be possible. Writing gets a lot more hairy...
>
> Filesystem-in-a-file. A FAT "filesystem" inside an ETFS partition. I
> could envision starting ETFS, and then devb-loopback, and running the
> umass_device code on top of the /dev/lo0 provided by devb-loopback, or
> mounting the filesystem when NOT connected to a PC. Don't ask about
> performance though.
>
>
>
> >
> > Dave
> >
> > ________________________________
> >
> > From: Mario Charest [mailto:community-noreply@qnx.com]
> > Sent: Fri 14/08/2009 8:15 AM
> > To: general-filesystems
> > Subject: RE: FAT32 filesystem on NAND ?
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Dave Bott [mailto:community-noreply@qnx.com]
> > > Sent: Friday, August 14, 2009 10:54 AM
> > > To: general-filesystems
> > > Subject: RE: FAT32 filesystem on NAND ?
> > >
> > > Thanks for your reply David !
> > >
> > > The FAT file system does need to be read/written by QNX
> > Neutrino, to
> > > generate the files that can be uploaded to the PC.
> > >
> >
> > Wouldn't it be somewhat easier to write a Windows application
> > that can read ETFS?
> >
> > > So, it sounds like we definitely don't support this today.
> > >
> > > Hopefully, it is understood *why* they want to do this -
> > any plans for
> > > us to support devb on NAND ?
> >
> > > Lots of devices get plugged in to PCs these days... it's such a
> > > convenient thing to do.
> >
> > Raw NAND devices are not typically plugged...
View Full Message
|
|
|
|
|
|
Steve Reid
|
Re: FAT32 filesystem on NAND ?
|
|
Steve Reid
09/09/2009 5:11 PM
post37695
|
Re: FAT32 filesystem on NAND ?
You'll be pleased to hear that devb-loopback is going into 6.4.2, so I guess it's OK for your customer to use it.
There's an entry for it in the 6.4.2 Utilities Reference that might help you:
http://stevernto.ott.qnx.com/neutrino/utilities/d/devb-loopback.html
If it doesn't, please make suggestions for improving it (as if I could stop you...)
Steve Reid (stever@qnx.com)
Technical Editor
QNX Software Systems
|
|
|
|
|
|
HELP
