Re: NAND vs SD on GTA02
Gennady Kupava g...@bsdmn.com wrote: Interesting point. I noticed that all my last GSM failures with GTA were related to simple fact that CPU itself were working, but GSM do not because simple battery discharge. The set of Calypso docs I have found and put up on my FTP site (see the other thread) includes a spec for the Iota chip. Iota is the Analog Baseband (ABB) component of the chipset, but it also handles power management. The Iota spec says the minimum battery voltage is 3.0 V. The Rita chip (RF transceiver) also draws some power directly from the battery without going through the Iota, and its spec also says 3.0 V is the minimum. That voltage appears to be the design minimum for Calypso/Iota/Rita phones. In comparison, the PCF50633 which provides power management to the AP (application processor) part of the GTA02 claims to be able to handle Vsys going down to 2.8 V. Hence the Calypso/Iota/Rita block appears to be the limiting factor for how low you can drain the battery and still keep the phone functional (as a phone). Use NAND. Yup, that's my plan. If it wears out in few years, you can just buy one more GTA02 cheap as dirt. Hmm, I wouldn't call $468.46 USD (what I've paid for my GTA02 order, after EUR currency conversion, shipping and international bank transfer fees) exactly dirt cheap. Also you can switch to uSD at any time, so if you NAND will fail, you can just start using uSD. Yes, very true. I hope anyone interested can buy GTA04 soon, so no need to worry about GTA02 stock. For some of us GTA02 is a lot more valuable than GTA04! Am I really the only person left in the world who wants his phone to be a PHONE, not a handheld computer, not a PDA, not a Wifi toy and not a GPS navigation device? For a phone that acts as a *phone*, i.e., stays registered with the cell network while drawing the smallest possible amount of power from its battery, receives incoming calls and SMS on its assigned PSTN number, and allows its user to make outgoing calls and SMS, the part that matters the most is the GSM baseband processor. The whole Linux- based application processor becomes essentially superfluous fluff for a basic phone. For someone who wants his phone to be a phone, free your phone means freeing the GSM baseband processor, nothing less. With the leaked/ liberated Calypso bits I've been finding on that Chinese forum site (hoping to find more...), there is now at least a glimmer of a possibility of freeing a Calypso-based phone down to the GSM RF level. But I don't see how anyone would be able to do that with a modern fully-monolithic UMTS module (GTA04 style) any time soon. MS ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: NAND vs SD on GTA02
On Tuesday 27 September 2011 09:23:17 msoko...@ivan.harhan.org wrote: Use NAND. Yup, that's my plan. If you want to have the system stable NAND is good choice. I never had single filesystem corruption with JFFS2 even after pulling battery. With SD card and ext2/ext3 you will probably hit filesystem corruption after unclean resets. I hope anyone interested can buy GTA04 soon, so no need to worry about GTA02 stock. For some of us GTA02 is a lot more valuable than GTA04! Am I really the only person left in the world who wants his phone to be a PHONE, not a handheld computer, not a PDA, not a Wifi toy and not a GPS navigation device? For a phone that acts as a *phone*, i.e., stays registered with the cell network while drawing the smallest possible amount of power from its battery, receives incoming calls and SMS on its assigned PSTN number, and allows its user to make outgoing calls and SMS, the part that matters the most is the GSM baseband processor. The whole Linux- based application processor becomes essentially superfluous fluff for a basic phone. I can see your point, but if the hardware and power management is done right, you can power off Wifi, GPS and all unused things. Since you will have most of the time phone in suspend, you should care only about power consumed in suspend - which is power drawed by GSM+RAM+PMU. And btw do you think that your phone will draw less battery if you remove web browser from the system? For someone who wants his phone to be a phone, free your phone means freeing the GSM baseband processor, nothing less. With the leaked/ liberated Calypso bits I've been finding on that Chinese forum site (hoping to find more...), there is now at least a glimmer of a possibility of freeing a Calypso-based phone down to the GSM RF level. But I don't see how anyone would be able to do that with a modern fully-monolithic UMTS module (GTA04 style) any time soon. I doubt it is legal and if your phone operator would be happy with hand-made GSM firmware. Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: NAND vs SD on GTA02
Radek Polak pson...@seznam.cz wrote: If you want to have the system stable NAND is good choice. I never had single filesystem corruption with JFFS2 even after pulling battery. With SD card and ext2/ext3 you will probably hit filesystem corruption after unclean resets. Yup, that's what I was thinking too. I can see your point, but if the hardware and power management is done right, you can power off Wifi, GPS and all unused things. Since you will have most of the time phone in suspend, you should care only about power consumed in suspend - which is power drawed by GSM+RAM+PMU. Yup, that's my thinking too. And btw do you think that your phone will draw less battery if you remove web browser from the system? Of course not. However, I prefer to keep the application processor front-end software as simple as possible (in *my* personal sense of simplicity) in order to make it easier for me to tweak it to my peculiar tastes and preferences. I have considered the following question: if I were to succeed in obtaining an illegal copy of the Calypso fw recompilable source, which is what I am really after (i.e., that's what free your phone means to me), do I really need something as fancy as a Neo, or would my needs be better satisfied with something like this: http://bb.osmocom.org/trac/wiki/MotorolaC123 I thought about it, and came to the conclusion that a *simple* Linux-based application processor front-end would be useful even for someone like me: * I would probably have an easier time making the UI look and work exactly the way I want if it's driven by Linux rather than Calypso; * A lot of people with whom I have to interact in my daily life have adopted text/SMS as their primary means of communication, replacing both human voice calls and email. I don't like it, but I need to interact with these people, and making them change their ways is not an option. Therefore, I would like a phone with very powerful SMS handling capabilities. Here's what I have in mind: * I would like to archive *all* sent and received SMS, lots of them. I doubt that doing it the way ancient phones did it (store it all on the SIM I guess?) would cut it; JFFS2 would do the job much better, methinks. * Long messages sent over multiple SMS: my phone needs to be able to receive and reconstitute them at the very least, with full error handling: if only some part(s) arrived, let me see that etc. Would like to be able to send such beasts as well, for communicating with people who don't do email and who would get upset if I actually called them at just the wrong instant... I know there are feature phones (BP only, no AP) that can do it, so I reason it probably *can* be done on the Calypso. But methinks it would be simpler to have the BP view each individual SMS as independent and have the AP handle segmentation and reassembly. * I would like to be able to compose long text messages in vi on my laptop, then inject them into the phone for transmission over USB. * I would like to save the complete log of all sent and received SMS and voice calls in long-term storage outside of the phone, i.e., on a UNIX minicomputer server in my own personal datacenter. In the first version I'll do it indirectly via the laptop (USB between the phone and my laptop, then from the laptop to the mainframe via scp or whatever), but eventually I would like to have the AP wake up on its own once a day or so, establish a circuit-switched data call or GPRS IP connection to my server back in the datacenter, and transfer everything automatically. I doubt it is legal And why should I care? and if your phone operator would be happy with hand-made GSM firmware. How would they know, and how would they enforce it? As long as the phone speaks the exactly correct protocol over the air (which it would if I were to start with a known-working codebase and just tweak it slightly to disable RRLP or whatever), they wouldn't be able to do squat about it. MS ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: NAND vs SD on GTA02
Hi, msoko...@ivan.harhan.org (Michael Sokolov) writes: Hence my question to the community: is the flash wear-out concern I've just outlined the primary reason for the recommendation of using SD instead of NAND to hold the OS/distro, or was that recommendation driven by some other, completely unrelated concerns? I personally prefer SD for these reasons: 1. unlimited space, and you'd need an SD anyway if you want to use OSM and/or Debian 2. ease of maintenance: if you fucked up your config files or kernel and can't boot, just swap it out and fix it in your laptop 3. ease of swapping distros (not applicable to me as i use only Debian) However, the points you raised in your analisys are all valid as it's true that glamo makes SD access slow, and that the power consumption is a bit higher etc. It's just that it doesn't make any difference for me :) As to the distro development, you might want to try NFS root over USB during the active development phase. I can also suggest looking at OpenWrt if you want a solid plain manageable cool base for your distro. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: NAND vs SD on GTA02
Hi, Michael, В Сбт, 24/09/2011 в 00:42 +, Michael Sokolov пишет: Hello again, As I was browsing through the Om community documentation, I saw a note somewhere (I think it was somewhere in the wiki, but I have a hard time finding it again) saying that the native NAND flash on the GTA02 should not be used for anything but the bootloader, and that the OS/distro should live on the micro-SD card instead. No explanation was given as to why. I wonder, would anyone here happen to know the rationale for that recommendation? And does the Om community actually follow that recommendation? Where do most GTA02 users keep their OS/distro: NAND or micro-SD? Community is set of independent people, they may have opposite opinions on some questions, and someone may write his opinion onto wiki. Others may ignore it or even just do not want to contradict person who wrote it. This way you may get anything on wiki. Personally I prefer to add exploration :) Personally I were using mixed NAND/sd environment - just /usr and /home moved to sd. NAND is 100% reliable and much faster (especially with UBI), so it is worth using it. Unless I'm missing an elephant somewhere, my common sense suggests that JFFS2 on the native NAND ought to be much more convenient: SD is a serial bus, and it hangs off the Glamo on the GTA02, whereas the native NAND is, well, native, it's right there inside the MCU. It also seems to me that the native NAND ought to be an outright win in terms of power management: NAND is powered from the IO_1V8 rail which is fed from a switching converter in the PMIC, whereas SD is powered via an HCLDO at 3.3 V. The IO_1V8 supply has to stay on all the time anyway as it keeps the SDRAM in self-refresh, so whatever tiny idle current the NAND draws is going to be the same whether one uses it to store a file system or not. But for the SD one needs 3.3 instead of 1.8 V, the linear regulator is inherently more wasteful than a switcher, and what happens when the battery voltage falls below 3.3 V? If I've read the PMIC datasheet correctly, one ought to be able to keep running a GTA02 on battery until it goes down to almost 2.8 V: I reason it ought to be doable with NAND, but not with SD. Interesting point. I noticed that all my last GSM failures with GTA were related to simple fact that CPU itself were working, but GSM do not because simple battery discharge. May be it is possible to get similar problems with glamo? May be all glamo problems related to power supply? We have very strange glamo init procedure on boot. The only truly valid reason I've been able to come up with for using SD instead of NAND is flash wear concerns. As all good embedded system engineers know, NAND flash is finicky: you've got read disturb, program disturb, and a limited number of erase cycles in each block. Of course the actual physics of NAND flash is exactly the same whether you use it directly or if it's hidden from you behind an interface like SD. The actual magic smoke in those SD cards, USB sticks etc is the exact same NAND which people dislike using directly; the only difference is that with native NAND you as a Linux developer get to implement the necessary algorithms yourself (JFFS2 et al) in a fully visible, free / open source manner, whereas with SD cards etc someone else has done that work, in the form of a closed source circuit which you have no visibility into. I tend to agree with Linux MTD maintainer dwmw2's preference of doing it all yourself with JFFS2 et al. Of course the underlying problem of flash wear exhaustion remains there: no matter how good your flash management algorithms are, eventually the available number of erase/program cycles will be exhausted for more blocks than the maximum number of bad blocks one can tolerate. What do we do then? This concern is the ONLY area where I can see an advantage with SD: once the micro-SD card's flash wear cycles have been exhausted (forgetting for the moment that you can't actually depend on the card reporting this condition to you), you simply throw that card in the trash and get a fresh one. OTOH, if you exhaust the available erase/ program cycles for the NAND flash inside that oddball Samsung chip on the GTA02, getting a replacement chip and getting it swapped out on the board would be problematic. Right, problem is not in layers, but in the fact that internal one is not interchangeable. Hence my question to the community: is the flash wear-out concern I've just outlined the primary reason for the recommendation of using SD instead of NAND to hold the OS/distro, or was that recommendation driven by some other, completely unrelated concerns? Has anyone here actually exhaused the available number of flash erase/program cycles, on any HW platform, ever? (I personally haven't, in my ~10 y of doing embedded Linux work on various systems: I know from the physics and from device datasheets that the
NAND vs SD on GTA02
Hello again, As I was browsing through the Om community documentation, I saw a note somewhere (I think it was somewhere in the wiki, but I have a hard time finding it again) saying that the native NAND flash on the GTA02 should not be used for anything but the bootloader, and that the OS/distro should live on the micro-SD card instead. No explanation was given as to why. I wonder, would anyone here happen to know the rationale for that recommendation? And does the Om community actually follow that recommendation? Where do most GTA02 users keep their OS/distro: NAND or micro-SD? Unless I'm missing an elephant somewhere, my common sense suggests that JFFS2 on the native NAND ought to be much more convenient: SD is a serial bus, and it hangs off the Glamo on the GTA02, whereas the native NAND is, well, native, it's right there inside the MCU. It also seems to me that the native NAND ought to be an outright win in terms of power management: NAND is powered from the IO_1V8 rail which is fed from a switching converter in the PMIC, whereas SD is powered via an HCLDO at 3.3 V. The IO_1V8 supply has to stay on all the time anyway as it keeps the SDRAM in self-refresh, so whatever tiny idle current the NAND draws is going to be the same whether one uses it to store a file system or not. But for the SD one needs 3.3 instead of 1.8 V, the linear regulator is inherently more wasteful than a switcher, and what happens when the battery voltage falls below 3.3 V? If I've read the PMIC datasheet correctly, one ought to be able to keep running a GTA02 on battery until it goes down to almost 2.8 V: I reason it ought to be doable with NAND, but not with SD. The only truly valid reason I've been able to come up with for using SD instead of NAND is flash wear concerns. As all good embedded system engineers know, NAND flash is finicky: you've got read disturb, program disturb, and a limited number of erase cycles in each block. Of course the actual physics of NAND flash is exactly the same whether you use it directly or if it's hidden from you behind an interface like SD. The actual magic smoke in those SD cards, USB sticks etc is the exact same NAND which people dislike using directly; the only difference is that with native NAND you as a Linux developer get to implement the necessary algorithms yourself (JFFS2 et al) in a fully visible, free / open source manner, whereas with SD cards etc someone else has done that work, in the form of a closed source circuit which you have no visibility into. I tend to agree with Linux MTD maintainer dwmw2's preference of doing it all yourself with JFFS2 et al. Of course the underlying problem of flash wear exhaustion remains there: no matter how good your flash management algorithms are, eventually the available number of erase/program cycles will be exhausted for more blocks than the maximum number of bad blocks one can tolerate. What do we do then? This concern is the ONLY area where I can see an advantage with SD: once the micro-SD card's flash wear cycles have been exhausted (forgetting for the moment that you can't actually depend on the card reporting this condition to you), you simply throw that card in the trash and get a fresh one. OTOH, if you exhaust the available erase/ program cycles for the NAND flash inside that oddball Samsung chip on the GTA02, getting a replacement chip and getting it swapped out on the board would be problematic. Hence my question to the community: is the flash wear-out concern I've just outlined the primary reason for the recommendation of using SD instead of NAND to hold the OS/distro, or was that recommendation driven by some other, completely unrelated concerns? Has anyone here actually exhaused the available number of flash erase/program cycles, on any HW platform, ever? (I personally haven't, in my ~10 y of doing embedded Linux work on various systems: I know from the physics and from device datasheets that the number is finite, I just haven't had a personal experience exhausting it.) Just trying to figure out whether I should use NAND or SD to store the OS/distro on my GTA02 (when I get it), and have a rationale for that choice. And if I do end up wearing out the NAND flash in the Samsung ARM chip on my GTA02... Dr. H. Nikolaus Schaller h...@goldelico.com wrote: For us, the GTA02 devices have mostly become sources for plastic parts [...] So when you cannibalize a good GTA02 for its plastic parts (for use with a GTA04 board or whatever), what happens to the good GTA02 PCBA? I hope you don't throw them out, do you? Perhaps those boards could be made available to those hapless GTA02 users who have worn out their NAND flash? Developing a new from-scratch distro generally involves a lot more reloading of the flash than a normal user would do... And while we are on that subject, I wonder, how many of these new-in-box GTA02 devices are still left? At what rate is this legacy stock being depleted? (Unless you consider that
