OESF Portables Forum
Model Specific Forums => Sharp Zaurus => Zaurus - pdaXrom => Topic started by: johnsutton on November 21, 2006, 07:38:33 am
-
There must be a way using dd to cut up the image and then use the loopback device to mount the various parts of the SYSTC100.DBK nand backup image once it is held on another (linux) system. It is just a matter of knowing where to cut it and what type is the filesystem(s), surely?. This would be very handy to be able to fish out the config info from an old system to put back into a newly flashed system. Anybody know how to do it?
-----------------------------------------
Attached script solves this problem for the C1000. Probably fairly easy to adapt for other models.
Ho hum:
THE FOLLOWING ERROR(S) WERE FOUND
Upload failed. You are not permitted to upload a file with that file extension.
So I can't upload it ;-( Tried with .sh and no extension at all. Any ideas?
-----------------------------------------
Succeeded - see post #14
-
On addition, if we know the structure of these files, we can maybe make NAND backups compatible between SL-C1000, SL-C3100 and Sl-C3200.
If I want to duplicate a setup (or restore a C3100 backup on a C3200), I currently have to install the ROM the conservative way, then copy the file structure 1:1 using tar. Using NAND backup files would make it easier and faster and safer.
daniel
-
On addition, if we know the structure of these files, we can maybe make NAND backups compatible between SL-C1000, SL-C3100 and Sl-C3200.
If I want to duplicate a setup (or restore a C3100 backup on a C3200), I currently have to install the ROM the conservative way, then copy the file structure 1:1 using tar. Using NAND backup files would make it easier and faster and safer.
daniel
[div align=\"right\"][a href=\"index.php?act=findpost&pid=146822\"][{POST_SNAPBACK}][/a][/div]
why do you do a NAND backup? restore the NAND of your including your file structure?
Late
-
Here's a script I adapted to strip the error-checking info out of the nand backup file.
After that you are left with a jffs2 image (including all partitions), that can be mounted under linux if you have the right kernel modules installed.
There was a thread a while ago where someone made some changes that split the partitions out into separate files, but I can't seem to find it at the moment.
Daniel, the NAND is a direct copy of the whole flash rom, if the different models have different size flash roms then you won't be able to interchange NAND images.
[ You are not allowed to view attachments ]
Stu
-
Hello Stu
Thanks for the script. I've been trying to modify it for use with my C1000 image but have not succeeded as yet ;-( Some observations and questions:
1) The comments at the top talk about a 64mbyte chip and show some calculations:
# i have a 64mbyte flash (Toshiba TH58512FT
# Manufacture ID: 0x98, Chip ID: 0x76)
# filesize of nand_dump is then:
# 528*4096 +(64*1024*1024) + 16
but these numbers do not correspond to the filesize defined and used later on:
$filesize=138543120/16;
This seems to refer to a 128mbyte flash? But it is 7168 blocks longer than my c1000 image - 138428432.
2) The script treats the image as being made up of 1024 (16byte) blocks followed by 33 blocks of errorcheck info, i.e. 1057 blocks total. However, the filesize value above is an integral number of 1057 blocks plus 1 BUT in addition the first 2 blocks are skipped. This means that the last 1024 block in the file can only be followed by 32 blocks of errorcheck rather than 33?
3) The fact that the first 2 blocks are skipped seems very odd because the first block in my image looks very like the jffs2 fs signature. I say this because I can find 3 of them in the image as a whole:
[root@diva pdaxrom]# strings SYSTC100.DBK | grep JFFS2
JFFS2TOP:
JFFS2TOP:****
JFFS2TOP:
and the first of these is at offset 0. So if I throw away the first 2 blocks (32 bytes) then it looks to me like I am throwing away the fs signature, which surely can't be right?
I'd appreciate any help here!
TIA
John
-
As I said, this is an adapted script. The original script was for a 64Mb nand (C700 I think, but might have been a 5500) so the comments at the start are from the original script, the file size is from the C760/C860 NAND files size.
I've just checked my C1000 NAND size and it's the same as what you report - never noticed that before. Sharp probably changed the layout of the NAND.
Running hexdump on SYSC100.DBK gives
00000000 5b 49 5d 4a 46 46 53 32 54 4f 50 3a 00 00 68 00 |[I]JFFS2TOP:..h.|
00000010 00 00 00 00 5b 47 4c 5d 20 20 20 20 20 20 20 20 |....[GL] |
00000020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
00021020 00 00 02 00 5b 47 4c 5d 20 20 20 20 20 20 20 20 |....[GL] |
Which might explain why I haven't been able to mount the resulting image without errors.
I'll have to see if I can come up with a new script for stripping the C1000 NAND. Hopefully the structure is similar to the previous NANDs.
Stu
-
Stu
Is this idea possible at all? When I try to mount a (would be) jffs2 fs over loopback I get this in the system log:
Nov 24 10:11:46 diva kernel: JFFS2 version 2.1. © 2001 Red Hat, Inc., designed by Axis Communications AB.
Nov 24 10:11:46 diva kernel: jffs2: attempt to mount non-MTD device 07:00
which seems to indicate that unless the jffs2 image is sitting on an appropriate physical medium then it is just not going to work? But your previous posts clearly indicate that you have done exactly this in the past. How? Are there some special options you can pass to the mount so as to force it?
-
Stu
Is this idea possible at all? When I try to mount a (would be) jffs2 fs over loopback I get this in the system log:
Nov 24 10:11:46 diva kernel: JFFS2 version 2.1. © 2001 Red Hat, Inc., designed by Axis Communications AB.
Nov 24 10:11:46 diva kernel: jffs2: attempt to mount non-MTD device 07:00
which seems to indicate that unless the jffs2 image is sitting on an appropriate physical medium then it is just not going to work? But your previous posts clearly indicate that you have done exactly this in the past. How? Are there some special options you can pass to the mount so as to force it?
[div align=\"right\"][{POST_SNAPBACK}][/a][/div] (http://index.php?act=findpost&pid=147157\")
You can't mount a jffs2 image over loopback:
[a href=\"http://www.handhelds.org/hypermail/familiar/62/6232.html]http://www.handhelds.org/hypermail/familiar/62/6232.html[/url]
(I'm sure someone has covered this in the forum here, but I couldn't find it, so the link above is the first one I found with Google...)
-
I wonder what blkmtd.o in cacko does
-
I wonder what blkmtd.o in cacko does
[div align=\"right\"][a href=\"index.php?act=findpost&pid=147261\"][{POST_SNAPBACK}][/a][/div]
I've no idea but I can verify that the recipe contained at the URL posted by karlto does indeeed work (not withstanding some size issue which is probably addressable through an option to one (or more) of the modules concerned). So I am content that the job is doable and am rather hoping that Stu will do the serious legwork of trying to strip out the extraneous info in the nand backup image ;-)
But that sets me wondering... Surely it can only be in Sharp's best interest to enable the likes of us to do this kind of thing, so maybe the proper way to do this is just to contact Sharp and ask them for the tech spec of their backup format?
Are there any formal or informal points of contact between Sharp and the pdaxrom/openzaurus/cacko etc community?
-
But that sets me wondering... Surely it can only be in Sharp's best interest to enable the likes of us to do this kind of thing, so maybe the proper way to do this is just to contact Sharp and ask them for the tech spec of their backup format?
Are there any formal or informal points of contact between Sharp and the pdaxrom/openzaurus/cacko etc community?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=147340\"][{POST_SNAPBACK}][/a][/div]
No, there aren't
Background - I recieved my 5000D directly from the VP of Sharp R&D who was the head of the Z project while he was visiting the telecommunicatinos research institue that I worked for at the time.
An engineer who worked with me who is a big fan of the Z recently contacted that VP. Turns out he's moved on to head the Sharp WZero3 project. Some interesting facts came to light from that conversation:
1) Sharp really had *no* idea what the open source community was about, and no idea why anyone would want the source code in the first place.
2) They picked linux because they just wanted an OS fast, and MS wasn't flexible enough.
3) They consider a Z a glorified Japanese dictionary.
We got in touch with the aide of the current head of the Z project, and found out some more:
4) They aren't interested in working with the community.
5) Further investment in the Z line isn't warranted.
Now, as far as 5 is concerned, I take that to mean that further investment outside of their current roadmap isn't going to happen, not that *no further* invesment is planned. (The aide's English wasn't the best, and my friend is somewhat blunt at the best of times.)
Unfortunately, their roadmap consists of making it a better dictionary, not a better handheld computer.
In short, I doubt we'll get any further useful info out of Sharp.
-
Attached script solves this problem for the C1000. Probably fairly easy to adapt for other models.
Ho hum:
THE FOLLOWING ERROR(S) WERE FOUND
Upload failed. You are not permitted to upload a file with that file extension.
So I can't upload it ;-( Tried with .sh and no extension at all. Any ideas?
-
Append .txt as theextension, then it should work.
Whoever downloads and uses it, has to remove .txt, thoguh.
I'm curious how you have got it working!
And:
What happens if you modify something inside the NAND image and then try to restore (i.e. flash) it?
Does this work? Or is there a CRC check over the NAND image after flashing or something like that?
daniel
-
Append .txt as theextension, then it should work.
Whoever downloads and uses it, has to remove .txt, thoguh.
I'm curious how you have got it working!
And:
What happens if you modify something inside the NAND image and then try to restore (i.e. flash) it?
Does this work? Or is there a CRC check over the NAND image after flashing or something like that?
daniel
[div align=\"right\"][a href=\"index.php?act=findpost&pid=152393\"][{POST_SNAPBACK}][/a][/div]
OK, am trying again with filename mountjffs.txt.
As for your question, the answer is no, because I haven't bothered to work out the checksum scheme. It would not be very difficult to do (I imagine) but I can'r really see the point in it?
What I don't understand is this: where is the "partition table" for the nand flash held? I would think that it is somewhere in the first 7Mb of the flash file, but I couldn't find it ;-( And so you will have to set the size of your root filesystem - called ROOTFS in the script - by hand rather than it being read and set automatically.
-
I'm trying to use your script to mount a nand from a C860 (systc860.dbk), and while the rootfs comes out to 256 (32768/128), the command 'wc -c /dev/mtdblock1' comes up 0. Any suggestions? thks
-
I wonder if this will work for C3100 flash backups... I would love to be able to take a snapshot, do something radical with package installs, and be able to get back to where I was.
-
I'm trying to use your script to mount a nand from a C860 (systc860.dbk), and while the rootfs comes out to 256 (32768/128), the command 'wc -c /dev/mtdblock1' comes up 0. Any suggestions? thks
[div align=\"right\"][a href=\"index.php?act=findpost&pid=152596\"][{POST_SNAPBACK}][/a][/div]
I don't know anything about the 860. Does it have a 128Mb flash same as c1000? If so, you could find the size of the root (which you have above as 256) and then in the same way the size of the "user" partition, and then subtract the sum of those two from 128x8 (= number of 128k blocks in 128Mb) to get the size of the ROMFS.
But this can't work unless your systc860.dbk file is exactly 138428432 bytes, so that is the first thing to check!