Bootloading from SD card

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... ?

yg
-- 
http://ygdes.com / http://yasep.org

On Thu, 19 Nov 2009 05:57:21 +0100, 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... ?

True.

I forgot all about the BIOS doing all the hard work doing the drive
I/O.  However, from what I remember when I read thru some bios
listings, reading from an MFM / RLL / ESDI / IDE drive in PIO mode
isn't all that big a deal.  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.  :-)
-- 
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.

On Sun, 15 Nov 2009 22:57:56 -0600, eeboy wrote:

> I want to enable my device to replace the contents of flash by reading
> in a binary file from the SD card. The catch is that I don't want to
> implement FAT in my bootloader. I want it to be as small in size and as
> simple as can be.

Easiest solution is to do whatever LILO (Linux loader) used to do: put the
binary file on the SD Card using normal file copy. After the file has been
copied, use a special application to find out exactly where the file is,
and make a list of all sector numbers. Put that list in the second half of
the boot sector.

If the sector list doesn't fit in the boot sector, put it somewhere else
on the disk, and put its sector numbers in the boot sector.

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!

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

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

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!!

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

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

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