Rockbox Development > New Ports
Creative Zen Vision:M
quetzalcoatl:
prior to line246 you are esentially obtaining the inode number of 'vfat' entry in the root directory -- thats lines 241-242.
having it, you read the inode (line254-255) and then fseek on its firstclasschain[0] and then, from this position you fread into structure CFS_DIRENTRY.
is it right? if you have obtained the virtualvolume file's inode, the very file should lie in this cluster, not an another cfs directory.
otherwise, if it is a directory for example for virtualvolumes, then why arent you searching for the right one?
instead of searching, what you do next, is scanning through the 'vfat files' and collect theirs inodes' numbers into array 'vfat_inodes', skipping the first - why doing so? the direntry#1 should be nothing special, just an entry like any other
okay, assuming that all above was correct, you now essentially have a 'vfat_inodes' array that holds all inodes of all files under /VFAT directory in the CFS volume
then, foreach file, you gather its dataclusters' numbers from the first/second/thirdclass chains correctly
(i've now noticed that my notes aren't the _latest_.. i must have lost the latest ones, because on those i have found and published there's a:
uint32 first_class_chain
uint32 second_class_chain_first_cluster
uint32 second_class_chain_second_cluster
what you probably noticed thats to Tobia's site is not true. the diagram:
inode
\_ up to 12 data clusters (some of which might be set to -1)
\_ second class chain cluster (seems to always be allocated)
(......)
is taken almost directly from an email i sent him once..
its' really
uint32 first_class_chain
uint32 second_class_chain_clusterid
uint32 third_class_chain_clusterid
and you took it right)
and finally, you copy all the dataclusters from all files in VFAT into a single huge file.. i suppose thats for debugging only? this surely does not produce a valid content
oh, and you're not using any bitmaps at all [and there's a lot of them everywhere!]. i think you should.. the files you are analyzing supposedly are rarely moved anywhere, but yo unever know which entry in directory/inodes/blah would be disabled via the bitmap
i'll have probably few hours today, so i'll look in that vfat direcotry-to-be and its contents. littlebit strange that they put such directory and files inside. does the ZenVisionM support multiple virtualvolumes on it? or does the directory contain a single file only?
mcuelenaere:
--- Quote from: quetzalcoatl on August 30, 2008, 12:06:26 PM ---prior to line246 you are esentially obtaining the inode number of 'vfat' entry in the root directory -- thats lines 241-242.
having it, you read the inode (line254-255) and then fseek on its firstclasschain[0] and then, from this position you fread into structure CFS_DIRENTRY.
is it right? if you have obtained the virtualvolume file's inode, the very file should lie in this cluster, not an another cfs directory.
--- End quote ---
I have to admit, I haven't commented the file really.
The structure is like this:
root inode -> VFAT dir -> * VFSYS
* vfile_00
* vfile_01
The VFSYS file contains another (unknown) structure with inode references to vfile_00 & vfile_01 + some kind of partitioning info how the total file is divided (see struct cfs_vfat)
--- Quote ---otherwise, if it is a directory for example for virtualvolumes, then why arent you searching for the right one?
--- End quote ---
I am, but there are several files containing the volume
--- Quote ---instead of searching, what you do next, is scanning through the 'vfat files' and collect theirs inodes' numbers into array 'vfat_inodes', skipping the first - why doing so? the direntry#1 should be nothing special, just an entry like any other
--- End quote ---
Ok, perhaps I'm wrong here (I haven't looked into what filesystem bitmaps are), but these two inodes (vfile_00 & vfile_01) contain inode numbers (which contain the data of the virtual volume).
--- Quote ---okay, assuming that all above was correct, you now essentially have a 'vfat_inodes' array that holds all inodes of all files under /VFAT directory in the CFS volume
--- End quote ---
Correct.
--- Quote ---then, foreach file, you gather its dataclusters' numbers from the first/second/thirdclass chains correctly
(i've now noticed that my notes aren't the _latest_.. i must have lost the latest ones, because on those i have found and published there's a:
uint32 first_class_chain
uint32 second_class_chain_first_cluster
uint32 second_class_chain_second_cluster
what you probably noticed thats to Tobia's site is not true. the diagram:
inode
\_ up to 12 data clusters (some of which might be set to -1)
\_ second class chain cluster (seems to always be allocated)
(......)
is taken almost directly from an email i sent him once..
its' really
uint32 first_class_chain
uint32 second_class_chain_clusterid
uint32 third_class_chain_clusterid
and you took it right)
and finally, you copy all the dataclusters from all files in VFAT into a single huge file.. i suppose thats for debugging only? this surely does not produce a valid content
--- End quote ---
No that's not for debugging, I *thought* that all these dataclusters together merged to the virtual volume..
--- Quote ---oh, and you're not using any bitmaps at all [and there's a lot of them everywhere!]. i think you should.. the files you are analyzing supposedly are rarely moved anywhere, but yo unever know which entry in directory/inodes/blah would be disabled via the bitmap
--- End quote ---
As I'm not familiar with this, I haven't used them nor found them (all this file system is stuff is completely new to me).
--- Quote ---i'll have probably few hours today, so i'll look in that vfat direcotry-to-be and its contents. littlebit strange that they put such directory and files inside. does the ZenVisionM support multiple virtualvolumes on it? or does the directory contain a single file only?
--- End quote ---
Thanks.
No, the ZenVisionM doesn't support multiple virtualvolumes but AFAI understand the virtual volume is divided into vfile_0x files.
quetzalcoatl:
divided? it seems.. pointless. i didn't got there today, but i updated the notes with information on the cfs's "header".
new interesting things on CFS
- cluster on NJB is 0x10 sectors, on ZVM - 0x40 sectors
- CFS's adresation is actually overlapping with MINIFS: CFS's physical sector 0x000000 is seen by CFS as a *second* sector of its very first physical cluster, and the last sector of MINIFS is seen as that first sector.. This is why the first cluster is never-ever used, and logical ID of -1/0xFFFFFFFF and filled with 0x00s or 0xFFs
- cluster 0x02 contain volume-specific information, and cluster 0x03 probably too. for now, i'll call them volumeinformation1 (VI1) and volumeinformation2 (VI2) respectively
the VI1 contains very important information. currently known are:
- cluster size
- volumesize
- signature 'BFS1' :)
- root directory inode number! no more hardcoding!
- timestamp. what did you do on 2005-08-01 01:51:07 ?:) that probably was the time when the drive was formatted and volume created
----------
and the bitmaps [notes/minifs/bitmaps.txt]
all, or almost all of the lists that must be traversed does have a special 'bitmap' that tells which entries are used and which are free. there are for example:
- drive:cluster bitmap <-> all clusterchains
- a directory:direntry bitmap<-> that directory's list of entries
and may be others, i dont recall right now.
each entry on the list has a zero-based position. so does the bits on the bitmap. each bit tells if the entry is used. bit=0 indicates that it is free, bit=1 that it is used, for example:
having a dir entries' list:
0 empty
1 empty
2 somefilename
3 empty
4 somefilename
5 somefilename
6 empty
7 empty
8 SoMeFiLeNaMe
9 empty
A somefilename
B somefilename
C somefilename
D somefilename
E empty
F somefilename
the bitmap would contain: 0 0 1 0 1 1 0 0 1 0 1 1 1 1 0 1, that is b1011110100110100, that is 0xBD34
BUT, would the bitmap actually contain 0xBC34, that would mean, that the SoMeFiLeNaMe entry if free - despite having well-looking contents! - for example, the file could have been deleted long time ago and its unlinked data could have already be overwritten with new content
the same follows with cluster bitmap. the cluster bitmap is a bitmap that indexes whole volume's clusterspace. each cluster does have a corresponding bit in the bitmap and is subject to be checked against it. if a clusterchain contains an clusterid which is marked as free (bit=0), this clearly indicates that the chain and/or the bitmap has been corrupted. this is serious, because when new files are written/added to the volume, the system searches for free space using the *bitmap*. actually, this is the main reason for its existence: looking for holes that may be reused. traversing a list of 0/1 bits is waaay faster than scanning clusterchains and looking which clusterids are unused
---------
i have started looking into CFS directory structure. the whole volume format matches the old one, with respect to changed clustersize. the inodes' and directories' structure is the same, too. the directories take 1632 entries in total of 0x80 sectors which translates to 8clusters in NJB and 2 clusters in ZVM.
on yours (mcuelenaere) drive image, in the root directory, I have found several new entries:
inode=0x00000009, fnlen = 0x0008, unk = 0x0002, {archives\0,} [old]
inode=0x0000000E, fnlen = 0x0003, unk = 0x0002, {pim\0,} [new!]
inode=0x00000013, fnlen = 0x0009, unk = 0x0002, {playlists\0,} [old]
inode=0x00000018, fnlen = 0x000A, unk = 0x0002, {recordings\0,} [old]
inode=0x0000001D, fnlen = 0x0005, unk = 0x0002, {songs\0,} [old]
inode=0x00000022, fnlen = 0x0006, unk = 0x0002, {system\0,} [old]
inode=0x00000027, fnlen = 0x0006, unk = 0x0002, {photos\0,} [new]
inode=0x0000002C, fnlen = 0x0006, unk = 0x0002, {videos\0,} [new]
inode=0x00000031, fnlen = 0x0004, unk = 0x0002, {vdir\0,} [new]
inode=0x00000036, fnlen = 0x0005, unk = 0x0002, {vrefs\0,} [new]
inode=0x0000003B, fnlen = 0x0004, unk = 0x0002, {VFAT\0,} [new]
inode=0x00000044, fnlen = 0x0006, unk = 0x0002, {albums\0,} [new]
inode=0x00000000,
please note the vdir, vrefs, VFAT:
vdir is a directory, with 9 valid entries, but the entries' filenames are "damaged" (instead of the name, 0xE59FF018 is repeated)
vrefs - unknown. inode looks like a inode of a directory. contents - are almost totally zeroed. if it is a directory, it is empty
vfat - a directory, with ONE entry named VFSYS [bingo]. so.. you might have something wrong in your reader - as it was told, your reader reports several files here. maybe you misplaced the directory for vdir somewhere?
--------
to speedup your searches - on the CF122,25mb image you have sent me:
- the contents of VFAT directory are on drive's physical sector
- the direntry for VFSYS file is: {inode=0x00000040, fnlen = 0x0005, unk = 0x0001, {VFSYS\0,} }
- the VFSYS file's inode is on sector
- the VFSYS file's clusters are ... , 100% consecutively :)
on the image the VFSYS file has is 0x30 bytes, as follows:
--- Code: ---Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F
00000000 03 00 B0 00 54 41 46 56 00 00 00 00 00 00 00 00 ..°.TAFV........
00000010 00 00 00 00 00 00 00 00 00 00 00 00 FF FF FF FF ............˙˙˙˙
00000020 00 00 00 00 00 00 00 00 00 00 00 00 FF FF FF FF ............˙˙˙˙
--- End code ---
...small, eh? had construction of the virtualvolume on CF card failed?
-----
to get to the VFSYS file's inode:
- determine raw position of the CFS
- read root directory inode (1 cluster, 64sectors)
- read the two clusters firstclasschain[0] and firstclasschain[1] (2*64 sectors) that contain the root directory
- find VFAT entry
- store te inode numer from that entry
- read that inode
- read the two clusters firstclasschain[0] and firstclasschain[1] (2*64 sectors) that contain the vfat directory
- find VFSYS entry
- store te inode numer from that entry
- read that inode
hurray, you have the file(s)
megaman2000:
excuse me i am new to all of this so i am a noob sorry but i have a issue with building the rockbox.zvmboot file for the 60gb creative xen vision m. i made a 30gb rockbox.zvmboot no problem but the 60gb wont work. this is my first time using linux so just to let you know. if there is any way to post files here i have nk.bin ready for a 30gb zen vision m whoever wants it here is my error if someone can help me i sure would greatly appreciate it.
LD bootloader.elf
/home/user/rockbox/build_creative/firmware/target/arm/tms320dm320/crt0.o: In function 'start_loc':
target/arm/tms320dm320/crt0.S:(.init.text+0x70): undefined reference to 'main'
collect2: ld returned 1 exit status
make[1]: *** [home/user/rockbox/build_creative/bootloader/bootloader.elf] Error 1
make: *** [build] Error 2
mcuelenaere:
--- Quote from: megaman2000 on September 04, 2008, 03:13:10 PM ---excuse me i am new to all of this so i am a noob sorry but i have a issue with building the rockbox.zvmboot file for the 60gb creative xen vision m. i made a 30gb rockbox.zvmboot no problem but the 60gb wont work. this is my first time using linux so just to let you know. if there is any way to post files here i have nk.bin ready for a 30gb zen vision m whoever wants it here is my error if someone can help me i sure would greatly appreciate it.
LD bootloader.elf
/home/user/rockbox/build_creative/firmware/target/arm/tms320dm320/crt0.o: In function 'start_loc':
target/arm/tms320dm320/crt0.S:(.init.text+0x70): undefined reference to 'main'
collect2: ld returned 1 exit status
make[1]: *** [home/user/rockbox/build_creative/bootloader/bootloader.elf] Error 1
make: *** [build] Error 2
--- End quote ---
Sorry about that, I just fixed this in SVN. (do 'svn up')
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version