OESF Portables Forum
General Forums => General Discussion => Topic started by: DrWowe on May 09, 2004, 04:52:16 pm
-
Well, I finally got around to setting up a cross compiler, instead of doing more important things.
Anyway, I\'ve uploaded a package called mtdtools.tar.gz that contains some nifty things, among them the blkmtd.o kernel driver and various mtd and jffs2 utilities.
WARNING: I used the 6000 kernel sources as a base for the module, and only tested on SL-6000L. YMMV. No warentees or guarentees, and I\'m not responsible if you brick your machine.
If you want to format a block device to use jffs2, here\'s a quick HOWTO. Run these commands from the command line, as root.
First run a little script I whipped up to create additional MTD entries in /dev:
$ sh MakeMoreMTDDevs.sh
Next, load the kernel module, which attaches an MTD device to the specified block device.
$ insmod blkmtd.o device=/dev/mydevice
Since mtd0-3 are used by the internal flash, the device should appear as mtd4. Use dmesg to confirm this. If you do more than one, then you\'ll get mtd5, mtd6, ...
$ dmesg
Now, format your device for jffs2:
$ flash_eraseall -j /dev/mtd4 (be careful here, if you type the wrong number you could hose your internal flash!)
It\'s ready. Now you can mount it:
$ mount /dev/mtdblock4 /mnt/mymountpoint -t jffs2
-
Very cool! How is the performance of JFFS2 formatted SD cards vs ETX2?
-
I plan to do some benchmarking sometime next week. While I\'m at it, I\'m going to compare an MMC with an SD card and see if I can resolve that question. When I get the tools and methodology figured out, I\'ll upload everything so others can post numbers too.
Coming soon: SL-6000
Heh heh heh...
-
Coming soon: SL-6000
Heh heh heh...
Yeah, well, as more and more rough spots get smoothed over, it\'s getting harder to resist...
-
BTW, just wondering, what\'s the typical turnaround time for a submission to the DL area? I submitted this yesterday and it still hasn\'t shown up.
-
There it is:
http://www.zaurususergroup.com/modules.php...date=1084368817 (http://www.zaurususergroup.com/modules.php?op=modload&name=UpDownload&file=index&req=NewDownloadsDate&selectdate=1084368817)
Enjoy.
BTW, if anyone decides to try this on another machine (besides 6000) please post if it works or not. It\'s been my experience that the kernels between various models are pretty much compatible so I can\'t think of any particular reason why it shouldn\'t... but please make backups just to be safe. I think a little caution is prudent when you\'re running tools named \"flash_eraseall\"
-
Which utility functions as an fsck? There are a few deleted or erased blocks appearing in my dmesg that I would like to get rid of. (apparently the current jffs2 will scan, but not clear things out unless they happen to be overwritten)
-
Which utility functions as an fsck? There are a few deleted or erased blocks appearing in my dmesg that I would like to get rid of. (apparently the current jffs2 will scan, but not clear things out unless they happen to be overwritten)
Don\'t know if such thing exists - sorry.
-
Actually, you could probably take care of it by filling your partition with a gibberish and then deleting it. Run df to see how much free space you have, then do:
$ dd if=/dev/urandom of=gibberish bs=1024 count=(free space in KB)
followed by:
$ rm gibberish
-
Actually, you could probably take care of it by filling your partition with a gibberish and then deleting it. Run df to see how much free space you have, then do:
$ dd if=/dev/urandom of=gibberish bs=1024 count=(free space in KB)
followed by:
$ rm gibberish
Another slightly faster and easier way of doing this is:
cp /dev/zero gibberish
rm gibberish
Good work on the JFFS2 stuff BTW, I\'ve always wanted a JFFS2 FS on my SD card but didn\'t know it was possible until now.
Matt
-
I spefically refrained from using /dev/zero, because jffs2 will compress it down and you will wait a very long time.. Stick to urandom.
-
Dr. Wowe,
Any speed comparisons for JFFS2 vs EXT2 on CF/SD cards yet?
-
Hi folks,
Great job! I always thought that this is impossible or at least totally impractical (performance wise).
I have a SL750 and thought to give it a try following your instructions above. When I try to load the blkmtd.o module, I get the following messages in dmesg:
# insmod blkmtd.o device=/dev/mmcda
# dmesg
<snip>
blkmtd: mtd3: [/dev/mmcda] erase_size = 128K
Unable to handle kernel paging request at virtual address ffffffff
pgd = c0004000
*pgd = 00000000, *pmd = 00000000
Internal error: Oops: 0
CPU: 0
pc : [<c004a524>] lr : [<c5ae040c>] Tainted: P
sp : c151df88 ip : c151df9c fp : c151df98
r10: c13d6000 r9 : 00039690 r8 : c5ae1f60
r7 : c5ae1f80 r6 : 00000000 r5 : 00000000 r4 : c151c000
r3 : a0000093 r2 : a0000093 r1 : ffffffff r0 : c151c000
Flags: NzCv IRQs off FIQs on Mode SVC_32 Segment user
Control: 197F Table: A0BA8000 DAC: 00000015 PID: 0
Process tdd (pid: 13359, stackpage=c151d000)
Stack: (0xc151df78 to 0xc151e000)
df60: c5ae040c c004a524
df80: a0000093 ffffffff c151c000 c151dff4 c151df9c c5ae040c c004a4f4 00000000
dfa0: 00000000 c151dfb0 c002e8d4 c003e3b8 c151c000 c151dfbc 00000e00 00000000
dfc0: c151c000 00000000 00000000 00000000 c5ae1da0 00000000 c5ae1f80 c5ae1f60
dfe0: 00039690 c13d6000 00000000 c151dff8 c002fc04 c5ae0374 00000000 00000000
Backtrace:
Function entered at [<c004a4e8>] from [<c5ae040c>]
r4 = C151C000
Function entered at [<c5ae0368>] from [<c002fc04>]
Code: e5843334 e10f2000 e3823080 e121f003 (e5913000)
blkmtd: version 1.9
I tried it with your blkmtd and tried to build one myself, using a crosstool (gcc 2.95.3, glibc 2.2.5) and the
linux-2.4.18-rmk7-pxa3-embedix sources. I get the same error messages with both modules....
Am I missing something here? Did anyone else try this on a 7xx? I am running pdaXrom 1.0.5, btw...
Cheers, Levent
-
Try with the pdaXrom toolchain. It\'s gcc 3.3.2. And don\'t forget to flash your kernel too.
-
Hi!
@amrein: Thanks for your answer. The reason why I used gcc-2.95.3 is that the kernel included was build with (according to /proc/version). I hoped to build the module without flashing the whole kernel.
Do you know where one can get the source and config file for the kernel used in pdaXrom 1.0.5?
Cheers, Levent
-
Me again...
Finally, I did it! Got the pdaXrom kernel source plus patches and config file from a link posted in another thread, build it with my kegel.com gcc-2.95.3/glibc2.2.5 cross chain, copied the blkmtd.o module on my Z, and voila! everything worked as decribed by DrWowe in the first post. Cool! Now I can go ahead and start putting some stuff on my SD card.....
/Levent
-
Glad it worked! It might be useful if you upload your version of blkmtd.o to the files area.
-
Hi!
I just uploaded the module, hope it\'ll show up soon.
/Levent
-
Actually, you could probably take care of it by filling your partition with a gibberish and then deleting it. Run df to see how much free space you have, then do:
$ dd if=/dev/urandom of=gibberish bs=1024 count=(free space in KB)
followed by:
$ rm gibberish
On a 512MB SD card, each of these is taking hours to complete. :shock: Is this consistent with everyone else\'s experience?
(Once rm finishes--tomorrow?--I\'m going to run some jffs2 vs ext2 benchmarks...)
-
As measured by timing the copying of a 10MB gibberish file from internal flash to SD and back again, I\'m getting about 65 KB/sec to write to the SD and 237 KB/sec to read from it.
By comparison, I\'m getting 1078 KB/sec to write to an SD card formatted ext2, and 336 KB/sec to read back from it...
What\'s everybody else\'s experience?