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. :-)
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.
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. :-)
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!