Reply by November 20, 20092009-11-20
On Fri, 20 Nov 2009 00:52:00 -0600,
ArarghMail911NOSPAM@NOT.AT.Arargh.com wrote:

>On Fri, 20 Nov 2009 00:45:15 GMT, NoEmailAds@execpc.com (Chris Giese) >wrote: > >>ArarghMail911NOSPAM@NOT.AT.Arargh.com wrote: >> >>>It's not all that difficult for FAT12 or FAT16 if you restrict your >>>file to the root directory. I wrote a routine that searches the root >>>directory for a specific file, and reads it into memory via the FAT. I >>>think it took less than 512 bytes on an x86, not sure, but definitely >>>less than 1024 bytes. The boot sector is only 2 sectors long -- non >>>standard disk format - but I presume your routine would be in ROM or >>>flash so my non-standard format is not an issue. >> >>I also did a FAT-12 PC bootsector in 512 bytes: >> http://my.execpc.com/~geezer/code/fatboot.zip >> >>This code requires that the second stage or kernel or whatever be >>in the root directory, but it need not be physically contiguous on >>the disk. >> >>FAT-16 wouldn't be too different, >13 vs 5 instructions for FAT12 vs FAT16 in the code I wrote.
Forgot to mention that I cheated and just copied the first 64k worth of FAT to memory. For FAT12, that handles the split across sectors headache.
>>but I agree that a FAT-32 >>bootloader probably wouldn't fit in 512 bytes. >No, I don't think it's even possible, but I haven't tried. > >And see no point doing so, either. :-)
-- ArarghMail911 at [drop the 'http://www.' from ->] http://www.arargh.com BCET Basic Compiler Page: http://www.arargh.com/basic/index.html To reply by email, remove the extra stuff from the reply address.
Reply by November 20, 20092009-11-20
On Fri, 20 Nov 2009 00:45:15 GMT, NoEmailAds@execpc.com (Chris Giese)
wrote:

>ArarghMail911NOSPAM@NOT.AT.Arargh.com wrote: > >>It's not all that difficult for FAT12 or FAT16 if you restrict your >>file to the root directory. I wrote a routine that searches the root >>directory for a specific file, and reads it into memory via the FAT. I >>think it took less than 512 bytes on an x86, not sure, but definitely >>less than 1024 bytes. The boot sector is only 2 sectors long -- non >>standard disk format - but I presume your routine would be in ROM or >>flash so my non-standard format is not an issue. > >I also did a FAT-12 PC bootsector in 512 bytes: > http://my.execpc.com/~geezer/code/fatboot.zip > >This code requires that the second stage or kernel or whatever be >in the root directory, but it need not be physically contiguous on >the disk. > >FAT-16 wouldn't be too different,
13 vs 5 instructions for FAT12 vs FAT16 in the code I wrote.
>but I agree that a FAT-32 >bootloader probably wouldn't fit in 512 bytes.
No, I don't think it's even possible, but I haven't tried. And see no point doing so, either. :-) -- ArarghMail911 at [drop the 'http://www.' from ->] http://www.arargh.com BCET Basic Compiler Page: http://www.arargh.com/basic/index.html To reply by email, remove the extra stuff from the reply address.
Reply by Chris Giese November 19, 20092009-11-19
ArarghMail911NOSPAM@NOT.AT.Arargh.com wrote:

>It's not all that difficult for FAT12 or FAT16 if you restrict your >file to the root directory. I wrote a routine that searches the root >directory for a specific file, and reads it into memory via the FAT. I >think it took less than 512 bytes on an x86, not sure, but definitely >less than 1024 bytes. The boot sector is only 2 sectors long -- non >standard disk format - but I presume your routine would be in ROM or >flash so my non-standard format is not an issue.
I also did a FAT-12 PC bootsector in 512 bytes: http://my.execpc.com/~geezer/code/fatboot.zip This code requires that the second stage or kernel or whatever be in the root directory, but it need not be physically contiguous on the disk. FAT-16 wouldn't be too different, but I agree that a FAT-32 bootloader probably wouldn't fit in 512 bytes.
Reply by Mark Borgerson November 19, 20092009-11-19
In article <4b05a986$0$28153$5fc3050@news.tiscali.nl>, 
dombo@disposable.invalid says...
> whygee schreef: > > hi ! > > > > Grant Edwards wrote: > >> ARM bootloaders that run in a total of 8KB of memory (code and > >> data) are able to find and load files fromt the root directory > >> of a FAT filesystem on an SD card, so it can't be _that_ hard. > > Sure. > > > > However, 1 or 2 sectors take 512 to 1024 bytes, > > while 8KB is larger than that. That's at least > > 8x more work :-/ > > > > Seriously, with Linux, there is no such issue, > > just "cat mybinary > /dev/SDcard" and make the > > embedded CPU read X consecutive sectors. > > That's more or less what I did for my > > own x86 boot-sector applications, with nasm > > and standard GNU utilities. The rest of the > > script ensured that the device where I 'cat' > > is not mounted, to prevent accidental catastrophes :-) > > > > Now, if the original poster really wants to > > use MS Windows, he is trading ease/speed of > > development for ease for the user, but sometimes > > the cost (time, money, complexity) is not > > worth it. At least, for me, it's not worth caring > > about this at all, for many years. With W95 > > it was still possible to access BIOS-driven > > routines for raw device access from a DOS box, > > but because of the lack of a decent security > > model, MS simply forbids this now. > > There is no need to resort to BIOS calls to access disk sectors on > Windows; one can access disk sectors using the Win32 file API calls by > calling the CreateFile() function with "\\\\.\\PhysicalDriveX" as > filename (X should be replaced with the number of the physical drive). >
That's correct. I use that method to read data in a proprietary sequential file system that I use with SD cards on MSP430 loggers. You don't necessarily need to use the physical drive number either. I use this: sprintf(devname,"\\\\.\\%c:", *EDDevice->Text.c_str()); devhandle = CreateFile( devname, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, flags, NULL); where %c in the file name is the drive letter (usually 'E' for the SD card interface on my computer). Mark Borgerson
Reply by Dombo November 19, 20092009-11-19
whygee schreef:
> hi ! > > Grant Edwards wrote: >> ARM bootloaders that run in a total of 8KB of memory (code and >> data) are able to find and load files fromt the root directory >> of a FAT filesystem on an SD card, so it can't be _that_ hard. > Sure. > > However, 1 or 2 sectors take 512 to 1024 bytes, > while 8KB is larger than that. That's at least > 8x more work :-/ > > Seriously, with Linux, there is no such issue, > just "cat mybinary > /dev/SDcard" and make the > embedded CPU read X consecutive sectors. > That's more or less what I did for my > own x86 boot-sector applications, with nasm > and standard GNU utilities. The rest of the > script ensured that the device where I 'cat' > is not mounted, to prevent accidental catastrophes :-) > > Now, if the original poster really wants to > use MS Windows, he is trading ease/speed of > development for ease for the user, but sometimes > the cost (time, money, complexity) is not > worth it. At least, for me, it's not worth caring > about this at all, for many years. With W95 > it was still possible to access BIOS-driven > routines for raw device access from a DOS box, > but because of the lack of a decent security > model, MS simply forbids this now.
There is no need to resort to BIOS calls to access disk sectors on Windows; one can access disk sectors using the Win32 file API calls by calling the CreateFile() function with "\\\\.\\PhysicalDriveX" as filename (X should be replaced with the number of the physical drive).
Reply by whygee November 19, 20092009-11-19
Grant Edwards wrote:
> On 2009-11-19, whygee <yg@yg.yg> wrote: >> However, 1 or 2 sectors take 512 to 1024 bytes, >> while 8KB is larger than that. That's at least >> 8x more work :-/ > Oops. I missed the requirement that it fit in 1-2 512-byte > sectors.
however the OP could code something that dumps the X first sectors anyway :-) yg -- http://ygdes.com / http://yasep.org
Reply by Grant Edwards November 19, 20092009-11-19
On 2009-11-19, whygee <yg@yg.yg> wrote:
> hi ! > > Grant Edwards wrote: >> ARM bootloaders that run in a total of 8KB of memory (code and >> data) are able to find and load files fromt the root directory >> of a FAT filesystem on an SD card, so it can't be _that_ hard. > Sure. > > However, 1 or 2 sectors take 512 to 1024 bytes, > while 8KB is larger than that. That's at least > 8x more work :-/
Oops. I missed the requirement that it fit in 1-2 512-byte sectors. -- Grant Edwards grante Yow! Everybody is going at somewhere!! It's probably visi.com a garage sale or a disaster Movie!!
Reply by whygee November 19, 20092009-11-19
hi !

Grant Edwards wrote:
> ARM bootloaders that run in a total of 8KB of memory (code and > data) are able to find and load files fromt the root directory > of a FAT filesystem on an SD card, so it can't be _that_ hard.
Sure. However, 1 or 2 sectors take 512 to 1024 bytes, while 8KB is larger than that. That's at least 8x more work :-/ Seriously, with Linux, there is no such issue, just "cat mybinary > /dev/SDcard" and make the embedded CPU read X consecutive sectors. That's more or less what I did for my own x86 boot-sector applications, with nasm and standard GNU utilities. The rest of the script ensured that the device where I 'cat' is not mounted, to prevent accidental catastrophes :-) Now, if the original poster really wants to use MS Windows, he is trading ease/speed of development for ease for the user, but sometimes the cost (time, money, complexity) is not worth it. At least, for me, it's not worth caring about this at all, for many years. With W95 it was still possible to access BIOS-driven routines for raw device access from a DOS box, but because of the lack of a decent security model, MS simply forbids this now. So why care about FAT when it can be avoided, and bait&switch operating systems ? yg -- http://ygdes.com / http://yasep.org
Reply by whygee November 19, 20092009-11-19
ArarghMail911NOSPAM@NOT.AT.Arargh.com wrote:
> I would think that the other systems > wouldn't be that much more complicated, but I have no idea, never > having used any of them. > Unless you count a DG NOVA clone some 25 or 30 years ago. :-)
this would be OT for this group ;-) yg -- http://ygdes.com / http://yasep.org
Reply by Grant Edwards November 19, 20092009-11-19
On 2009-11-19, whygee <yg@yg.yg> wrote:
> hi, > > ArarghMail911NOSPAM@NOT.AT.Arargh.com wrote: >> It's not all that difficult for FAT12 or FAT16 if you restrict your >> file to the root directory. I wrote a routine that searches the root >> directory for a specific file, and reads it into memory via the FAT. I >> think it took less than 512 bytes on an x86, not sure, but definitely >> less than 1024 bytes. The boot sector is only 2 sectors long -- non >> standard disk format - but I presume your routine would be in ROM or >> flash so my non-standard format is not an issue. > > The original poster did not mention the target system's CPU > or even type. If it's a PC or an embedded x86, then your solution > is OK because the BIOS does most of the nasty work and your boot > sector just calls INTxx but what if it's an ARM or MIPS or... ?
ARM bootloaders that run in a total of 8KB of memory (code and data) are able to find and load files fromt the root directory of a FAT filesystem on an SD card, so it can't be _that_ hard. -- Grant Edwards grante Yow! All right, you at degenerates! I want visi.com this place evacuated in 20 seconds!