Messages

316

C1000/3x00 General discussions / Zaurus SL-C3000

« on: October 16, 2004, 04:04:59 pm »

So, I'm interested now in hearing more about the HD in the C3000: what kind is it and can it be upgraded to, say, 30 or 40 GB?  If anyone hears anything regarding this please post what you hear.

The HD is almost certainly a 4GB Hitachi 1" drive. We won't know if it's in the CF card packaging or standalone until someone rips a C3000 apart, but I'm betting it's a CF card. If so, there's a good chance you could upgrade it to a 5GB Seagate but that's currently as far as you can go. To get 30 or 40 GB you need to go to a 1.8" drive and it's doubtful the C3000 went that route.

317

C1000/3x00 General discussions / Zaurus SL-C3000

« on: October 15, 2004, 03:53:07 pm »

More memory is absolutely critical. Take a look at what people in these forums are trying to do with these devices

People in these forums are not, and never have been, the people that Sharp is targeting with the Zaurus. What's hard for enthusiasts to realize is that the vast majority of people who buy PDAs (even high end PDAs like the Zaurus) will never install more than a handful of third party applications. A surprisingly large number (close to 1/3 according to the last survey I read) will never install any third party software.

Needless to say, if the amount of memory included in the device adequately supports the built in apps and the mainstream third party stuff (X and web servers are definitely not mainstream) then why change it? It would mean a hit in cost, possibly component lead times, and definitely power budget (RAM is a big power hog - especially when you look at sleep mode). All that with no tangible benefit for the target consumer would be very bad business strategy.

As much as I would like to see a company making a handheld specifially targeted at the "geek" market, I accepted long ago that such is not Sharp's mission. So who is Sharp targeting with the clamshell models? Not Linux hackers. The clamshell is intended as a mobile office platform for business folks. Think about the built in software suite ... Hancom Word, Hancom Sheet, Hancom Presenter, and a relatively Outlook compatible PIM suite and email client. No terminal app, no real text editor, not even a Java VM on the latest model. It may run Linux but Linux people aren't the target demographic (I wonder if they even include Qtopia Desktop any more?).

For those who Sharp wants to buy the C3000, increasing storage without changing speed or memory makes a lot of sense.

318

General Discussion / Latest rumour on next model

« on: October 15, 2004, 07:59:01 am »

A couple thoughts on some of the points folks have been raising:

Built in HD uses too much power - not necessarily. I have a 4GB Hitachi drive that I keep in the CF slot of my 760 most of the time (I only take it out to use WiFi or Bluetooth) and it has no noticeable impact on battery life unless I use it extensively (playing music or video). CF hard drives have an excellent power saving mode and spin down completely when not being accessed. This works much better than power saving on a standard hard drive because the tiny platter takes very little power and time to spin back up. Combined with the fact that Linux is pretty good at keeping the right stuff cached means that CF disks really work well in the Zaurus without a big battery impact.

Should have had built in wireless - this is a device designed for the Japanese market. If I'm not mistaken, the popular mode of on-the-go internet access there is via DoCoMo's mobile phone network. I don't think there are many Bluetooth enabled DoCoMo phones so built in Bluetooth doesn't make sense. Likewise, market research I've seen shows WiFi for home networking is less prevalent in Japan, so no justification for built in 802.11.

I don't see the C3000 replacing many C series clamshells in the US, but that doesn't mean that Sharp has missed the mark. The C3000 may actually be very well suited to their target market.

319

General Discussion / Rio Carbon MP3 (5 GB Seagate)

« on: October 14, 2004, 07:47:12 am »

If Sandisk's 4GB CF Card is selling at $419, I doubt that Seagate's 5GB CF Microdrive will cost only $150.

Sandisk's 4GB card is a solid state flash memory based card. It uses cutting edge (expensive) high density memory parts that won't get any cheaper until yields and supplies go up. By contrast the Seagate 5GB (and Hitachi 4GB) "microdrives" are not solid state. They are actual miniature hard drives (magnetic storage) complete with spinning platter and moving read/write head. The minaturization takes a hefty manufacturing investment, but once that's done, they should be able to crank them out with a per unit cost not much worse than a regular hard drive. The $150 price point that Seagate has suggested is aggressive, but not unrealistic.

320

Cxx0 Hardware / Does SL-C860 support MMC?

« on: October 09, 2004, 06:50:36 pm »

... and the solutions is as easy as ... for some card you have to use /dev/mmcda not /dev/mmcda1 ... don't ask me why ...

The why is because in some cases you'll find cards formatted without a partition table. Running without a partition table is the norm for floppies but rare on other media. However, there are a few brain damaged devices that will format MMC cards "floppy style" with no partition table. I ran into this same thing a few years back with small capacity CF cards. I found a few that actually came from the manufacturer with a no-partition-table format!

321

General Discussion / SanDisk regular vs Ultra II

« on: October 08, 2004, 07:57:21 am »

I just wonder why big read/write speed difference in all those card (MMC, SanDisk, SanDisk Ultra II) is leveled on Z?

The key is that MMC and SD (in MMC compatibility mode) use a serial interface (data is moved one bit at a time) to get data to and from the card. Contrast that to CF where data is moved one (or two) bytes at a time and you can see that MMC/SD cards are at a significant speed disadvantage. To combat that, the SD spec also defines a "4 bit at a time" mode and faster serial data rates that are not backwards compatible with MMC cards. Special hardware is required to support those features and that hardware is definitely not present in the SL-5000/5500 Zaurii. I don't know about the SL-CXXX series but I'm guessing they're no better off.

Since SD cards in the Zaurus are essentially operating in MMC compatibility mode, the single data path and limited serial data rate pretty much level the playing field. The only area where you may notice significant differences is write speed since that's many times slower than the actual data rate and is driven by the type of flash memory and the programming algorithms in the cards themselves.

322

Software / PDF viewer recommendations?

« on: October 05, 2004, 05:10:34 pm »

I figure if I'm going to go off topic, I might as well do it big  I've relocated my "flash wear" post to its own topic in the Accessories forum (seemed to make sense for flash cards) so it will be easier for folks to find.

And in the interest of getting back on topic ... I too heartily reccommend QPDF2! It's one of the most frequently used apps on my C760. There's nothing like being able to carry dozens of 500+ page technical spec documents everywhere I go

323

Accessories / Wearing out flash memory

« on: October 05, 2004, 04:54:58 pm »

The following is a copy of a post I wrote addressing the question of flash memory "wear". I'm reposting it to it's own topic since it may be of interest to people not following the PDF reader topic (yes, I went a wee bit off-topic  ) where it originated. The original question was whether it's a good idea to routinely use a swapfile on a CF or SD card ...

Flash life is typically between 10K and 100K erase cycles per sector (depending on the flash memory technology used). When data (let's say a byte) is written to flash what really happens is that the chunk of flash (sector) where the byte is to be written first gets read into RAM. The byte in question is then changed in the RAM copy, the sector in the flash is erased back to all zeros (or ones depending on the technology), and then the RAM copy of the sector is programmed back into the flash. As a result, writing 512 contiguous bytes may be done with only a single erase cycle. Writing the same byte 512 times could be as much as 512 erase cycles.

Good flash cards combat wear by using wear leveling techniques. Wear leveling works by spreading the writes out amongst all the free flash sectors. Let's say you have one sector (perhaps in a swapfile) that's getting hit over and over. The logic in the card will actually map that logical sector to a different physical sector each time a write happens. That means that if the life of a sector is 10K cycles and the card has 128M sectors (typical for a 64M card) then the card can theoretically survive 1.28G writes. Now, wear leveling generally only works on "free" sectors so keeping your card 50% full would cut that number in half. Keeping your card 99% full is going to get you back down close to that 10K - 100K number since there are few free sectors to share the erase/write cycles.

When using flash as a file system, data is typically written in big chunks - and only when the user does something. User's aren't very fast (relatively speaking) so this keeps the number of erase cycles to a minimum. When you use a swapfile, the flash can get hammered at much higher rates. Note that Linux will often use the swapfile even with plenty of free RAM available so you don't have much control over the level of activity your swapfile will see. Needless to say, using a swapfile occasionally on a CF or SD card with plenty of free space isn't likely to have a noticeable impact on the life of your card. On the other hand, using a swapfile continuously on a relatively full card could significantly shorten its lifespan.

As for the question of internal memory, the SL-5xxx series use RAM for the internal file system so there are no worries.  The SL-Cxxx series use flash for the internal file system so there *is* a risk of intense activity wearing out the internal flash. And all Zaurii use flash for the operating system but it's typically only erased on a reflash and not too many folks are going to reflash 10K times.

324

Software / PDF viewer recommendations?

« on: October 04, 2004, 09:16:06 am »

That's a known fact about all flash memory... It's only good for a certain number of write/rewrite cycles. I don't know the exact stats, but I've heard it's around 500. I don't believe it affects the Z's internal memory, luckily, but I could be wrong...

Actually, it's between 10K and 100K erase cycles (depending on the flash memory technology used).

See this post for lots more info.

325

Sharp ROMs / New versions of fdisk and e2fsprogs

« on: September 28, 2004, 08:25:59 am »

How do you wipe a FAT clean of its history?

If you want to *really* start over from scratch, you may want to try the following:

Code: [Select]

$ su
# umount /dev/mmcda1
# dd if=/dev/zero of=/dev/mmcda bs=512 count=20480
That last command will overwrite the first 10MiB of the card with zeros, thoroughly destroying what's left of your MSDOS filesystem. Be prepared for the command to take several minutes (i.e. make sure you're running on AC power and have timed power off set to a large timeout).

If the dd command fails to complete, then you have a hardware/driver problem and no amount of fdisk/mkfs work is going to help. If the dd command succeeds, then partitioning/reformatting should work at that point.

326

General Discussion / 4gig cf cards- mount problems

« on: August 05, 2004, 03:36:09 pm »

What was talked about a while back (and I believe what has been done with iPod mini microdrives) is locking the drive firmware into "True-IDE" mode. I'm just speculating that this is what Hitachi has done, but it's consistant with the reported behavior and it's what I'd do if I were the Hitachi engineer tasked with stopping microdrive canibalization.

The CF standard actually defines three different types of card interface: I/O, memory, and True-IDE. The primary difference (without getting into too much detail) is how the 50 physical CF signals are utilized. True-IDE is a remnant of the early PCMCIA days and was designed in to make it easy to build a "glueless" PCMCIA to IDE adapter.

Solid-state CF memory cards and retail microdrives provide both the "memory" and "True-IDE" interfaces. Memory is the simplest so that's what the hardware in most digicams and PDAs is designed to support. True-IDE mode requires some additional hardware logic and a matching device driver. Most laptop PCMCIA controllers support True-IDE, many USB-CF adapters do, very few digicams do, and no StrongARM/Xscale PDAs that I know of do.

So by tweaking the drive's firmware to disable memory mode (but leave True-IDE mode intact), you render the card inoperable in most cameras and PDAs. It will still work fine on a host with True-IDE support - but how many people are going to rip apart a $250 MP3 player just to add a measly 4GB to their PC or laptop?

Don't expect a workaround any time soon as it really is a hardware limitation.

327

General Discussion / 4gig cf cards- mount problems

« on: August 05, 2004, 08:01:26 am »

I'm running a 4GB Hitachi from a Muvo2 (3BA barcode) in a 760 with Cacko 1.21a and I've had zero problems.

I remember hearing a rumor that newer models of the Muvo2 were going to have their drives "tweaked" (locked into true-IDE mode ala iPod mini) to prevent use in digicams (which would also make them incompatible with most PDAs including the Zaurus) but I have no idea if that ever actually happened.

328

General Discussion / dev-img 1.5 install error

« on: August 03, 2004, 01:32:32 pm »

Some Zaurus ROMs don't automatically have a bunch of extra loop devices available.  The good news is that it's not hard to add new ones. Open embeddedkonsole and become root then use the following command to show the available loop devices:

Code: [Select]

ls -l /dev/loop*
If you only see /dev/loop0 and /dev/loop1 that's most likely the problem. Use the following command to create more loop devices:

Code: [Select]

mknod /dev/loopx b 7 x
where x is the next loop device number. So to create /dev/loop2 the command would be:

Code: [Select]

mknod /dev/loop2 b 7 2
You can have up to 8 loop devices (loop0 - loop7). Note that any devices you create this way will stick around until the next reboot - then you'll have to create them again.

329

Software / Experiences running wiki on Zaurii

« on: July 23, 2004, 09:22:12 am »

Note that you can speed up MoinMoin dramatically by using it's built in Python based HTTP server instead of Apache or Boa. Python itself is pretty speedy on the Zaurus, it's just the initial loading of all the various modules when a Python process starts that takes forever.

To do this you need to copy moin_config.py from your moin data dir (usually /usr/share/moin) into $PYTHON_DIR/site-packages/MoinMoin. Edit moin_config.py to make sure all the paths are set up correctly. Then just kick off $PYTHON_DIR/site-packages/MoinMoin/httpdmain.py as a background process.

The MoinMoin Python CGI scripts will execute in the context of the server which conveniently keeps all of the various Python modules cached up. Using that technique MoinMoin page loads (after the very first) usually happen in under 3 seconds.

--
    Dave Kessler