File written, under FreeDOS, on spi flash (formatted as FAT12) is not found in Linux
Linux - Embedded & Single-board computerThis forum is for the discussion of Linux on both embedded devices and single-board computers (such as the Raspberry Pi, BeagleBoard and PandaBoard). Discussions involving Arduino, plug computers and other micro-controller like devices are also welcome.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
File written, under FreeDOS, on spi flash (formatted as FAT12) is not found in Linux
Hi all,
I have a development board which has an spi flash. Under linux, this flash is mounted as MTD block device. I'm using the formatting tool provided by manufacturer, called spitool.exe. If I write file to the flash when I want to read it under FreeDOS it is not found. Otherwise If I write file under FreeDOS it is not found under Linux. The flash is formatted as FAT12 disk. BIOS emulates the spi flash as a floppy disk. The superblock is written by the spitool.exe. Why is it occurring?
I read the flash in raw mode and I realized that the Directory Entry of the file (in root directory) was written at different byte offset when the file was written under FreeDOS in relation to Linux. Root Directory Entries can only be written starting at sector 13 up to sector 27. But under FreeDOS the Root Directory Entries was written starting at sector 41.
Any help will be appreciated.
What is the mount command you use under Linux, to mount the gadget? The reason I ask is (though I don't know much about the deep down workings of the various FAT formats) I wonder if Linux is detecting it as the correct FAT version, and/or if not, could "wrong FAT version" account for the offset difference you discovered??
From `man mount` there is the option: fat=12
..which might force the correct FAT type (assumibng it's wrong to begin with, but again, I don't know whether the different FATs each use a different offset, leading to what you describe).
Sorry I can't offer anything further; I hope someone else has something to offer!
What is the mount command you use under Linux, to mount the gadget? The reason I ask is (though I don't know much about the deep down workings of the various FAT formats) I wonder if Linux is detecting it as the correct FAT version, and/or if not, could "wrong FAT version" account for the offset difference you discovered??
From `man mount` there is the option: fat=12
..which might force the correct FAT type (assumibng it's wrong to begin with, but again, I don't know whether the different FATs each use a different offset, leading to what you describe).
Sorry I can't offer anything further; I hope someone else has something to offer!
Sasha
I added some "printk's" in FAT source file and I recompiled the FAT driver. One printk shows the FAT bits (12, 16 or 32). And it showed 12 bits for the FAT recorded on the flash (accordingly to FAT superblock).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.