Questions about Bootsector of an SD card
Ariba
Posts: 2,690
I try to make my own little filesystem, as well as a minimal SD card bootloader.
The idea is to have a FAT16 or FAT32 formated SD card, with a big file which holds my
own filesystem.
I need to know the startsector of this file, without going thru the FAT table, so I had
the idea to evaluate this once and write the number into a known place in sector 0 of the SD
card.
When I look at the description of sector 0 this can be a BootRecord or a MasterBootRecord. In
both cases the most part of the sector holds a boot code. For what is this boot code? It's an
i286 assembly code which wan't work anyway on many systems that can read an SD card.
What happens if I just overwrite parts of this code, will a Windows or MSDOS PC fail to read
the SD card later?
Has anybody a better idea to store the sector number at a known place inside a FAT structure?
Andy
The idea is to have a FAT16 or FAT32 formated SD card, with a big file which holds my
own filesystem.
I need to know the startsector of this file, without going thru the FAT table, so I had
the idea to evaluate this once and write the number into a known place in sector 0 of the SD
card.
When I look at the description of sector 0 this can be a BootRecord or a MasterBootRecord. In
both cases the most part of the sector holds a boot code. For what is this boot code? It's an
i286 assembly code which wan't work anyway on many systems that can read an SD card.
What happens if I just overwrite parts of this code, will a Windows or MSDOS PC fail to read
the SD card later?
Has anybody a better idea to store the sector number at a known place inside a FAT structure?
Andy
Comments
Look in that thread.
http://forums.parallax.com/forums/default.aspx?f=25&p=3&m=437544
I have send some info on FAT16, FAT32 to it
If Yoy can find program - HEXEDIT on internet it has posibility to give You all info you need.
Bootcode is native 8086-80 ASM code.
You not need overvrite nonthing in MBR else BootSector -- them have some spare place both after BootCode,
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
That code is there to load the op system. So unless you try to boot a PC with it, it should work.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
pPropellerSim - A propeller simulator for ASM development sourceforge.net/projects/ppropellersim
I missed this discussion in the YAZ80 thread, very interesting.
My goal is that it works the same with FAT16 and FAT32 and I don't need to make partitions or other special formating tricks.
The SD card should boot my propeller system, and never a PC, it must only be readable and writeable from a PC.
So I think overwriting some bytes of this boot code should work.
Andy
You can probably use my fatfs.spin then. It does read FAT16 and FAT32, and should also read FAT12 (untested), can find a file and return various info like size, date, (most important) first sector. I also have a continuity check in my code to ensure the image I'm going to write to is in sequential clusters. It can also scan a directory and return the 32 byte directory entries one after another to the calling function. It doesn't handle long filenames.
Juergen
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
sound very handy. I already have my own FSRW extensions to get the startsector of a file, but I will have a look at your fatfs.spin
too. But I will use this only for a helper application to make the SD card bootable (= write the startsector at a defined position in
sector 0). The filesystem driver for the end application should be as small as possible and only use the low level SD card access (the SPI driver).
Andy