From wolfgang at qi-hardware.com Tue Sep 1 05:11:16 2009 From: wolfgang at qi-hardware.com (Wolfgang Spraul) Date: Tue, 1 Sep 2009 05:11:16 -0400 Subject: [Company] Weekly Operations Update 35/2009 Message-ID: <20090901091116.GA4302@debian> Hi, last week was quiet, for most people summer is more attractive than open whatever, understandably... :-) Still, some important little things were discussed and decided: ---1 dip switch for USB boot First we thought about the USB booting only to make the device totally unbrickable (the CPU supports USB boot). But then we had a discussion last week on the list that some developers might want to stay in that mode for a while, or people might want to operate the device or board in a client-server config. After some back and forth we decided to try a dip switch on Adam's next small run. See what people think, then decide whether to adopt it for the Ya NanoNote. ---2 GUI Talked about Qt vs. GTK and framebuffer vs. X. We believe we first want to optimize this device for CLI - command line interface :-) Yes! lynx as our launcher, and for offline Wikipedia, and other cool apps... We first want to get the peripherals stable, optimize boot time and power consumption, optimize ncurses and lynx. In parallel people can be experimenting with GUIs they like, framebuffer will work, and once the device has more RAM (Ya?) I'm sure everybody can get the GUI they want... ---3 distributors Two distributors showed some initial interest in carrying the NanoNotes, that's a good start and we will continue to work hard to make our device more attractive. If you are interested in carrying it in your country, please come forward. We do want to sell them worldwide, and have as good as possible local shipping and service options. ---4 some FPGA fun The idea of adding a small FPGA chip (Lattice XP2-5 or -8) to a future NanoNote keeps turning heads. So I did some reading and came across this presentation http://www.celinux.org/elc08_presentations/glikely--fpga-lessons-learned.pdf Flip through for some interesting first thoughts on Linux & FPGAs... More next week, some things cooking in certification, prototypes, etc. Wolfgang From yi at qi-hardware.com Tue Sep 1 07:30:00 2009 From: yi at qi-hardware.com (Yi Zhang) Date: Tue, 1 Sep 2009 19:30:00 +0800 Subject: Initial FCC test report Message-ID: <054F41D5-821D-492B-AB04-4EB181D5CE15@qi-hardware.com> Hi All, You can find the initial FCC test report at [1]. It shows that radiation test has failed. The red line is standard. This is not final report yet. Engineers are working on finding solutions which will pass the test yet not cause much changes on board. Yi [1] http://downloads.qi-hardware.com/hardware/certification/ FCC_Test_Report_20090901.pdf From yi at qi-hardware.com Tue Sep 1 09:04:36 2009 From: yi at qi-hardware.com (Yi Zhang) Date: Tue, 1 Sep 2009 21:04:36 +0800 Subject: Initial FCC test report In-Reply-To: <054F41D5-821D-492B-AB04-4EB181D5CE15@qi-hardware.com> References: <054F41D5-821D-492B-AB04-4EB181D5CE15@qi-hardware.com> Message-ID: <9D51395C-D346-489E-B982-712693B9E553@qi-hardware.com> Forgot to mention, our battery has passed CE tests. Yi On 2009-9-1, at ??7:30, Yi Zhang wrote: > Hi All, > > You can find the initial FCC test report at [1]. It shows that > radiation test has failed. The red line is standard. This is not > final report yet. Engineers are working on finding solutions which > will pass the test yet not cause much changes on board. > > Yi > > [1] http://downloads.qi-hardware.com/hardware/certification/ > FCC_Test_Report_20090901.pdf From kzjeef at gmail.com Wed Sep 2 00:32:22 2009 From: kzjeef at gmail.com (ZhangJieJing) Date: Wed, 2 Sep 2009 12:32:22 +0800 Subject: Upstreaming JZ4740 & OpenInkpot In-Reply-To: <87d46ai86i.fsf@vertex.dottedmag.net> References: <87d46ai86i.fsf@vertex.dottedmag.net> Message-ID: Hi, Mikhail, Thanks for your sharing. I'm working on porting jz4740 soc sound card 2.6.31. I've view your kernel tree(based on 2.6.29) and merge some change about soc snd, and port to 2.6.31. my question is: what type soc sound card interface you using i2s or ac97? did the jz's soc sound card works on your board? thanks. --- Best regards, Zhang Jiejing On Tue, Sep 1, 2009 at 3:50 AM, Mikhail Gusarov wrote: > Hello, > > In the course of OpenInkpot[1] development we've cleaned up and rebased > JZ47xx support to 2.6.29.x. Not upstream'ed yet though. Feel free to > take patches from our git[2]. > > It would be nice to share the efforts for pushing the patches upstream - > we have only one kernel developer, and he is kind of busy. We also have > contacted Ingenic developers and they expressed the interest in having > JZ47xx code mainline. > > [1] http://openinkpot.org/ > [2] http://git.openinkpot.org/linux-2.6.git/ > > -- > http://fossarchy.blogspot.com/ > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dottedmag at dottedmag.net Wed Sep 2 05:01:27 2009 From: dottedmag at dottedmag.net (Mikhail Gusarov) Date: Wed, 02 Sep 2009 16:01:27 +0700 Subject: Upstreaming JZ4740 & OpenInkpot In-Reply-To: (ZhangJieJing's message of "Wed, 2 Sep 2009 12:32:22 +0800") References: <87d46ai86i.fsf@vertex.dottedmag.net> Message-ID: <87ocpthg9k.fsf@vertex.dottedmag.net> Twas brillig at 12:32:22 02.09.2009 UTC+08 when kzjeef at gmail.com did gyre and gimble: Z> I'm working on porting jz4740 soc sound card 2.6.31. I've view your Z> kernel tree(based on 2.6.29) and merge some change about soc snd, Z> and port to 2.6.31. Great. Z> my question is: what type soc sound card interface you using i2s or Z> ac97? did the jz's soc sound card works on your board? It's currently TODO, and I'm not really a kernel hacker, so I don't know. According to http://git.openinkpot.org/linux-2.6.git/?a=blob;f=sound/soc/codecs/jzcodec.c;hb=HEAD it should be I2S, but I have no idea what this mean :) -- http://fossarchy.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 834 bytes Desc: not available URL: From wolfgang at qi-hardware.com Wed Sep 2 09:25:24 2009 From: wolfgang at qi-hardware.com (Wolfgang Spraul) Date: Wed, 2 Sep 2009 09:25:24 -0400 Subject: Upstreaming JZ4740 & OpenInkpot In-Reply-To: <87d46ai86i.fsf@vertex.dottedmag.net> References: <87d46ai86i.fsf@vertex.dottedmag.net> Message-ID: <20090902132524.GA2065@debian> Hi Mikhail, thanks a lot for the heads up, openinkpot was already on my radar and someone said I should try to locate 'dottedmag' and 'jekhor' on irc :-) > In the course of OpenInkpot[1] development we've cleaned up and rebased > JZ47xx support to 2.6.29.x. Not upstream'ed yet though. Feel free to > take patches from our git[2]. Wow that's fantastic and very much appreciated here. I just visited Ingenic again today and we are trying to find ways to better support the various development efforts (dingux, openinkpot, nanonote, etc). > It would be nice to share the efforts for pushing the patches upstream - Absolutely! Just a word of caution: It's a huge task. We have to be realistic and patient. At Openmoko, I had a similar upstream kernel effort and I had a phenomenal group of 5+ full-time paid kernel hackers, plus another 5-10 active community contributors. After about 1+ year of intense work, I can say we got somewhere. Had a really stable kernel, got some stuff upstream (more was in the pipeline). Regression testing was still at the beginning. Now with the Ingenic kernel, we are just starting. Lars and Mirko Vogt have done an incredible job the last few weeks. Xiangfu and others are contributing to it. We hope we can unite our efforts with dingux, openinkpot and others (like Yajin Zhou's onda vx747 work). I hope we can convince Ingenic to support us better (working on that). This time I will also focus on automatic regression testing early on, maybe we can reuse some of the Openmoko testing stuff http://git.openmoko.org/?p=gta03-test-suite.git;a=summary So yes, we will take stuff from your git, and you are very welcome to take stuff from our openwrt tree http://projects.qi-hardware.com/index.php/p/openwrt-xburst/source/changes/xburst/ 'Upstream' is a far away goal for me right now, I don't even dream about it at night :-) I'd say 95% of the Ingenic sources will need to be rewritten for that... But it's fantastic you have the motivation to go there, please spread the word that we need more people to help with this, whether it's on the openinkpot or nanonote side. Good to know you are there, I will check out and subscribe to the openinkpot lists asap, Wolfgang On Tue, Sep 01, 2009 at 02:50:48AM +0700, Mikhail Gusarov wrote: > Hello, > > In the course of OpenInkpot[1] development we've cleaned up and rebased > JZ47xx support to 2.6.29.x. Not upstream'ed yet though. Feel free to > take patches from our git[2]. > > It would be nice to share the efforts for pushing the patches upstream - > we have only one kernel developer, and he is kind of busy. We also have > contacted Ingenic developers and they expressed the interest in having > JZ47xx code mainline. > > [1] http://openinkpot.org/ > [2] http://git.openinkpot.org/linux-2.6.git/ > > -- > http://fossarchy.blogspot.com/ > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer From adam at qi-hardware.com Wed Sep 2 11:36:39 2009 From: adam at qi-hardware.com (Adam Wang) Date: Wed, 02 Sep 2009 23:36:39 +0800 Subject: Cleaned up some files of qi_avt2 under downloads Message-ID: <4A9E9107.5080103@qi-hardware.com> Hi, I cleaned up some files on downloads for qi_avt2 folders. The original folders under qi_avt2 folder are moved into "old" folder now. Also uploaded some smt files related avt2 into "v1.0" folder. http://downloads.qi-hardware.com/hardware/qi_avt2/ Adam From cicamargoba at gmail.com Wed Sep 2 19:50:08 2009 From: cicamargoba at gmail.com (Carlos Camargo) Date: Wed, 2 Sep 2009 18:50:08 -0500 Subject: Developer utilities Message-ID: <19ebea720909021650q13803109w628d7d609a8bcfca@mail.gmail.com> Hi My Ben has arrived yesterday, thanks a lot guys for this new toy, Is really nice, I was waiting for a bigger device, but ben is very thin and cute. At present I'm working in build the tools, u-boot, kernel, and openwrt. I'm working on my board ECB_4725, I'm using the available tools at [1]. I can build and upload u-boot and the kernel image using usbboot tool, and I get a kernel panic :). You can see some pictures of this simple board in [2], Is a very cheap 2 layer boards, but we can develop many interesting applications on It, Coming soon I will create one page on [1] for this board. I have some observations about the new Qi and the Ben nano. 1. From the kernel and u-boot developers point of view will be usefull, if we have access to a RS232 interface, as Wolfgang said some days ago, many software people don't have the technical background for make a pcb for a rs232-3.3V converter. 2. I don't like the usboot connection on ben, I think that the switch added for Adam is better for this option. [1] http://projects.qi-hardware.com/ [2] http://downloads.qi-hardware.com/hardware/hacking/ECB_4725.jpg Best Regards -- Carlos Iv?n Camargo Bare?o Profesor Asistente Departamento de Ingenier?a El?ctrica y Electr?nica Universidad Nacional de Colombia cicamargoba at unal.edu.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From cicamargoba at gmail.com Thu Sep 3 07:38:01 2009 From: cicamargoba at gmail.com (Carlos Camargo) Date: Thu, 3 Sep 2009 06:38:01 -0500 Subject: Ben NanoNote Internals Message-ID: <19ebea720909030438k6dbe8036n6826c325ccde0ffd@mail.gmail.com> Hi Here [1] you can find some photos of Ben. http://downloads.qi-hardware.com/hardware/Photos/ Carlos -- Carlos Iv?n Camargo Bare?o Profesor Asistente Departamento de Ingenier?a El?ctrica y Electr?nica Universidad Nacional de Colombia cicamargoba at unal.edu.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From wolfgang at qi-hardware.com Fri Sep 4 02:11:07 2009 From: wolfgang at qi-hardware.com (Wolfgang Spraul) Date: Fri, 4 Sep 2009 02:11:07 -0400 Subject: Ben NanoNote Internals In-Reply-To: <19ebea720909030438k6dbe8036n6826c325ccde0ffd@mail.gmail.com> References: <19ebea720909030438k6dbe8036n6826c325ccde0ffd@mail.gmail.com> Message-ID: <20090904061107.GA3543@debian> Carlos, > http://downloads.qi-hardware.com/hardware/Photos/ Yes! Thanks a lot. Our cute little NanoNote in Colombia, very cool... I scaled all pictures to 800x600 for easier and faster viewing on screen, hope you don't mind. Also, I was looking for a nice directory indexing option to auto-generate thumbnails, but couldn't find anything. Some PHP solutions exist... On a related issue, we had our second server outage yesterday, this time for a total of 2 hr and 25 minutes :-( We knew about the crash within minutes, but it took that long to restart the machine... We are currently working on moving to a bigger dedicated server. Unfortunately since we don't know the root cause of the crash yet, there may be more outages until we have it all under control. Bear with us, thanks for your patience... Wolfgang On Thu, Sep 03, 2009 at 06:38:01AM -0500, Carlos Camargo wrote: > Hi > Here [1] you can find some photos of Ben. > > http://downloads.qi-hardware.com/hardware/Photos/ > > Carlos > > > -- > Carlos Iv?n Camargo Bare?o > Profesor Asistente > Departamento de Ingenier?a El?ctrica y Electr?nica > Universidad Nacional de Colombia > cicamargoba at unal.edu.co > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer From wijnen at debian.org Fri Sep 4 14:10:21 2009 From: wijnen at debian.org (Bas Wijnen) Date: Fri, 4 Sep 2009 20:10:21 +0200 Subject: Ben NanoNote Internals In-Reply-To: <19ebea720909030438k6dbe8036n6826c325ccde0ffd@mail.gmail.com> References: <19ebea720909030438k6dbe8036n6826c325ccde0ffd@mail.gmail.com> Message-ID: <20090904181021.GC15406@a82-93-13-222.adsl.xs4all.nl> Hi, On Thu, Sep 03, 2009 at 06:38:01AM -0500, Carlos Camargo wrote: > http://downloads.qi-hardware.com/hardware/Photos/ On the photos I don't see a switch to detect if the device is open or closed. Does it have one? (My device hasn't arrived yet, so I can't check.) Possibly the best feature of the GMate Yopy was that it would switch on by opening the device, and auto-suspend by closing it (except when music was playing). If this is not possible on the Ben, I suggest it as a feature for the Ya. :-) If there are no other options, I would sacrifice a key from the keyboard for it. But I don't know if that will work: it must be able to send a power-on signal to the device. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From cicamargoba at gmail.com Fri Sep 4 23:03:55 2009 From: cicamargoba at gmail.com (Carlos Camargo) Date: Fri, 4 Sep 2009 22:03:55 -0500 Subject: board-qi-avt2 Message-ID: <19ebea720909042003u13f98c42v70274ae97aa3a98b@mail.gmail.com> Hi I've already upload some new files to board-qi-avt2 project. There is a .brd file with the components in place and the board outline. But, as you will see, there are many labels on each component, and we don't know how edit to resize or move. Can help us with that? Best Regards Carlos -- Carlos Iv?n Camargo Bare?o Profesor Asistente Departamento de Ingenier?a El?ctrica y Electr?nica Universidad Nacional de Colombia cicamargoba at unal.edu.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From cicamargoba at gmail.com Fri Sep 4 23:57:12 2009 From: cicamargoba at gmail.com (Carlos Camargo) Date: Fri, 4 Sep 2009 22:57:12 -0500 Subject: Pcb secifications Message-ID: <19ebea720909042057w6319c653uc1956e711c24a86@mail.gmail.com> Hi Adam Can you send me the board specs? I mean: Min trace width, annular ring, number of layers, via drill, etc, etc, We want to start the routing process, and we need this information. Thanks Carlos -- Carlos Iv?n Camargo Bare?o Profesor Asistente Departamento de Ingenier?a El?ctrica y Electr?nica Universidad Nacional de Colombia cicamargoba at unal.edu.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at qi-hardware.com Sat Sep 5 01:49:24 2009 From: adam at qi-hardware.com (Adam Wang) Date: Sat, 5 Sep 2009 13:49:24 +0800 Subject: Pcb secifications In-Reply-To: <19ebea720909042057w6319c653uc1956e711c24a86@mail.gmail.com> References: <19ebea720909042057w6319c653uc1956e711c24a86@mail.gmail.com> Message-ID: Hi Carlos, The all the requirements of qi_avt2 I uploaded to [1] for pcb file, [2] for jz4720 COB fingers, [3] for gerber file Since those can be openned by PADS, there're having more detail things you can get. Also includes drill, etc. Thanks, Adam [1] http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/pcb/ [2] http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/pcb/cob/ [3] http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/gerber/ On Sat, Sep 5, 2009 at 11:57 AM, Carlos Camargo wrote: > Hi Adam > > Can you send me the board specs? I mean: Min trace width, annular ring, > number of layers, via drill, etc, etc, We want to start the routing process, > and we need this information. > > Thanks > > Carlos > > > -- > Carlos Iv?n Camargo Bare?o > Profesor Asistente > Departamento de Ingenier?a El?ctrica y Electr?nica > Universidad Nacional de Colombia > cicamargoba at unal.edu.co > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at qi-hardware.com Sat Sep 5 02:04:32 2009 From: adam at qi-hardware.com (Adam Wang) Date: Sat, 5 Sep 2009 14:04:32 +0800 Subject: Ben NanoNote Internals In-Reply-To: <20090904181021.GC15406@a82-93-13-222.adsl.xs4all.nl> References: <19ebea720909030438k6dbe8036n6826c325ccde0ffd@mail.gmail.com> <20090904181021.GC15406@a82-93-13-222.adsl.xs4all.nl> Message-ID: Hi Bas, On Sat, Sep 5, 2009 at 2:10 AM, Bas Wijnen wrote: > Hi, > > On Thu, Sep 03, 2009 at 06:38:01AM -0500, Carlos Camargo wrote: > > http://downloads.qi-hardware.com/hardware/Photos/ > > On the photos I don't see a switch to detect if the device is open or > closed. Does it have one? (My device hasn't arrived yet, so I can't > check.) Possibly the best feature of the GMate Yopy was that it would > switch on by opening the device, and auto-suspend by closing it (except > when music was playing). > > If this is not possible on the Ben, I suggest it as a feature for the > Ya. :-) If there are no other options, I would sacrifice a key from the > keyboard for it. But I don't know if that will work: it must be able to > send a power-on signal to the device. > > The Ben doesn't have detect switch if device is open or close, but it's a great feature for the YA. Adam > Thanks, > Bas > > -- > I encourage people to send encrypted e-mail (see http://www.gnupg.org). > If you have problems reading my e-mail, use a better reader. > Please send the central message of e-mails as plain text > in the message body, not as HTML and definitely not as MS Word. > Please do not use the MS Word format for attachments either. > For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkqhWAwACgkQFShl+2J8z5UhjwCgyZdV3DeXfaSCY+wOfQ2s7k7W > 8UEAoMwicZACE2ipG4hE4jVRMadiL7Ye > =3iLg > -----END PGP SIGNATURE----- > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wijnen at debian.org Sun Sep 6 06:28:33 2009 From: wijnen at debian.org (Bas Wijnen) Date: Sun, 6 Sep 2009 12:28:33 +0200 Subject: Iris source is online Message-ID: <20090906102832.GA19362@a82-93-13-222.adsl.xs4all.nl> Hello, Previously I wrote that the source for my kernel, Iris, would be put on savannah.nongnu.org. However, they still haven't responded to my request. Furthermore, I decided to target not only the Trendtac, but also the NanoNote. That made it logical to host the sources on the server of the makers of that device, http://www.qi-hardware.com. The sources can be found under the projects link from the menu bar at the top. Under the report directory there is a full explanation for how to build them, including how to set up a cross-compiler. I tried to make it all as simple as possible, but suggestions for improvement are very welcome.[0] The current sources build an uimage which can run on the Trendtac. Porting to the NanoNote will be done when I receive that device. It has a working lcd framebuffer driver, leds, keyboard and touchpad buttons. The current system sets up the drivers and waits for events. Key presses are signaled by sending a character to the screen; touchpad button events by changing the leds. In other words, it demonstrates that the device drivers are working. I defined several interfaces for device types. Any program can provide such an interface, and behave as such a device. Next steps are to make the current drivers follow the interfaces (as far as they don't yet), to make more drivers, in particular something with a filesystem, and to allow the user to start programs. Comments (and help) are much appreciated. Thanks, Bas [0] I realize that the build process would be much easier if I would package libshevek and pypp, which are build-dependencies. However, I don't currently want to invest the time that would be required for making sure the packaging is done right (especially for libshevek). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From yi at qi-hardware.com Sun Sep 6 11:30:13 2009 From: yi at qi-hardware.com (Yi Zhang) Date: Sun, 6 Sep 2009 23:30:13 +0800 Subject: new location for sources Message-ID: <43127190-8D9F-4481-A299-DAB85D225B7E@qi-hardware.com> All, In case some of you didn't know yet, all of our sources (software and hardware) have been moved to [1]. Yi [1] http://projects.qi-hardware.com/ From xiangfu at qi-hardware.com Sun Sep 6 21:37:41 2009 From: xiangfu at qi-hardware.com (Xiangfu Liu) Date: Mon, 07 Sep 2009 09:37:41 +0800 Subject: configure mpd/mpc in openwrt. music player in Ben NanoNote Message-ID: <4AA463E5.5090802@qi-hardware.com> 1. in terminal, under openwrt folder run $ scripts/feeds install mpd $ scripts/feeds install mpc 2. run [make menuconfig] then select --> sound --> enable [mpc] [mpd] 3. run [make menuconfig] --> Base System --> enable [libstdcpp] then you run make. you will get the [mpd] [mpc] in you rootfs. you need change the [/etc/mpd.conf] to make the mpd work. From xiangfu at qi-hardware.com Sun Sep 6 21:48:05 2009 From: xiangfu at qi-hardware.com (Xiangfu Liu) Date: Mon, 07 Sep 2009 09:48:05 +0800 Subject: Software Status Message-ID: <4AA46655.3040007@qi-hardware.com> Hi the software status, the tasks I think are not finished. feel free to give advice on this. Bootloader: boot menu boot from nand boot from SD card we think about the u-boot. it's big and functionally. we want use a most simple one. just load the kernel and boot. what do you think about this? keep u-boot or replace u-boot? the new bootloader we want 1-[boot from nand] 2-[boot from SD-card] 3-[easy to configure kernel cmdline] 4-[easy choose 1 or 2] Kernel: usb subsystem not test sound driver lcd have some bug. the display is not correct keyboard, some combination key not work poweron/off key not work suspend system. auto poweroff. Rootfs: add mpd/mpc audio player, not test since sound driver not work. From xiangfu.z at gmail.com Sun Sep 6 22:50:04 2009 From: xiangfu.z at gmail.com (Xiangfu Liu) Date: Mon, 07 Sep 2009 10:50:04 +0800 Subject: (matrix_keypad driver) Re: qi_lb60_keypad driver question? In-Reply-To: <20090901021034.6117F526EA5@mailhub.coreip.homeip.net> References: <4A819D39.2040006@qi-hardware.com> <20090812024620.E4E10526EC9@mailhub.coreip.homeip.net> <4A9AA392.4060301@gmail.com> <20090901021034.6117F526EA5@mailhub.coreip.homeip.net> Message-ID: <4AA474DC.9010509@gmail.com> Hi Dmitry Dmitry Torokhov wrote: > Hi, > Historically our KEY_* definitions did not include defines for symbols > like '@' because they do not have a dedicated key but rather being > produced as a combination of a primary key + modifier; the mapping is > done either in console driver or in X. > > Looking at the picture of the device that you provided it appears that > your device does not have a dedicated '@' key so it should work in the > same fashion as above. > since we don't have X now. I google about this. I don't know how to modify the console driver. can you tell me which file I need look into? thanks. I found an another method. we use busybox in rootfs. the busybox have command [dumpkmap] [loadkmap] [showkey], ----------- in host system run : /usr/bin/dumpkeys > normal_keymap /usr/bin/loadkeys funky_mini_keyboard_keymap /usr/bin/busybox dumpkmap > funky_mini_keyboard_keymap.bin /usr/bin/loadkeys normal_keymap then in target system run "loadkmap funky_mini_keyboard_keymap.bin" ----------- in our device have a two special keys [RED UP POINT] keycode is 94 [QI] keycode is 93 the loadkeys alwasy like: compose '|' 's' to '$' how to write the keycode to the loadkeys file. I just found this method yesterday. not test yet. anyone have experience on this? thanks for advice -- Best Regards Xiangfu Liu Email: xiangfu at qi-hardware dot com Web: http://www.qi-hardware.com From mirko at qi-hardware.com Mon Sep 7 01:01:38 2009 From: mirko at qi-hardware.com (Mirko Lindner) Date: Mon, 7 Sep 2009 07:01:38 +0200 Subject: Iris source is online In-Reply-To: <20090906102832.GA19362@a82-93-13-222.adsl.xs4all.nl> References: <20090906102832.GA19362@a82-93-13-222.adsl.xs4all.nl> Message-ID: <11ac140a0909062201g2eb80751k40e83c53e9761f0a@mail.gmail.com> Hey Bas, hey lists, I just wanted to take this opportunity to say that we are very happy about Iris being hosted on qi-hardware. We are looking forward to seeing Iris run on the NanoNote and add another piece in the big puzzle of Copyleft Hardware. I also want to invite everyone to tell us about his/her mips project on the Qi Hardware list [1] or join one of the Qi hosted projects such as Iris[2] or our OpenWrt effort [3]. Let's do this, /mirko [1] http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer [2] http://projects.qi-hardware.com/index.php/p/iris/ [3] http://projects.qi-hardware.com/index.php/p/openwrt-xburst/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiangfu.z at gmail.com Mon Sep 7 05:48:54 2009 From: xiangfu.z at gmail.com (Xiangfu Liu) Date: Mon, 07 Sep 2009 17:48:54 +0800 Subject: need help on lcd driver. Message-ID: <4AA4D706.9030400@gmail.com> Hi there is something wrong with our lcd driver. I don't know how to fix this. you can see the picture[1] the pixels not in line. and the color also not correct. here is our source code is at [2] thanks for any advice [1] http://www.openmobilefree.net/other/file/lcm_pixels.jpg [2] http://projects.qi-hardware.com/index.php/p/openwrt-xburst/source/tree/xburst/target/linux/xburst/patches-2.6.31 -- Best Regards Xiangfu Email: xiangfu at qi-hardware dot com Web: http://www.qi-hardware.com From xiangfu at qi-hardware.com Mon Sep 7 06:13:27 2009 From: xiangfu at qi-hardware.com (Xiangfu Liu) Date: Mon, 07 Sep 2009 18:13:27 +0800 Subject: need help on lcd driver. In-Reply-To: <4AA4D706.9030400@gmail.com> References: <4AA4D706.9030400@gmail.com> Message-ID: <4AA4DCC7.1020406@qi-hardware.com> Xiangfu Liu wrote: > Hi > there is something wrong with our lcd driver. > I don't know how to fix this. you can see the picture[1] > the pixels not in line. and the color also not correct. > > here is our source code is at [2] > thanks for any advice > > > [1] http://www.openmobilefree.net/other/file/lcm_pixels.jpg > [2] http://projects.qi-hardware.com/index.php/p/openwrt-xburst/source/tree/xburst/target/linux/xburst/patches-2.6.31 > if you can not open [1] try this: http://downloads.qi-hardware.com/software/reports/lcm_pixels.jpg From rjeffries at gmail.com Mon Sep 7 12:21:38 2009 From: rjeffries at gmail.com (Ron K. Jeffries) Date: Mon, 7 Sep 2009 09:21:38 -0700 Subject: Iris source is online In-Reply-To: <11ac140a0909062201g2eb80751k40e83c53e9761f0a@mail.gmail.com> References: <20090906102832.GA19362@a82-93-13-222.adsl.xs4all.nl> <11ac140a0909062201g2eb80751k40e83c53e9761f0a@mail.gmail.com> Message-ID: <886128c30909070921q46070a63o7109632090e31451@mail.gmail.com> When will the OpenWrt for Ben Nanonote be ableto run the Lua scripting language? --- Ron K. Jeffries On Sun, Sep 6, 2009 at 22:01, Mirko Lindner wrote: > Hey Bas, hey lists, > > I just wanted to take this opportunity to say that we are very happy about > Iris being hosted on qi-hardware. > We are looking forward to seeing Iris run on the NanoNote and add another > piece in the big puzzle of Copyleft Hardware. > > I also want to invite everyone to tell us about his/her mips project on the > Qi Hardware list [1] or join one of the Qi hosted projects such as Iris[2] > or our OpenWrt effort [3]. > > Let's do this, > > /mirko > > [1] http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > [2] http://projects.qi-hardware.com/index.php/p/iris/ > [3] http://projects.qi-hardware.com/index.php/p/openwrt-xburst/ > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at nanl.de Mon Sep 7 13:15:16 2009 From: lists at nanl.de (Mirko Vogt) Date: Mon, 07 Sep 2009 19:15:16 +0200 Subject: Iris source is online In-Reply-To: <886128c30909070921q46070a63o7109632090e31451@mail.gmail.com> References: <20090906102832.GA19362@a82-93-13-222.adsl.xs4all.nl> <11ac140a0909062201g2eb80751k40e83c53e9761f0a@mail.gmail.com> <886128c30909070921q46070a63o7109632090e31451@mail.gmail.com> Message-ID: <1252343716.22690.1732.camel@mia> On Mon, 2009-09-07 at 09:21 -0700, Ron K. Jeffries wrote: > When will the OpenWrt for Ben Nanonote be able > to run the Lua scripting language? Actually - now. Just enable lua in OpenWrt's to select the lua-interpreter and therefore include it into the resulting rootfs-image. mirko > > --- > Ron K. Jeffries > > > > > > > > > > On Sun, Sep 6, 2009 at 22:01, Mirko Lindner > wrote: > Hey Bas, hey lists, > > I just wanted to take this opportunity to say that we are very > happy about Iris being hosted on qi-hardware. > We are looking forward to seeing Iris run on the NanoNote and > add another piece in the big puzzle of Copyleft Hardware. > > I also want to invite everyone to tell us about his/her mips > project on the Qi Hardware list [1] or join one of the Qi > hosted projects such as Iris[2] or our OpenWrt effort [3]. > > Let's do this, > > /mirko > > [1] > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > [2] http://projects.qi-hardware.com/index.php/p/iris/ > [3] > http://projects.qi-hardware.com/index.php/p/openwrt-xburst/ > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer -- This email address is used for mailinglist purposes only. Non-mailinglist emails will be dropped automatically. If you want to get in contact with me personally, please mail to: mirko.vogt nanl de From cicamargoba at gmail.com Mon Sep 7 18:58:13 2009 From: cicamargoba at gmail.com (Carlos Camargo) Date: Mon, 7 Sep 2009 17:58:13 -0500 Subject: qi-avt2 new features Message-ID: <19ebea720909071558t469942fbt946ae1b887ca9be1@mail.gmail.com> I was thinking about new qi-avt2 features, specially power consumption and SDRAM memory size. 1. The current design qi-avt2 use a keyboard that use a whole layer, We will use this space if we use a capacitive keyboard with a cypress controller, In the past we use [1], with our ARM board and we program the cypress chip with the processor GPIOs. Whit this, we have enough space to place another SDRAM chip on qi-avt2, and we will have up to 128MB of SDRAM, enough for many applications. 2. I prefer use a light sensor for controlling the LCD brightness and detect if the device is close. 3. I was thinking in the possible use of a FPGA in the design, I think that this FPGA would provide some peripherals like PWMs, for servo controlling, There are an open project that we can use with it [2]. Or drive an analog acquisition card for experiments like [3] [1] http://m8cutils.sourceforge.net/ [2] http://playerstage.sourceforge.net/ [3] http://www.vernier.com/physics/ Carlos -- Carlos Iv?n Camargo Bare?o Profesor Asistente Departamento de Ingenier?a El?ctrica y Electr?nica Universidad Nacional de Colombia cicamargoba at unal.edu.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From cicamargoba at gmail.com Mon Sep 7 19:30:35 2009 From: cicamargoba at gmail.com (Carlos Camargo) Date: Mon, 7 Sep 2009 18:30:35 -0500 Subject: configure mpd/mpc in openwrt. music player in Ben NanoNote In-Reply-To: <4AA463E5.5090802@qi-hardware.com> References: <4AA463E5.5090802@qi-hardware.com> Message-ID: <19ebea720909071630t1a680beexf5d62ec2084090ba@mail.gmail.com> Hi We are trying to test the sound driver, with alsa, mplayer, but doesn't work :( The Qi kernel source support the JZ sound driver? If not, where can I foun information about this driver? $ scripts/feeds install mpd $ scripts/feeds install mpc I try to run this command but I get the following error: Ignoring feed 'packages' - index missing Ignoring feed 'xwrt' - index missing Ignoring feed 'luci' - index missing WARNING: No feed for package 'mpd' found, maybe it's already part of the standard packages? Carlos On Sun, Sep 6, 2009 at 8:37 PM, Xiangfu Liu wrote: > > 1. in terminal, under openwrt folder run > > 2. run [make menuconfig] then select --> sound --> enable [mpc] [mpd] > 3. run [make menuconfig] --> Base System --> enable [libstdcpp] > > then you run make. you will get the [mpd] [mpc] in you rootfs. > you need change the [/etc/mpd.conf] to make the mpd work. > > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -- Carlos Iv?n Camargo Bare?o Profesor Asistente Departamento de Ingenier?a El?ctrica y Electr?nica Universidad Nacional de Colombia cicamargoba at unal.edu.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiangfu at qi-hardware.com Mon Sep 7 21:38:24 2009 From: xiangfu at qi-hardware.com (Xiangfu Liu) Date: Tue, 08 Sep 2009 09:38:24 +0800 Subject: configure mpd/mpc in openwrt. music player in Ben NanoNote In-Reply-To: <19ebea720909071630t1a680beexf5d62ec2084090ba@mail.gmail.com> References: <4AA463E5.5090802@qi-hardware.com> <19ebea720909071630t1a680beexf5d62ec2084090ba@mail.gmail.com> Message-ID: <4AA5B590.5000000@qi-hardware.com> Carlos Camargo wrote: > Hi > > We are trying to test the sound driver, with alsa, mplayer, but doesn't > work :( The Qi kernel source support the JZ sound driver? If not, where > can I foun information about this driver? the Qi kernel not support JZ sound driver not. Jieijing Zhang and larsc work on that. you can find the Jieijing Zhange sound code: http://projects.qi-hardware.com/index.php/p/kzjeef-kernel/source/changes/master/ you can find JZ 2.6.27 sound driver at: http://downloads.qi-hardware.com/software/sources/linux-2.6.27.git.svn.tgz > > > $ scripts/feeds install mpd > $ scripts/feeds install mpc run 'scripts/feeds update' before install mpd/mpc. > > I try to run this command but I get the following error: > > Ignoring feed 'packages' - index missing > Ignoring feed 'xwrt' - index missing > Ignoring feed 'luci' - index missing > WARNING: No feed for package 'mpd' found, maybe it's already part of the > standard packages? > > > > Carlos > > > > On Sun, Sep 6, 2009 at 8:37 PM, Xiangfu Liu > wrote: > > > 1. in terminal, under openwrt folder run > > > > 2. run [make menuconfig] then select --> sound --> enable [mpc] [mpd] > 3. run [make menuconfig] --> Base System --> enable [libstdcpp] > > then you run make. you will get the [mpd] [mpc] in you rootfs. > you need change the [/etc/mpd.conf] to make the mpd work. > From lists at nanl.de Mon Sep 7 11:15:38 2009 From: lists at nanl.de (Mirko Vogt) Date: Mon, 07 Sep 2009 17:15:38 +0200 Subject: some updates "from behind the scenes" Message-ID: <1252336538.22690.1601.camel@mia> Hello qi! :) Long time no news, but now some updates - as Wolfgang said: "from behind the scenes"; what happened on "our" side in keywords. == Hardware We got new prototypes with 2 GB NAND / new LCM - some things we noticed (some amy not be relevant - but wanted to have them mentioned): - as Xiang Fu already mentioned, parts of the display are partially hidden by the case (in my case - the first pixel-column on the left respective the first pixel-row on the bottom). - the qi-hardware-bezels on top are not really fixed [1] - the new LCM switches on (and is fading into white) when going into USB-boot-mode (the AUO didn't) - the new prototype makes weird high-frequency sounds when connected to the serial console but not to power - when power-cycling the NanoNote too fast (which happens for me when I flashed and now wanna try it out which results in plugging usb out and in) it does not react anymore at all - you have to remove power several seconds to get it booting again - keyboard and serial-console are partially sharing their pins, so for now _either_ the full keyboard can be used _or_ the serial console - the NAND (old and new one) can be erased 5k times - in contrast the NAND-chip within the Openmoko Freerunner has about 100k erase-cycles == Software - OpenWrt is (still) running (with a really nice bootsplash - made with love and passion [2]) - still having the "boot-reliable-from-sdcard"-issues - 1GB as well as 2GB NAND chips are working - display- and framebuffer driver are written from scratch and working - keyboard is working in general (however we experienced some kbd-issues with recent A1-devices - key-combinations to get special characters inserted needs some more work, too) - you have to erase the NAND ( in u-boot will do the job) before flashing a jffs2-image (this may either be fixed in jffs2-code or getting the flash-tools to erase the blocks after the jffs2-EOF-marker) - also there exist some more ECC-problems == misc - Ignacio should have got a Ben NanoNote - have fun! :) Hopefully you can help us with getting this sd-card-issue fixed These were just a few keywords - in case you want some more verbose output please let us know :) Happy hacking! mirko (vogt) [1] attachment: ben_qi-hardware-bezels.jpg [2] attachment: ben_openwrt.jpg -- This email address is used for mailinglist purposes only. Non-mailinglist emails will be dropped automatically. If you want to get in contact with me personally, please mail to: mirko.vogt nanl de -------------- next part -------------- A non-text attachment was scrubbed... Name: ben_openwrt.jpg Type: image/jpeg Size: 100892 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ben_qi-hardware-bezels.jpg Type: image/jpeg Size: 57516 bytes Desc: not available URL: From yi at qi-hardware.com Tue Sep 8 02:48:01 2009 From: yi at qi-hardware.com (Yi Zhang) Date: Tue, 8 Sep 2009 14:48:01 +0800 Subject: some updates "from behind the scenes" In-Reply-To: <1252336538.22690.1601.camel@mia> References: <1252336538.22690.1601.camel@mia> Message-ID: <6ADE4A09-FFBE-4789-B4EA-73B127873C11@qi-hardware.com> Mirko, On 2009-9-7, at ??11:15, Mirko Vogt wrote: > - the new LCM switches on (and is fading into white) when going into > USB-boot-mode (the AUO didn't) Does LCD remain white, or does it go back to normal after LCD driver has loaded? Yi From wolfgang at qi-hardware.com Tue Sep 8 08:48:50 2009 From: wolfgang at qi-hardware.com (Wolfgang Spraul) Date: Tue, 8 Sep 2009 08:48:50 -0400 Subject: some updates "from behind the scenes" In-Reply-To: <1252336538.22690.1601.camel@mia> References: <1252336538.22690.1601.camel@mia> Message-ID: <20090908124639.GA5892@debian> Mirko, excellent list, thanks a lot! Let me just go through... > - as Xiang Fu already mentioned, parts of the display are partially > hidden by the case (in my case - the first pixel-column on the left > respective the first pixel-row on the bottom). Totally agree, we will watch this from now on and it should not appear again. > - the qi-hardware-bezels on top are not really fixed [1] On you picture it seems like it is really coming off quite easily. On my prototype it is not. How is your bezel attached to the top cover? Not at all? Glue? Do you have that little slider to open the device? In my device the slider also prevents the bezel from coming off. > - the new LCM switches on (and is fading into white) when going into > USB-boot-mode (the AUO didn't) I tested this here on my prototype, same batch of 20 as yours, and I cannot reproduce it. Are you using the Giantplus LCM with the 1GB or 2GB board? Maybe it was some setting in the LCM from your driver work? Is this reproducible to you? Yi already asked - can you still use the LCM later or will it remain unusable? Please let me know if you want us to look deeper into this. > - the new prototype makes weird high-frequency sounds when connected to > the serial console but not to power > - when power-cycling the NanoNote too fast (which happens for me when I > flashed and now wanna try it out which results in plugging usb out and > in) it does not react anymore at all - you have to remove power several > seconds to get it booting again Those 2 are strange. You see this only with the black Qi design prototypes? Or also with the older 1GB boards? Both cases also seem a bit rare to me, so I will wait whether we see a pattern or believe this is important before taking further actions. Please let me know. > - keyboard and serial-console are partially sharing their pins, so for > now _either_ the full keyboard can be used _or_ the serial console That's a design limitation. I don't think it's worth fixing right now. > - the NAND (old and new one) can be erased 5k times - in contrast the > NAND-chip within the Openmoko Freerunner has about 100k erase-cycles Interesting. Where does the 5k and 100k number come from? I looked in the NanoNote NAND datasheet, and the revision history says "10K->5K" and then "5K->TBD". Now it says TBD. I'm not sure whether this is just a 'paper value' because of warranty concerns, or whether it's a real 'low endurance' NAND chip. Both the NanoNote and FreeRunner use NAND chips from Samsung, and the one in the NanoNote is a relatively recent chip. So I hope they improved technology, not made it worse :-) I think we need to find a real NAND expert to tell us how real those numbers are and which chip we could switch to for higher endurance. > - still having the "boot-reliable-from-sdcard"-issues Hmm. That's strange. Please keep me posted, especially if you think it's a chip or HW design issue. Still, all sounds encouraging, congratulations for the great progress! Wolfgang From lists at nanl.de Tue Sep 8 08:59:17 2009 From: lists at nanl.de (Mirko Vogt) Date: Tue, 08 Sep 2009 14:59:17 +0200 Subject: some updates "from behind the scenes" In-Reply-To: <6ADE4A09-FFBE-4789-B4EA-73B127873C11@qi-hardware.com> References: <1252336538.22690.1601.camel@mia> <6ADE4A09-FFBE-4789-B4EA-73B127873C11@qi-hardware.com> Message-ID: <1252414757.22690.2104.camel@mia> Yeah, it behaves as normal when doing a "normal" boot. All in all I just noticed, that the LCM just doesn't keep dark (but turning white) when switching the device on and the usbboot-pins are short circuited. When power cycling the NanoNote, without having the usbboot-pins short circuited, the LCM behaves as normal (uboot shows up, then the kernel, etc.) mirko On Tue, 2009-09-08 at 14:48 +0800, Yi Zhang wrote: > Mirko, > > On 2009-9-7, at ??11:15, Mirko Vogt wrote: > > > - the new LCM switches on (and is fading into white) when going into > > USB-boot-mode (the AUO didn't) > > Does LCD remain white, or does it go back to normal after LCD driver > has loaded? > > Yi > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer -- This email address is used for mailinglist purposes only. Non-mailinglist emails will be dropped automatically. If you want to get in contact with me personally, please mail to: mirko.vogt nanl de From wolfgang at qi-hardware.com Tue Sep 8 09:26:20 2009 From: wolfgang at qi-hardware.com (Wolfgang Spraul) Date: Tue, 8 Sep 2009 09:26:20 -0400 Subject: some updates "from behind the scenes" In-Reply-To: <1252414757.22690.2104.camel@mia> References: <1252336538.22690.1601.camel@mia> <6ADE4A09-FFBE-4789-B4EA-73B127873C11@qi-hardware.com> <1252414757.22690.2104.camel@mia> Message-ID: <20090908132620.GA5966@debian> Mirko, > All in all I just noticed, that the LCM just doesn't keep dark (but > turning white) when switching the device on and the usbboot-pins are > short circuited. Sure we got that (also see my mail). It's too bad we cannot test whether you can still normally initialize and use the LCM in that case. We would have to load a Linux kernel into memory and execute it right there, see whether the LCM comes up. But you probably only go to USB boot mode to reflash, then reboot the device? So you never need the LCM when booting over USB boot. Like I said, I cannot reproduce this bug on my device here. We need to watch it... Wolfgang On Tue, Sep 08, 2009 at 02:59:17PM +0200, Mirko Vogt wrote: > Yeah, it behaves as normal when doing a "normal" boot. > > All in all I just noticed, that the LCM just doesn't keep dark (but > turning white) when switching the device on and the usbboot-pins are > short circuited. > > When power cycling the NanoNote, without having the usbboot-pins short > circuited, the LCM behaves as normal (uboot shows up, then the kernel, > etc.) > > mirko > > On Tue, 2009-09-08 at 14:48 +0800, Yi Zhang wrote: > > Mirko, > > > > On 2009-9-7, at ??11:15, Mirko Vogt wrote: > > > > > - the new LCM switches on (and is fading into white) when going into > > > USB-boot-mode (the AUO didn't) > > > > Does LCD remain white, or does it go back to normal after LCD driver > > has loaded? > > > > Yi > > _______________________________________________ > > Qi Developer Mailing List > > Mail to list (members only): developer at lists.qi-hardware.com > > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -- > This email address is used for mailinglist purposes only. > Non-mailinglist emails will be dropped automatically. > If you want to get in contact with me personally, please mail to: > mirko.vogt nanl de > > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer From kzjeef at gmail.com Tue Sep 8 11:08:42 2009 From: kzjeef at gmail.com (ZhangJieJing) Date: Tue, 8 Sep 2009 23:08:42 +0800 Subject: configure mpd/mpc in openwrt. music player in Ben NanoNote In-Reply-To: <4AA5B590.5000000@qi-hardware.com> References: <4AA463E5.5090802@qi-hardware.com> <19ebea720909071630t1a680beexf5d62ec2084090ba@mail.gmail.com> <4AA5B590.5000000@qi-hardware.com> Message-ID: Hi, Sound card on my kernel tree is just can be found by alsa driver, But the driver have problem with DMA(jz's driver use too old DMA method) I 'm trying to fix it. The sound cann't play for now. --- Best regards, Zhang Jiejing On Tue, Sep 8, 2009 at 9:38 AM, Xiangfu Liu wrote: > Carlos Camargo wrote: > > Hi > > > > We are trying to test the sound driver, with alsa, mplayer, but doesn't > > work :( The Qi kernel source support the JZ sound driver? If not, where > > can I foun information about this driver? > > the Qi kernel not support JZ sound driver not. Jieijing Zhang and larsc > work on that. > > you can find the Jieijing Zhange sound code: > > http://projects.qi-hardware.com/index.php/p/kzjeef-kernel/source/changes/master/ > > you can find JZ 2.6.27 sound driver at: > http://downloads.qi-hardware.com/software/sources/linux-2.6.27.git.svn.tgz > > > > > > > $ scripts/feeds install mpd > > $ scripts/feeds install mpc > > run 'scripts/feeds update' before install mpd/mpc. > > > > > I try to run this command but I get the following error: > > > > Ignoring feed 'packages' - index missing > > Ignoring feed 'xwrt' - index missing > > Ignoring feed 'luci' - index missing > > WARNING: No feed for package 'mpd' found, maybe it's already part of the > > standard packages? > > > > > > > > Carlos > > > > > > > > On Sun, Sep 6, 2009 at 8:37 PM, Xiangfu Liu > > wrote: > > > > > > 1. in terminal, under openwrt folder run > > > > > > > > 2. run [make menuconfig] then select --> sound --> enable [mpc] [mpd] > > 3. run [make menuconfig] --> Base System --> enable [libstdcpp] > > > > then you run make. you will get the [mpd] [mpc] in you rootfs. > > you need change the [/etc/mpd.conf] to make the mpd work. > > > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at nanl.de Tue Sep 8 11:58:24 2009 From: lists at nanl.de (Mirko Vogt) Date: Tue, 08 Sep 2009 17:58:24 +0200 Subject: some updates "from behind the scenes" In-Reply-To: <20090908124639.GA5892@debian> References: <1252336538.22690.1601.camel@mia> <20090908124639.GA5892@debian> Message-ID: <1252425504.22690.2363.camel@mia> On Tue, 2009-09-08 at 08:48 -0400, Wolfgang Spraul wrote: > Mirko, Wolfgang, > Let me just go through... will do the same :) > > > - the qi-hardware-bezels on top are not really fixed [1] > > On you picture it seems like it is really coming off quite easily. > On my prototype it is not. How is your bezel attached to the top cover? > Not at all? Glue? Do you have that little slider to open the device? > In my device the slider also prevents the bezel from coming off. Yes, it came off quiet easily. For me, it's fixed with a bit of glue and somehow clipped on, but can be pushed off quiet easily from the bottom (it happened to me, when I used the slider and wanted to open the NanoNote - that way I pushed off the bezel from the bottom). > > > - the new LCM switches on (and is fading into white) when going into > > USB-boot-mode (the AUO didn't) > > I tested this here on my prototype, same batch of 20 as yours, and I > cannot reproduce it. Are you using the Giantplus LCM with the 1GB or > 2GB board? Maybe it was some setting in the LCM from your driver work? > Is this reproducible to you? Yi already asked - can you still use the > LCM later or will it remain unusable? > Please let me know if you want us to look deeper into this. The display does not get any data to show while being in usbboot-mode - that's normal and ok. To me the only thing which differs is, that the Giantplus-display is enabled (powered on) by default, while the AUO wasn't. And because of missing data it just fades to white. In normal use (not usbboot-mode) everything is fine, because uboot successfully initializes and send data to the display. > > > - the new prototype makes weird high-frequency sounds when connected to > > the serial console but not to power > > - when power-cycling the NanoNote too fast (which happens for me when I > > flashed and now wanna try it out which results in plugging usb out and > > in) it does not react anymore at all - you have to remove power several > > seconds to get it booting again > > Those 2 are strange. You see this only with the black Qi design prototypes? > Or also with the older 1GB boards? Both cases also seem a bit rare to me, > so I will wait whether we see a pattern or believe this is important before > taking further actions. Please let me know. I noticed this high-frequency sound just on my (new) prototype. This "not reacting"-issue after unplugging and plugging power too fast, I experienced on _all_ devices I tried (same with lars'). > > > - the NAND (old and new one) can be erased 5k times - in contrast the > > NAND-chip within the Openmoko Freerunner has about 100k erase-cycles > > Interesting. Where does the 5k and 100k number come from? > I looked in the NanoNote NAND datasheet, and the revision history says > "10K->5K" and then "5K->TBD". Now it says TBD. I'm not sure whether this > is just a 'paper value' because of warranty concerns, or whether it's a > real 'low endurance' NAND chip. Both the NanoNote and FreeRunner use > NAND chips from Samsung, and the one in the NanoNote is a relatively > recent chip. So I hope they improved technology, not made it worse :-) > I think we need to find a real NAND expert to tell us how real those > numbers are and which chip we could switch to for higher endurance. The "5k"-value came from the published datasheet for the 1GB-NAND. It isn't mentioned within the sheet for the 2GB-one, however the 5k-value for the 2GB-chip was mentioned somewhere else. > > > - still having the "boot-reliable-from-sdcard"-issues > > Hmm. That's strange. Please keep me posted, especially if you think > it's a chip or HW design issue. We will do. > > Still, all sounds encouraging, congratulations for the great progress! Thanks :) > Wolfgang mirko > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer -- This email address is used for mailinglist purposes only. Non-mailinglist emails will be dropped automatically. If you want to get in contact with me personally, please mail to: mirko.vogt nanl de From wolfgang at qi-hardware.com Tue Sep 8 21:24:24 2009 From: wolfgang at qi-hardware.com (Wolfgang Spraul) Date: Tue, 8 Sep 2009 21:24:24 -0400 Subject: [Company] Weekly Operations Update 36/2009 Message-ID: <20090909012424.GA6069@debian> Hi, last week in the land of Qi... ---1 updated Ingenic documentation Ingenic gave us explicit permission to redistribute a number of their manuals without NDA. They have also spent a lot of time updating their documentation in recent months. The agreement right now is to distribute the manuals upon by request by email, and not put them on a server. While this is a bit strange to me, others like Samsung are doing this as well so I cannot really complain. It's a step forward. I will continue to lobby Ingenic for better support of the free software community, such as putting CC-BY-ND licensed PDF files right on their server. Still, as of right now, we got the following updated manuals (SIMD is still missing, working on it...): XBurst Microprocessor Core, Rev 1.0, Apr 2007, 62 pages Jz4725B Data Sheet, Rel July 7, 2009, 37 pages Jz4725B Programming Manual, Julz 14, 2009, 529 pages Jz4720 Data Sheet, Rev 1, Jun 2008, 37 pages Jz4740 Data Sheet, Jun 2007, 35 pages Jz4740 Programming Manual, July 22, 2009, 539 pages Jz4750 Data Sheet, Apr 2009, 40 pages Jz4750L Data Sheet, July 17, 2009, 37 pages Jz4750L Programming Manual, July 14, 2009, 570 pages Jz4755 Data Sheet, July 7, 2009, 33 pages Jz4755 Programming Manual, Jul 22, 2009, 732 pages If you need any of them, please email me. Also, I ask everybody I email the documentation to to respect Ingenic's wish that it not be put on a server right now. I think this is a big step forward, and will also help other projects using Ingenic chips, such as dingux, emqbit or openinkpot. ---2 NanoNote FCC test failed Our first shot at FCC certification for the NanoNote failed, see http://downloads.qi-hardware.com/hardware/certification/FCC_Test_Report_20090901.pdf This is unfortunate and will cause delays in our schedule. By how much we don't know yet. In hindsight we should have started the certification process earlier, now we are all trying to fix the issue and get back on track... ---3 new activity on projects.qi-hardware.com We are a bit slow in bringing up more features of our indefero installation at projects.qi-hardware.com, such as commitlog, svn repositories (only git supported right now), etc. Still, Bas and Carlos have started putting serious projects on it and that's very welcome. We will offer free hosting for any GPL-licensed kicad or geda projects on our server, to everybody. Plus any software projects related to Qi or Qi affiliated devices. Email me to create a new project, that's one of the things that is not automated yet... --4 gta02-core-news Over at our sister project gta02-core, Alvaro Lopez started a blog to track what's going on at the gta02-core mailing list. http://gta02-core-news.blogspot.com If something major happens over there I will also mention it here in my weekly update. So much for now, Wolfgang From xiangfu at qi-hardware.com Tue Sep 8 23:27:52 2009 From: xiangfu at qi-hardware.com (Xiangfu Liu) Date: Wed, 09 Sep 2009 11:27:52 +0800 Subject: some updates "from behind the scenes" In-Reply-To: <1252336538.22690.1601.camel@mia> References: <1252336538.22690.1601.camel@mia> Message-ID: <4AA720B8.1000909@qi-hardware.com> Mirko Vogt wrote: > Hello qi! :) > > Long time no news, but now some updates - as Wolfgang said: "from > behind the scenes"; what happened on "our" side in keywords. > > == Hardware > We got new prototypes with 2 GB NAND / new LCM - some things we noticed > (some amy not be relevant - but wanted to have them mentioned): > > - as Xiang Fu already mentioned, parts of the display are partially > hidden by the case (in my case - the first pixel-column on the left > respective the first pixel-row on the bottom). > - the qi-hardware-bezels on top are not really fixed [1] > - the new LCM switches on (and is fading into white) when going into > USB-boot-mode (the AUO didn't) > - the new prototype makes weird high-frequency sounds when connected to > the serial console but not to power > - when power-cycling the NanoNote too fast (which happens for me when I > flashed and now wanna try it out which results in plugging usb out and > in) it does not react anymore at all - you have to remove power several > seconds to get it booting again > - keyboard and serial-console are partially sharing their pins, so for > now _either_ the full keyboard can be used _or_ the serial console I have enable the serial console. then the serial console and keyboard both work. the S58(shift) S59(alt) S60(FN) keys work just fine. both work, don't know why. > - the NAND (old and new one) can be erased 5k times - in contrast the > NAND-chip within the Openmoko Freerunner has about 100k erase-cycles > > == Software > - OpenWrt is (still) running (with a really nice bootsplash - made with > love and passion [2]) > - still having the "boot-reliable-from-sdcard"-issues > - 1GB as well as 2GB NAND chips are working > - display- and framebuffer driver are written from scratch and working > - keyboard is working in general (however we experienced some > kbd-issues with recent A1-devices - key-combinations to get special > characters inserted needs some more work, too) > - you have to erase the NAND ( in u-boot will do the job) > before flashing a jffs2-image (this may either be fixed in jffs2-code or > getting the flash-tools to erase the blocks after the jffs2-EOF-marker) > - also there exist some more ECC-problems > > == misc > - Ignacio should have got a Ben NanoNote - have fun! :) Hopefully you > can help us with getting this sd-card-issue fixed > > > These were just a few keywords - in case you want some more verbose > output please let us know :) > > > Happy hacking! > > mirko (vogt) From rakshat at gmail.com Tue Sep 8 23:47:45 2009 From: rakshat at gmail.com (rakshat hooja) Date: Wed, 9 Sep 2009 09:17:45 +0530 Subject: [Company] Weekly Operations Update 36/2009 In-Reply-To: <20090909012424.GA6069@debian> References: <20090909012424.GA6069@debian> Message-ID: <69a2e4550909082047s1d73be44xb8d10ffa21ac8f6f@mail.gmail.com> On Wed, Sep 9, 2009 at 6:54 AM, Wolfgang Spraul wrote: > > We will offer free hosting for any GPL-licensed kicad or geda projects on > our server, to everybody. > Does this mean it may be possible to Host a mirror of GTA-core files on your server? Rakshat -------------- next part -------------- An HTML attachment was scrubbed... URL: From wolfgang at qi-hardware.com Wed Sep 9 01:05:02 2009 From: wolfgang at qi-hardware.com (Wolfgang Spraul) Date: Wed, 9 Sep 2009 01:05:02 -0400 Subject: [Company] Weekly Operations Update 36/2009 In-Reply-To: <69a2e4550909082047s1d73be44xb8d10ffa21ac8f6f@mail.gmail.com> References: <20090909012424.GA6069@debian> <69a2e4550909082047s1d73be44xb8d10ffa21ac8f6f@mail.gmail.com> Message-ID: <20090909050502.GA6162@debian> Rakshat, > Does this mean it may be possible to Host a mirror of GTA-core files on your > server? Oh sure, gta02-core is totally in line with our copyleft hardware ideals. In fact Werner started a good part of it! However, I think the gta02-core project is perfectly fine where it is located now, inside the openmoko.org server farm. The management of openmoko.org is 100% in the hands of the community now, and I think it's being taken care of very well. What data do you want to mirror? Wolfgang On Wed, Sep 09, 2009 at 09:17:45AM +0530, rakshat hooja wrote: > On Wed, Sep 9, 2009 at 6:54 AM, Wolfgang Spraul wrote: > > > > > We will offer free hosting for any GPL-licensed kicad or geda projects on > > our server, to everybody. > > > > Does this mean it may be possible to Host a mirror of GTA-core files on your > server? > > Rakshat > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer From rakshat at gmail.com Wed Sep 9 02:11:05 2009 From: rakshat at gmail.com (rakshat hooja) Date: Wed, 9 Sep 2009 11:41:05 +0530 Subject: [Company] Weekly Operations Update 36/2009 In-Reply-To: <20090909050502.GA6162@debian> References: <20090909012424.GA6069@debian> <69a2e4550909082047s1d73be44xb8d10ffa21ac8f6f@mail.gmail.com> <20090909050502.GA6162@debian> Message-ID: <69a2e4550909082311h2693563cr14c39c0b29c69557@mail.gmail.com> On Wed, Sep 9, 2009 at 10:35 AM, Wolfgang Spraul wrote: > Rakshat, > > > Does this mean it may be possible to Host a mirror of GTA-core files on > your > > server? > > Oh sure, gta02-core is totally in line with our copyleft hardware ideals. > In fact Werner started a good part of it! > However, I think the gta02-core project is perfectly fine where it is > located > now, inside the openmoko.org server farm. The management of openmoko.orgis > 100% in the hands of the community now, and I think it's being taken care > of > very well. > > What data do you want to mirror? > I know their svn in on openmoko.org. I was just thinking if it would be ok for qi-hardware to also host cloned copy of their svn tree (synced say weekly) as a backup incase openmoko.org is down sometime. The other reason I had for this was that it will also give more publicity to the GTA core project as currently it is not very easy to explain to new people (as in those who were not already following Openmoko activities - like those who don't know both Werner and you were at openmoko and are very much in contact). But it fits in very neatly with the qi-hardware philosphy and a developer after reading your website will easily understand it. Rakshat -------------- next part -------------- An HTML attachment was scrubbed... URL: From roh at openmoko.org Wed Sep 9 03:29:38 2009 From: roh at openmoko.org (Joachim Steiger) Date: Wed, 09 Sep 2009 09:29:38 +0200 Subject: [Company] Weekly Operations Update 36/2009 In-Reply-To: <69a2e4550909082311h2693563cr14c39c0b29c69557@mail.gmail.com> References: <20090909012424.GA6069@debian> <69a2e4550909082047s1d73be44xb8d10ffa21ac8f6f@mail.gmail.com> <20090909050502.GA6162@debian> <69a2e4550909082311h2693563cr14c39c0b29c69557@mail.gmail.com> Message-ID: <4AA75962.2080301@openmoko.org> rakshat hooja wrote: > The other reason I had for this was that it will also give more publicity to > the GTA core project as currently it is not very easy to explain to new > people (as in those who were not already following Openmoko activities - > like those who don't know both Werner and you were at openmoko and are very > much in contact). But it fits in very neatly with the qi-hardware philosphy > and a developer after reading your website will easily understand it. you mean 'a link' ? i immediatelly thought of something like the ToH (table of hardware) from openwrt, just for all _foss_ hw we know of. (yet) > Rakshat regards -- Joachim Steiger Openmoko.org Central Services From xiangfu at qi-hardware.com Wed Sep 9 10:23:43 2009 From: xiangfu at qi-hardware.com (Xiangfu Liu) Date: Wed, 09 Sep 2009 22:23:43 +0800 Subject: How to Reflash Ben NanoNote Message-ID: <4AA7BA6F.7040305@qi-hardware.com> Hi we will put the recently image at [1], for the 2GB board. you need download those four files: openwrt-xburst-root.jffs2-512k openwrt-xburst-u-boot.bin openwrt-xburst-uImage.bin reflash_ben.sh put those four files in same folder boot the board to USB_BOOT mode. run "sh reflash_ben.sh" to reflash the device. after that. just reboot your Ben. you will see "Please press Enter to activate this console." on the screen. when you reflash the device, the first boot, kernel need about 3~5 minutes to erase the nand that rootfs not use. after first time. it's will work fine. the boot time is around ~10 secs. [1] http://downloads.qi-hardware.com/software/images/Ben_NanoNote_2GB_NAND/ From xiangfu.z at gmail.com Wed Sep 9 11:21:33 2009 From: xiangfu.z at gmail.com (Xiangfu Liu) Date: Wed, 09 Sep 2009 23:21:33 +0800 Subject: How to Reflash Ben NanoNote In-Reply-To: <4AA7BA6F.7040305@qi-hardware.com> References: <4AA7BA6F.7040305@qi-hardware.com> Message-ID: <4AA7C7FD.2020802@gmail.com> Hi here is the USB_BOOT host tools: http://downloads.qi-hardware.com/software/xburst-tools/ the configure is at /etc/xburst-tools/ by default the usbboot.cfg is for 2GB nand board. Xiangfu Liu wrote: > Hi > we will put the recently image at [1], > for the 2GB board. you need download those four files: > openwrt-xburst-root.jffs2-512k > openwrt-xburst-u-boot.bin > openwrt-xburst-uImage.bin > reflash_ben.sh > > put those four files in same folder > boot the board to USB_BOOT mode. > run "sh reflash_ben.sh" to reflash the device. > after that. just reboot your Ben. > you will see > "Please press Enter to activate this console." > on the screen. > > when you reflash the device, the first boot, > kernel need about 3~5 minutes to erase the nand that rootfs not use. > after first time. it's will work fine. > the boot time is around ~10 secs. > > > > [1] http://downloads.qi-hardware.com/software/images/Ben_NanoNote_2GB_NAND/ > > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer -- Xiangfu Liu Email: xiangfu at qi-hardware dot com Web: http://www.qi-hardware.com From kzjeef at gmail.com Wed Sep 9 11:32:53 2009 From: kzjeef at gmail.com (ZhangJieJing) Date: Wed, 9 Sep 2009 23:32:53 +0800 Subject: How to Reflash Ben NanoNote In-Reply-To: <4AA7BA6F.7040305@qi-hardware.com> References: <4AA7BA6F.7040305@qi-hardware.com> Message-ID: Hi, all should we post these paper to wiki ? --- Best regards, Zhang Jiejing On Wed, Sep 9, 2009 at 10:23 PM, Xiangfu Liu wrote: > Hi > we will put the recently image at [1], > for the 2GB board. you need download those four files: > openwrt-xburst-root.jffs2-512k > openwrt-xburst-u-boot.bin > openwrt-xburst-uImage.bin > reflash_ben.sh > > put those four files in same folder > boot the board to USB_BOOT mode. > run "sh reflash_ben.sh" to reflash the device. > after that. just reboot your Ben. > you will see > "Please press Enter to activate this console." > on the screen. > > when you reflash the device, the first boot, > kernel need about 3~5 minutes to erase the nand that rootfs not use. > after first time. it's will work fine. > the boot time is around ~10 secs. > > > > [1] > http://downloads.qi-hardware.com/software/images/Ben_NanoNote_2GB_NAND/ > > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mirko at qi-hardware.com Wed Sep 9 11:43:31 2009 From: mirko at qi-hardware.com (Mirko Lindner) Date: Wed, 9 Sep 2009 17:43:31 +0200 Subject: How to Reflash Ben NanoNote In-Reply-To: References: <4AA7BA6F.7040305@qi-hardware.com> Message-ID: <11ac140a0909090843m3888f990x43d2ae08807b82c3@mail.gmail.com> Hey, On Wed, Sep 9, 2009 at 5:32 PM, ZhangJieJing wrote: > Hi, all > > should we post these paper to wiki ? > Yes definitely. I will get on to this as well as soon as I get back to Berlin. Please go ahead and start the page, would be a great help! Thanks!!! /mirko -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiangfu at qi-hardware.com Wed Sep 9 11:38:56 2009 From: xiangfu at qi-hardware.com (Xiangfu Liu) Date: Wed, 09 Sep 2009 23:38:56 +0800 Subject: How to Reflash Ben NanoNote In-Reply-To: References: <4AA7BA6F.7040305@qi-hardware.com> Message-ID: <4AA7CC10.1000800@qi-hardware.com> ZhangJieJing wrote: > Hi, all > > should we post these paper to wiki ? yes. already work on that. http://wiki.qi-hardware.com/index.php/How_to_reflash feel free to edit it. make it more clear. > > > --- > Best regards, > Zhang Jiejing > > > On Wed, Sep 9, 2009 at 10:23 PM, Xiangfu Liu > wrote: > > Hi > we will put the recently image at [1], > for the 2GB board. you need download those four files: > openwrt-xburst-root.jffs2-512k > openwrt-xburst-u-boot.bin > openwrt-xburst-uImage.bin > reflash_ben.sh > > put those four files in same folder > boot the board to USB_BOOT mode. > run "sh reflash_ben.sh" to reflash the device. > after that. just reboot your Ben. > you will see > "Please press Enter to activate this console." > on the screen. > > when you reflash the device, the first boot, > kernel need about 3~5 minutes to erase the nand that rootfs not use. > after first time. it's will work fine. > the boot time is around ~10 secs. > > > > [1] > http://downloads.qi-hardware.com/software/images/Ben_NanoNote_2GB_NAND/ > > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer From rjeffries at gmail.com Wed Sep 9 12:18:31 2009 From: rjeffries at gmail.com (Ron K. Jeffries) Date: Wed, 9 Sep 2009 09:18:31 -0700 Subject: first thoughts re Nanonote Message-ID: <886128c30909090918y7b4031c9g42e0c40f2983f46e@mail.gmail.com> THANKS to Michael Shilo and Steve Mosher I temporarily have a Nanonote (with original keyboard and software). Thursday night Sep 10 I'll share NN with Santa Barbara Linux User Group, which includes a developer for the original SLUG porting efforts on Linksys NSLU. a few thoughts, 1/10th baked at best: > NN could be a great tool for kids to learn programming. > Don't ignore the possibility of a completely open PDA. My Palm V served me well for many years. NN does NOT require a service contract that's a huge deal. > [future] Touch sensitive screen would be a huge win. > [future] adding an FPGA would be a significant differentiator. > [just noodling] NN and Ardurino might (??) be used together in creative ways --- Ron K. Jeffries http://blog.eronj.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From cicamargoba at gmail.com Wed Sep 9 12:24:55 2009 From: cicamargoba at gmail.com (Carlos Camargo) Date: Wed, 9 Sep 2009 11:24:55 -0500 Subject: How to Reflash Ben NanoNote In-Reply-To: <11ac140a0909090843m3888f990x43d2ae08807b82c3@mail.gmail.com> References: <4AA7BA6F.7040305@qi-hardware.com> <11ac140a0909090843m3888f990x43d2ae08807b82c3@mail.gmail.com> Message-ID: <19ebea720909090924q7090fee9u6111bc18277a7100@mail.gmail.com> My Nano Its alive !!! Thanks for the info Carlos On Wed, Sep 9, 2009 at 10:43 AM, Mirko Lindner wrote: > Hey, > > On Wed, Sep 9, 2009 at 5:32 PM, ZhangJieJing wrote: > >> Hi, all >> >> should we post these paper to wiki ? >> > > Yes definitely. I will get on to this as well as soon as I get back to > Berlin. Please go ahead and start the page, would be a great help! > > Thanks!!! > > /mirko > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -- Carlos Iv?n Camargo Bare?o Profesor Asistente Departamento de Ingenier?a El?ctrica y Electr?nica Universidad Nacional de Colombia cicamargoba at unal.edu.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From kzjeef at gmail.com Wed Sep 9 12:56:02 2009 From: kzjeef at gmail.com (ZhangJieJing) Date: Thu, 10 Sep 2009 00:56:02 +0800 Subject: How to Reflash Ben NanoNote In-Reply-To: <19ebea720909090924q7090fee9u6111bc18277a7100@mail.gmail.com> References: <4AA7BA6F.7040305@qi-hardware.com> <11ac140a0909090843m3888f990x43d2ae08807b82c3@mail.gmail.com> <19ebea720909090924q7090fee9u6111bc18277a7100@mail.gmail.com> Message-ID: Hi, I reformat these 2 wiki on the website, let them more like a real wiki paper. :) I found the roadmap under wiki, http://wiki.qi-hardware.com/index.php/Ben_source_code, also have a part of "how to reflesh device", I think we should redriect this section to http://wiki.qi-hardware.com/index.php/How_to_reflash? what are you think? --- Best regards, Zhang Jiejing On Thu, Sep 10, 2009 at 12:24 AM, Carlos Camargo wrote: > My Nano Its alive !!! > > Thanks for the info > > > Carlos > > > On Wed, Sep 9, 2009 at 10:43 AM, Mirko Lindner wrote: > >> Hey, >> >> On Wed, Sep 9, 2009 at 5:32 PM, ZhangJieJing wrote: >> >>> Hi, all >>> >>> should we post these paper to wiki ? >>> >> >> Yes definitely. I will get on to this as well as soon as I get back to >> Berlin. Please go ahead and start the page, would be a great help! >> >> Thanks!!! >> >> /mirko >> >> _______________________________________________ >> Qi Developer Mailing List >> Mail to list (members only): developer at lists.qi-hardware.com >> Subscribe or Unsubscribe: >> http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer >> > > > > -- > Carlos Iv?n Camargo Bare?o > Profesor Asistente > Departamento de Ingenier?a El?ctrica y Electr?nica > Universidad Nacional de Colombia > cicamargoba at unal.edu.co > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cicamargoba at gmail.com Wed Sep 9 13:08:51 2009 From: cicamargoba at gmail.com (Carlos Camargo) Date: Wed, 9 Sep 2009 12:08:51 -0500 Subject: first thoughts re Nanonote In-Reply-To: <886128c30909090918y7b4031c9g42e0c40f2983f46e@mail.gmail.com> References: <886128c30909090918y7b4031c9g42e0c40f2983f46e@mail.gmail.com> Message-ID: <19ebea720909091008t59ae4ecevfee292cdcc2888cd@mail.gmail.com> Hi > > NN could be a great tool for kids > to learn programming. > Yes, I'm thinking in an application like Logo Blocks [1], or Turtle art [2] > > [future] adding an FPGA would be a > significant differentiator. > I agree, we can use this FPGA to interfaz Nano with real Hardware, like robots, acquisition cards, etc > > [just noodling] NN and Ardurino > might (??) be used together in creative ways > > I think that the arduino's success is the API, so, many people for different areas (music, artists, etc) can use it in easy way. [1] http://llk.media.mit.edu/projects/cricket/doc/help/logoblocks/startingwithlogoblocks.htm [2] http://wiki.laptop.org/go/Turtle_Art Carlos --- > Ron K. Jeffries > http://blog.eronj.com > > > > > > > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -- Carlos Iv?n Camargo Bare?o Profesor Asistente Departamento de Ingenier?a El?ctrica y Electr?nica Universidad Nacional de Colombia cicamargoba at unal.edu.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From nelsoneci at gmail.com Wed Sep 9 15:09:17 2009 From: nelsoneci at gmail.com (Nelson Castillo) Date: Wed, 9 Sep 2009 14:09:17 -0500 Subject: first thoughts re Nanonote In-Reply-To: <19ebea720909091008t59ae4ecevfee292cdcc2888cd@mail.gmail.com> References: <886128c30909090918y7b4031c9g42e0c40f2983f46e@mail.gmail.com> <19ebea720909091008t59ae4ecevfee292cdcc2888cd@mail.gmail.com> Message-ID: <2accc2ff0909091209q5fe442fck7f364b4a5eaaa2b5@mail.gmail.com> On Wed, Sep 9, 2009 at 12:08 PM, Carlos Camargo wrote: > > Hi > >> >> > NN could be a great tool for kids >> ?? to learn programming. > > Yes, I'm thinking in an application like Logo Blocks [1], or Turtle art [2] > > >> >> > [future] adding an FPGA would be a >> ?? significant differentiator. > > I agree,? we can use this FPGA to interfaz Nano with real Hardware, like > robots, acquisition cards, etc > >> >> > [just noodling] NN and Ardurino >> ?? might (??) be used together in creative ways >> > > I think that the arduino's success is the API, so, many people for > different? areas? (music, artists, etc) can use it in easy way. I agree. It amazes me to see how practitioners and artists have made the Arduino as popular as it is now. It's something you think you don't need... But I guess the APIs is what people get to like the most. From suyckerbol at gmail.com Wed Sep 9 16:02:52 2009 From: suyckerbol at gmail.com (W.G. van de Hulst) Date: Wed, 9 Sep 2009 22:02:52 +0200 Subject: Manuals (Re: [Company] Weekly Operations Update 36/2009) Message-ID: 2009/9/9, Wolfgang Spraul : > Ingenic gave us explicit permission to redistribute a number of their > manuals without NDA. They have also spent a lot of time updating their > documentation in recent months. That's great news. > Still, as of right now, we got the following updated manuals (SIMD is > still missing, working on it...): I wait with bated breath... > Jz4720 Data Sheet, Rev 1, Jun 2008, 37 pages > Jz4740 Data Sheet, Jun 2007, 35 pages > Jz4740 Programming Manual, July 22, 2009, 539 pages Does this mean there is no specific Jz4720 Programming Manual? In other words, is the Jz4740 Programming Manual the official reference for the jz4720? > Jz4750L Data Sheet, July 17, 2009, 37 pages > Jz4750L Programming Manual, July 14, 2009, 570 pages Is this related to the mysterious jz4757 chip ([1])? I don't think it's a simple updated jz4750 or it wouldn't have received its own tree in the Ingenic Linux kernel. [1] http://forum.eepw.com.cn/thread/155995/1 From steve at qi-hardware.com Wed Sep 9 17:24:19 2009 From: steve at qi-hardware.com (Steve Mosher) Date: Wed, 9 Sep 2009 14:24:19 -0700 Subject: first thoughts re Nanonote In-Reply-To: <886128c30909090918y7b4031c9g42e0c40f2983f46e@mail.gmail.com> References: <886128c30909090918y7b4031c9g42e0c40f2983f46e@mail.gmail.com> Message-ID: <2b311fa30909091424h3486c8den44fdb3d002e770c5@mail.gmail.com> Thanks Ron. comments below On Wed, Sep 9, 2009 at 9:18 AM, Ron K. Jeffries wrote: > THANKS to Michael Shilo and Steve Mosher > I temporarily have a Nanonote (with > original keyboard and software). > > Thursday night Sep 10 I'll share NN with > Santa Barbara Linux User Group, which > includes a developer for the original > SLUG porting efforts on Linksys NSLU. > > a few thoughts, 1/10th baked at best: > > > NN could be a great tool for kids > to learn programming. > Kids and college students. Michael does education, he can weigh in here. > > > Don't ignore the possibility of a > completely open PDA. My Palm V > served me well for many years. > NN does NOT require a service contract > that's a huge deal. > We aim to get there > > > [future] Touch sensitive screen would > be a huge win. > It's one of the number one requests I get. > > > [future] adding an FPGA would be a > significant differentiator. > > > [just noodling] NN and Ardurino > might (??) be used together in creative ways > Michael Shiloh said the same thing and was looking into that. Michael? > > --- > Ron K. Jeffries > http://blog.eronj.com > > > > > > > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wolfgang at qi-hardware.com Wed Sep 9 22:27:25 2009 From: wolfgang at qi-hardware.com (Wolfgang Spraul) Date: Wed, 9 Sep 2009 22:27:25 -0400 Subject: Manuals (Re: [Company] Weekly Operations Update 36/2009) In-Reply-To: References: Message-ID: <20090910022725.GC2612@debian> Hi, > > Ingenic gave us explicit permission to redistribute a number of their > > manuals without NDA. They have also spent a lot of time updating their > > documentation in recent months. > That's great news. Indeed. Thanks! You have no idea how many meetings were neccessary for that. > I wait with bated breath... I apologize for asking, but I need some new ways to prey them open. What do you plan to do with the SIMD Manual? Do you want to do some hacking? open source? Where is your project/source codes? Would it be acceptable for you to sign a FOSS-friendly NDA with Ingenic and get the SIMD documentation that way? You know that a lot of the SIMD stuff is already open, I summarized it in a recent mail on the list. With all that is open, I believe it's possible to start SIMD hacking already. We have the names of all instructions, for 47 of them we have C equivalents, we have mplayer and jpeg .c source codes using the instructions, and we have the assembler in source form. I think the first step would be to integreate a SIMD-accelerated mplayer into openwrt, using the openwrt-generated toolchain (needs to be enhanced to support the SIMD instructions), etc. > Does this mean there is no specific Jz4720 Programming Manual? In > other words, is the Jz4740 Programming Manual the official reference > for the jz4720? I didn't ask but yes I would think so. Same for the 4725. The 4720, 4725 and 4740 have the same die, just different packaging (and thus different pin-out and potentially different end-user features). But then the 4725b is the QFP variant of the 4750 (I think), but they have 2 programming manuals :-) Maybe I don't have full understanding yet... > Is this related to the mysterious jz4757 chip ([1])? I don't think > it's a simple updated jz4750 or it wouldn't have received its own tree > in the Ingenic Linux kernel. You never know. It's messy. I asked the CEO of Ingenic about the 4757 on your behalf, and he was laughing. They did that chip for one big customer who wanted to have their own chip. Even though it's the same die as the 4750 I believe. Chinese companies try all sorts of things to reduce the chances of their products being copied. Even if they can throw off the copy-cats for a few more weeks, that's already worth real money here. So some manufacturers will meticulously scratch out (manually!) the labeling of chips, or they will request the semiconductor to come out with a new model name just for them. Liu Qiang (the CEO) said they will not do this anymore in the future. Of course that's just his wish, if a large enough customer comes they can always ask for whatever they want. I would not read much, if anything, into the Linux tree thing. That's also very messy. In fact it may be that our (Qi Hardware's) Linux kernel will become the official Ingenic kernel. We are working to setting up a tighter collaboration. We just have to be careful that it doesn't mean that in the end Ingenic puts less resources on Linux, what we want is that we collaborate more efficiently. I would say let's focus on the open devices in our hands, from my perspective primarily the NanoNote of course, rather than to second guess every chip variant Ingenic has made here or there. What we need is a unified and recent Linux kernel and rootfs that runs on as many Ingenic-based devices as possible. Let's just start! Join the NanoNote hacking at our openwrt tree, or dingux.com, or openinkpot.org! :-) Wolfgang On Wed, Sep 09, 2009 at 10:02:52PM +0200, W.G. van de Hulst wrote: > 2009/9/9, Wolfgang Spraul : > > Ingenic gave us explicit permission to redistribute a number of their > > manuals without NDA. They have also spent a lot of time updating their > > documentation in recent months. > That's great news. > > > Still, as of right now, we got the following updated manuals (SIMD is > > still missing, working on it...): > I wait with bated breath... > > > Jz4720 Data Sheet, Rev 1, Jun 2008, 37 pages > > Jz4740 Data Sheet, Jun 2007, 35 pages > > Jz4740 Programming Manual, July 22, 2009, 539 pages > Does this mean there is no specific Jz4720 Programming Manual? In > other words, is the Jz4740 Programming Manual the official reference > for the jz4720? > > > Jz4750L Data Sheet, July 17, 2009, 37 pages > > Jz4750L Programming Manual, July 14, 2009, 570 pages > Is this related to the mysterious jz4757 chip ([1])? I don't think > it's a simple updated jz4750 or it wouldn't have received its own tree > in the Ingenic Linux kernel. > > [1] http://forum.eepw.com.cn/thread/155995/1 > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer From cicamargoba at gmail.com Wed Sep 9 23:12:30 2009 From: cicamargoba at gmail.com (Carlos Camargo) Date: Wed, 9 Sep 2009 22:12:30 -0500 Subject: Lattice or Xilinx Message-ID: <19ebea720909092012ib20ae76q9ed4e54b1490dc50@mail.gmail.com> Hi As you know, we are planning add a FPGA to the new Nano. I want to start a discussion about what is the best family for nano, what I care about is: Power consumption Size Free tools for programming / configuration Price Available logic, RAM, multipliers, etc At present I'm using Xilinx Spartan 3E FPGAs, but I don't have enough experience with Altera, or Lattice, Can you please talk us about your experiences with Lattice and Altera FPGAs? Best Regards Carlos -- Carlos Iv?n Camargo Bare?o Profesor Asistente Departamento de Ingenier?a El?ctrica y Electr?nica Universidad Nacional de Colombia cicamargoba at unal.edu.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From florian at openwrt.org Thu Sep 10 02:00:21 2009 From: florian at openwrt.org (Florian Fainelli) Date: Thu, 10 Sep 2009 08:00:21 +0200 Subject: Lattice or Xilinx In-Reply-To: <19ebea720909092012ib20ae76q9ed4e54b1490dc50@mail.gmail.com> References: <19ebea720909092012ib20ae76q9ed4e54b1490dc50@mail.gmail.com> Message-ID: <200909100800.26730.florian@openwrt.org> Hi Carlosm Le jeudi 10 septembre 2009 05:12:30, Carlos Camargo a ?crit : > Hi > > As you know, we are planning add a FPGA to the new Nano. I want to start a > discussion about what is the best family for nano, what I care about is: > > Power consumption Actel is afair the leader on that specific topic, but with much smaller FPGAs. > Size If talking about PCB size, Lattice also provides really small BGA-packaged FPGAs (like 5x5 mm), > Free tools for programming / configuration As far as I know, only Xilinx provides free tools for Linux. Lattice and Altera do for Windows, but for Linux. > Price > Available logic, RAM, multipliers, etc > > > At present I'm using Xilinx Spartan 3E FPGAs, but I don't have enough > experience with Altera, or Lattice, Can you please talk us about your > experiences with Lattice and Altera FPGAs? > > > Best Regards > > > Carlos -- Best regards, Florian Fainelli Email: florian at openwrt.org Web: http://openwrt.org IRC: [florian] on irc.freenode.net ------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 201 bytes Desc: This is a digitally signed message part. URL: From wolfgang at qi-hardware.com Thu Sep 10 02:22:35 2009 From: wolfgang at qi-hardware.com (Wolfgang Spraul) Date: Thu, 10 Sep 2009 02:22:35 -0400 Subject: qi-avt2 new features In-Reply-To: <19ebea720909071558t469942fbt946ae1b887ca9be1@mail.gmail.com> References: <19ebea720909071558t469942fbt946ae1b887ca9be1@mail.gmail.com> Message-ID: <20090910062235.GA3119@debian> Carlos, thanks a lot for the suggestions, I added them to the (growing) list at http://www.qi-hardware.com/products/ya-nanonote/ I encourage you, and everybody else, to read through the whole list at that page. Hardware it not as configurable as software. Not nearly ;-) So we cannot possibly build the Ya NanoNote with all good ideas that have already been discussed and will be discussed going forward. Instead, I think we need to look at the whole list and find a really neat and functional subset, and keep the device open enough to be taken in all those directions that weren't possible 'off the shelf'. Maybe others can build derivative versions of the device? Any suggestions to make this easier are also very welcome, such as your suggestion to use QFP/QFN packaging instead of BGA or COB. Anyway, thanks a lot for your feedback, keep it coming... Wolfgang On Mon, Sep 07, 2009 at 05:58:13PM -0500, Carlos Camargo wrote: > I was thinking about new qi-avt2 features, specially power consumption and > SDRAM memory size. > > 1. The current design qi-avt2 use a keyboard that use a whole layer, We will > use this space if we use a capacitive keyboard with a cypress controller, In > the past we use [1], with our ARM board and we program the cypress chip with > the processor GPIOs. Whit this, we have enough space to place another SDRAM > chip on qi-avt2, and we will have up to 128MB of SDRAM, enough for many > applications. > > 2. I prefer use a light sensor for controlling the LCD brightness and detect > if the device is close. > > 3. I was thinking in the possible use of a FPGA in the design, I think that > this FPGA would provide some peripherals like PWMs, for servo controlling, > There are an open project that we can use with it [2]. Or drive an analog > acquisition card for experiments like [3] > > [1] http://m8cutils.sourceforge.net/ > [2] http://playerstage.sourceforge.net/ > [3] http://www.vernier.com/physics/ > > Carlos > > > -- > Carlos Iv?n Camargo Bare?o > Profesor Asistente > Departamento de Ingenier?a El?ctrica y Electr?nica > Universidad Nacional de Colombia > cicamargoba at unal.edu.co > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer From deng.ya.nuo at gmail.com Thu Sep 10 02:34:32 2009 From: deng.ya.nuo at gmail.com (deng_ya_nuo) Date: Thu, 10 Sep 2009 14:34:32 +0800 Subject: Lattice or Xilinx In-Reply-To: <19ebea720909092012ib20ae76q9ed4e54b1490dc50@mail.gmail.com> References: <19ebea720909092012ib20ae76q9ed4e54b1490dc50@mail.gmail.com> Message-ID: Hi All, To my point : 1. the capability : this decide how large project you can put into the FPGA. 1.1 the lattice XP2-5 's is 5k 1.2 the Xilinx XC3S250E is 5 k 1.3 I think 5K is a good start point for us. 2. the price, the size , the power consume, and etc. 2.1 the Lattice's XP2 serial FPGA can be used directorily. No another config FLASH is needed. 2.2 the Xilinx, the Altera's FPGA need another config FLASH to work together. So it need more size, more power consume. 2.3 the Lattice is small then the Xillinx and Altera, so the price is good than the other two. 2.4. the Lattice is famous supplier for China military, early than the other two, and most military device use lattice now( As I know, in Xi'An). So the quality is good enough. So, the remain thing is : what should we put into the FPGA ? we will have to decide what capability the FPGA should have. 2009/9/10 Carlos Camargo : > Hi > > As you know, we are planning add a FPGA to the new Nano. I want to start a > discussion about what is the best family for nano, what I care about is: > > Power consumption > Size > Free tools for programming / configuration > Price > Available logic, RAM, multipliers, etc > > > At present I'm using Xilinx Spartan 3E FPGAs, but I don't have enough > experience with Altera, or Lattice, Can you please talk us about your > experiences with Lattice and Altera FPGAs? > > > Best Regards > > > Carlos > > > > > > > > -- > Carlos Iv?n Camargo Bare?o > Profesor Asistente > Departamento de Ingenier?a El?ctrica y Electr?nica > Universidad Nacional de Colombia > cicamargoba at unal.edu.co > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -- from deng.ya.nuo@@gmail.com , 029-8231 2155 http://dyndyndyn.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: xilinx_spartan-3E.png Type: image/png Size: 24532 bytes Desc: not available URL: From wolfgang at qi-hardware.com Thu Sep 10 02:46:25 2009 From: wolfgang at qi-hardware.com (Wolfgang Spraul) Date: Thu, 10 Sep 2009 02:46:25 -0400 Subject: first thoughts re Nanonote In-Reply-To: <886128c30909090918y7b4031c9g42e0c40f2983f46e@mail.gmail.com> References: <886128c30909090918y7b4031c9g42e0c40f2983f46e@mail.gmail.com> Message-ID: <20090910064625.GA3147@debian> Ron, thanks a lot for your feedback! Added to the Ya product page at http://www.qi-hardware.com/products/ya-nanonote/ > > [future] Touch sensitive screen would > be a huge win. Even though it's a clamshell and has a keyboard? Resistive or capacitive? > > [future] adding an FPGA would be a > significant differentiator. Yeah many people agree with that. We just have to be clever in how the FPGA is hooked up in the system and can drive peripherals. The connections are more important here than the number of gates, for example. Which use cases do you have in mind? > > [just noodling] NN and Ardurino > might (??) be used together in creative ways Definitely agree, hopefully we find someone with Arduino experience to help us identify those 'creative ways' how the NanoNote can work with an Arduino board. Just putting an AVR controller on the NanoNote PCB and running Arduino programs on the NanoNote (for example) doesn't sound right to me. The NanoNote should not replace Arduino, but complement it. Maybe a mobile Arduino development device? Best Regards, Wolfgang On Wed, Sep 09, 2009 at 09:18:31AM -0700, Ron K. Jeffries wrote: > THANKS to Michael Shilo and Steve Mosher > I temporarily have a Nanonote (with > original keyboard and software). > > Thursday night Sep 10 I'll share NN with > Santa Barbara Linux User Group, which > includes a developer for the original > SLUG porting efforts on Linksys NSLU. > > a few thoughts, 1/10th baked at best: > > > NN could be a great tool for kids > to learn programming. > > > Don't ignore the possibility of a > completely open PDA. My Palm V > served me well for many years. > NN does NOT require a service contract > that's a huge deal. > > > [future] Touch sensitive screen would > be a huge win. > > > [future] adding an FPGA would be a > significant differentiator. > > > [just noodling] NN and Ardurino > might (??) be used together in creative ways > > --- > Ron K. Jeffries > http://blog.eronj.com > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer From wolfgang at qi-hardware.com Thu Sep 10 02:48:33 2009 From: wolfgang at qi-hardware.com (Wolfgang Spraul) Date: Thu, 10 Sep 2009 02:48:33 -0400 Subject: first thoughts re Nanonote In-Reply-To: <2accc2ff0909091209q5fe442fck7f364b4a5eaaa2b5@mail.gmail.com> References: <886128c30909090918y7b4031c9g42e0c40f2983f46e@mail.gmail.com> <19ebea720909091008t59ae4ecevfee292cdcc2888cd@mail.gmail.com> <2accc2ff0909091209q5fe442fck7f364b4a5eaaa2b5@mail.gmail.com> Message-ID: <20090910064833.GB3147@debian> Nelson & Carlos, > > I think that the arduino's success is the API, so, many people for > > different? areas? (music, artists, etc) can use it in easy way. ... > Arduino as popular as it is now. It's something you think you don't > need... But I guess the APIs is what people get to like the most. Yes make it 3. I also believe it's the stability of the API. More than anything else I hope the NanoNote can become a stable platform with stable APIs for 5 years at least, better 10 :-) Good software, especially free software, needs time... Wolfgang On Wed, Sep 09, 2009 at 02:09:17PM -0500, Nelson Castillo wrote: > On Wed, Sep 9, 2009 at 12:08 PM, Carlos Camargo wrote: > > > > Hi > > > >> > >> > NN could be a great tool for kids > >> ?? to learn programming. > > > > Yes, I'm thinking in an application like Logo Blocks [1], or Turtle art [2] > > > > > >> > >> > [future] adding an FPGA would be a > >> ?? significant differentiator. > > > > I agree,? we can use this FPGA to interfaz Nano with real Hardware, like > > robots, acquisition cards, etc > > > >> > >> > [just noodling] NN and Ardurino > >> ?? might (??) be used together in creative ways > >> > > > > I think that the arduino's success is the API, so, many people for > > different? areas? (music, artists, etc) can use it in easy way. > > I agree. > > It amazes me to see how practitioners and artists have made the > Arduino as popular as it is now. It's something you think you don't > need... But I guess the APIs is what people get to like the most. > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer From wolfgang at qi-hardware.com Thu Sep 10 03:24:48 2009 From: wolfgang at qi-hardware.com (Wolfgang Spraul) Date: Thu, 10 Sep 2009 03:24:48 -0400 Subject: Lattice or Xilinx In-Reply-To: References: <19ebea720909092012ib20ae76q9ed4e54b1490dc50@mail.gmail.com> Message-ID: <20090910072448.GA3211@debian> Deng Ya Nuo, how about Linux tools - do the Lattice XP2 tools run under Linux? Which chips and tools (under which OS) do you work with? Wolfgang On Thu, Sep 10, 2009 at 02:34:32PM +0800, deng_ya_nuo wrote: > Hi All, > > To my point : > 1. the capability : this decide how large project you can put into the FPGA. > 1.1 the lattice XP2-5 's is 5k > 1.2 the Xilinx XC3S250E is 5 k > 1.3 I think 5K is a good start point for us. > > 2. the price, the size , the power consume, and etc. > 2.1 the Lattice's XP2 serial FPGA can be used directorily. No another > config FLASH is needed. > 2.2 the Xilinx, the Altera's FPGA need another config FLASH to work > together. So it need more size, more power consume. > 2.3 the Lattice is small then the Xillinx and Altera, so the price is > good than the other two. > 2.4. the Lattice is famous supplier for China military, early than the > other two, and most military device use lattice now( As I know, in > Xi'An). So the quality is good enough. > > So, the remain thing is : what should we put into the FPGA ? we will > have to decide what capability the FPGA should have. > > > 2009/9/10 Carlos Camargo : > > Hi > > > > As you know, we are planning add a FPGA to the new Nano. I want to start a > > discussion about what is the best family for nano, what I care about is: > > > > Power consumption > > Size > > Free tools for programming / configuration > > Price > > Available logic, RAM, multipliers, etc > > > > > > At present I'm using Xilinx Spartan 3E FPGAs, but I don't have enough > > experience with Altera, or Lattice, Can you please talk us about your > > experiences with Lattice and Altera FPGAs? > > > > > > Best Regards > > > > > > Carlos > > > > > > > > > > > > > > > > -- > > Carlos Iv?n Camargo Bare?o > > Profesor Asistente > > Departamento de Ingenier?a El?ctrica y Electr?nica > > Universidad Nacional de Colombia > > cicamargoba at unal.edu.co > > > > _______________________________________________ > > Qi Developer Mailing List > > Mail to list (members only): developer at lists.qi-hardware.com > > Subscribe or Unsubscribe: > > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > > > > > -- > from deng.ya.nuo@@gmail.com , 029-8231 2155 > http://dyndyndyn.blogspot.com/ > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer From david at tuxbrain.com Thu Sep 10 04:34:05 2009 From: david at tuxbrain.com (David Reyes Samblas Martinez) Date: Thu, 10 Sep 2009 10:34:05 +0200 Subject: first thoughts re Nanonote In-Reply-To: <20090910064625.GA3147@debian> References: <886128c30909090918y7b4031c9g42e0c40f2983f46e@mail.gmail.com> <20090910064625.GA3147@debian> Message-ID: <5c6ceea80909100134m32e0d0a1pd69bcb15272bb0e3@mail.gmail.com> 2009/9/10 Wolfgang Spraul : > Ron, > thanks a lot for your feedback! > Added to the Ya product page at > http://www.qi-hardware.com/products/ya-nanonote/ > >> > [future] Touch sensitive screen would >> ? ? be a huge win. > > Even though it's a clamshell and has a keyboard? > Resistive or capacitive? > Resistive please :), more precision and wide stylus offers out there (also a teeth wood stick from a bar ;P ) >> > [future] adding an FPGA would be a >> ? ?significant differentiator. > > Yeah many people agree with that. We just have to be clever in how > the FPGA is hooked up in the system and can drive peripherals. > The connections are more important here than the number of gates, > for example. > Which use cases do you have in mind? > >> > [just noodling] NN and Ardurino >> ? ?might (??) be used together in creative ways > > Definitely agree, hopefully we find someone with Arduino experience to help > us identify those 'creative ways' how the NanoNote can work with an Arduino > board. > Just putting an AVR controller on the NanoNote PCB and running Arduino > programs on the NanoNote (for example) doesn't sound right to me. > The NanoNote should not replace Arduino, but complement it. Maybe a mobile > Arduino development device? Just put an usb connection in host mode, main arduino boards (Mega, Duemilanove, Nano...) has an usb interface NanoNote can be a good "brain" or an HMI(Human Machine Interface) for the arduino boards > Best Regards, > Wolfgang > > On Wed, Sep 09, 2009 at 09:18:31AM -0700, Ron K. Jeffries wrote: >> THANKS to Michael Shilo and Steve Mosher >> I temporarily have a Nanonote (with >> original keyboard and software). >> >> Thursday night Sep 10 I'll share NN with >> Santa Barbara Linux User Group, which >> includes a developer for the original >> SLUG porting efforts on Linksys NSLU. >> >> a few thoughts, 1/10th baked at best: >> >> > NN could be a great tool for kids >> ? ?to learn programming. >> >> > Don't ignore the possibility of a >> ? ? completely open PDA. My Palm V >> ? ? served me well for many years. >> ? ? NN does NOT require a service contract >> ? ? that's a huge deal. >> >> > [future] Touch sensitive screen would >> ? ? be a huge win. >> >> > [future] adding an FPGA would be a >> ? ?significant differentiator. >> >> > [just noodling] NN and Ardurino >> ? ?might (??) be used together in creative ways >> >> --- >> Ron K. Jeffries >> http://blog.eronj.com > >> _______________________________________________ >> Qi Developer Mailing List >> Mail to list (members only): developer at lists.qi-hardware.com >> Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -- David Reyes Samblas Martinez http://www.tuxbrain.com Open ultraportable & embedded solutions Openmoko, Openpandora, Arduino Hey, watch out!!! There's a linux in your pocket!!! From iggarpe at gmail.com Thu Sep 10 04:42:56 2009 From: iggarpe at gmail.com (=?ISO-8859-1?Q?Ignacio_Garc=EDa_P=E9rez?=) Date: Thu, 10 Sep 2009 10:42:56 +0200 Subject: Lattice or Xilinx In-Reply-To: <19ebea720909092012ib20ae76q9ed4e54b1490dc50@mail.gmail.com> References: <19ebea720909092012ib20ae76q9ed4e54b1490dc50@mail.gmail.com> Message-ID: <9f2feba00909100142s66093d6dj1f9e991addcc4a1e@mail.gmail.com> I would say that for a portable device the MOST important feature, by far, is the power consumption, and even the latest low power devices have comparatively (to ASICs) high power requirements. That said, I sincerely think that adding an FPGA to the NanoNote is not a good idea. IIRC, the idea is to allow the NN to be used as as the "brains" of electronics projects. In that case, the FPGA offers the BEST flexibility if you forget about the power consumption issues, but to make use of that flexibility you must place a connector with a lot of pins. And that is a lot of PCB real state, not to mention the design challenge of integrating the high-pin-count connector in the enclosure. If I was to use the NN as the controller of a project, I would just use an external microcontroller with integrated USB device port. In this case it would be certainly convenient to have +5V/100mA available in the NN port. 2009/9/10 Carlos Camargo > Hi > > As you know, we are planning add a FPGA to the new Nano. I want to start a > discussion about what is the best family for nano, what I care about is: > > Power consumption > Size > Free tools for programming / configuration > Price > Available logic, RAM, multipliers, etc > > > At present I'm using Xilinx Spartan 3E FPGAs, but I don't have enough > experience with Altera, or Lattice, Can you please talk us about your > experiences with Lattice and Altera FPGAs? > > > Best Regards > > > Carlos > > > > > > > > -- > Carlos Iv?n Camargo Bare?o > Profesor Asistente > Departamento de Ingenier?a El?ctrica y Electr?nica > Universidad Nacional de Colombia > cicamargoba at unal.edu.co > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From suyckerbol at gmail.com Thu Sep 10 05:44:19 2009 From: suyckerbol at gmail.com (W.G. van de Hulst) Date: Thu, 10 Sep 2009 11:44:19 +0200 Subject: Manuals (Re: [Company] Weekly Operations Update 36/2009) In-Reply-To: <20090910022725.GC2612@debian> References: <20090910022725.GC2612@debian> Message-ID: 2009/9/10, Wolfgang Spraul : >> I wait with bated breath... > > I apologize for asking, but I need some new ways to prey them open. What > do you plan to do with the SIMD Manual? Do you want to do some hacking? That remark was equally in jest. It's nice to have those instructions, but not essential. > open source? Where is your project/source codes? I was thinking about Rockbox to get my feet wet. That project has its own web site. In fact I'm searching for something even smaller and simpler still, such as Contiki or Nuttx to minimize the amount of C code and to get as far as possible away from the usual red tape. > You never know. It's messy. I asked the CEO of Ingenic about the 4757 on > your behalf, and he was laughing. They did that chip for one big customer > who wanted to have their own chip. Next time tell them I will be deeply honored if they use the name of a certain ancient Dutch delicacy rather than a random number such as 4758 or 4759. > I would say let's focus on the open devices in our hands, from my > perspective primarily the NanoNote of course, rather than to second > guess every chip variant Ingenic has made here or there. The number suggested a certain progression towards 4760, the one I really want. > What we need is a unified and recent Linux kernel and rootfs that runs > on as many Ingenic-based devices as possible. I understand Linux is important, but not to me. From wolfgang at qi-hardware.com Thu Sep 10 05:48:20 2009 From: wolfgang at qi-hardware.com (Wolfgang Spraul) Date: Thu, 10 Sep 2009 05:48:20 -0400 Subject: Lattice or Xilinx In-Reply-To: <9f2feba00909100142s66093d6dj1f9e991addcc4a1e@mail.gmail.com> References: <19ebea720909092012ib20ae76q9ed4e54b1490dc50@mail.gmail.com> <9f2feba00909100142s66093d6dj1f9e991addcc4a1e@mail.gmail.com> Message-ID: <20090910094820.GA3284@debian> Ignacio, > I would say that for a portable device the MOST important feature, by far, > is the power consumption, and even the latest low power devices have > comparatively (to ASICs) high power requirements. What are the lowest power consumption FPGAs you know about? How much power do they consume? I think one idea was to just leave an unpopulated place for an FPGA on the board, so we could still sell the device to regular users, but it would have an easily accessible FPGA option for hacking projects. Or we offer two versions, one with and one without FPGA? Not sure, depends on what makes sense just like you say... Wolfgang On Thu, Sep 10, 2009 at 10:42:56AM +0200, Ignacio Garc?a P?rez wrote: > I would say that for a portable device the MOST important feature, by far, > is the power consumption, and even the latest low power devices have > comparatively (to ASICs) high power requirements. > > That said, I sincerely think that adding an FPGA to the NanoNote is not a > good idea. IIRC, the idea is to allow the NN to be used as as the "brains" > of electronics projects. In that case, the FPGA offers the BEST flexibility > if you forget about the power consumption issues, but to make use of that > flexibility you must place a connector with a lot of pins. And that is a lot > of PCB real state, not to mention the design challenge of integrating the > high-pin-count connector in the enclosure. > > If I was to use the NN as the controller of a project, I would just use an > external microcontroller with integrated USB device port. In this case it > would be certainly convenient to have +5V/100mA available in the NN port. > > 2009/9/10 Carlos Camargo > > > Hi > > > > As you know, we are planning add a FPGA to the new Nano. I want to start a > > discussion about what is the best family for nano, what I care about is: > > > > Power consumption > > Size > > Free tools for programming / configuration > > Price > > Available logic, RAM, multipliers, etc > > > > > > At present I'm using Xilinx Spartan 3E FPGAs, but I don't have enough > > experience with Altera, or Lattice, Can you please talk us about your > > experiences with Lattice and Altera FPGAs? > > > > > > Best Regards > > > > > > Carlos > > > > > > > > > > > > > > > > -- > > Carlos Iv?n Camargo Bare?o > > Profesor Asistente > > Departamento de Ingenier?a El?ctrica y Electr?nica > > Universidad Nacional de Colombia > > cicamargoba at unal.edu.co > > > > _______________________________________________ > > Qi Developer Mailing List > > Mail to list (members only): developer at lists.qi-hardware.com > > Subscribe or Unsubscribe: > > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer From wolfgang at qi-hardware.com Thu Sep 10 06:46:30 2009 From: wolfgang at qi-hardware.com (Wolfgang Spraul) Date: Thu, 10 Sep 2009 06:46:30 -0400 Subject: Manuals (Re: [Company] Weekly Operations Update 36/2009) In-Reply-To: References: <20090910022725.GC2612@debian> Message-ID: <20090910104630.GA3424@debian> Hi, > That remark was equally in jest. It's nice to have those instructions, > but not essential. OK got it. In that case I suggest we wait until we have a real need. There is a lot of stuff out there already to use as a starting point. > I was thinking about Rockbox to get my feet wet. That project has its > own web site. In fact I'm searching for something even smaller and > simpler still, such as Contiki or Nuttx to minimize the amount of C > code and to get as far as possible away from the usual red tape. Got it and sounds good. Keep us posted. Simple computing is the best! Which Rockbox site do you mean? > The number suggested a certain progression towards 4760, the one I really want. Yes sure we all do. Maybe we will do a 4760 reference design or reference product with Ingenic, we will see. First we need to get the NanoNote ball rolling... > I understand Linux is important, but not to me. I was working on another product recently that used the toppers/jsp kernel, using the ITRON APIs. Interesting stuff, someone should build a device around that... Also Bas has his capabilities kernel project. Let me know which kernel or microkernel you end up running eventually... Wolfgang On Thu, Sep 10, 2009 at 11:44:19AM +0200, W.G. van de Hulst wrote: > 2009/9/10, Wolfgang Spraul : > >> I wait with bated breath... > > > > I apologize for asking, but I need some new ways to prey them open. What > > do you plan to do with the SIMD Manual? Do you want to do some hacking? > That remark was equally in jest. It's nice to have those instructions, > but not essential. > > > open source? Where is your project/source codes? > I was thinking about Rockbox to get my feet wet. That project has its > own web site. In fact I'm searching for something even smaller and > simpler still, such as Contiki or Nuttx to minimize the amount of C > code and to get as far as possible away from the usual red tape. > > > You never know. It's messy. I asked the CEO of Ingenic about the 4757 on > > your behalf, and he was laughing. They did that chip for one big customer > > who wanted to have their own chip. > Next time tell them I will be deeply honored if they use the name of a > certain ancient Dutch delicacy rather than a random number such as > 4758 or 4759. > > > I would say let's focus on the open devices in our hands, from my > > perspective primarily the NanoNote of course, rather than to second > > guess every chip variant Ingenic has made here or there. > The number suggested a certain progression towards 4760, the one I really want. > > > What we need is a unified and recent Linux kernel and rootfs that runs > > on as many Ingenic-based devices as possible. > I understand Linux is important, but not to me. > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer From iggarpe at gmail.com Thu Sep 10 07:53:18 2009 From: iggarpe at gmail.com (=?ISO-8859-1?Q?Ignacio_Garc=EDa_P=E9rez?=) Date: Thu, 10 Sep 2009 13:53:18 +0200 Subject: Lattice or Xilinx In-Reply-To: <20090910094820.GA3284@debian> References: <19ebea720909092012ib20ae76q9ed4e54b1490dc50@mail.gmail.com> <9f2feba00909100142s66093d6dj1f9e991addcc4a1e@mail.gmail.com> <20090910094820.GA3284@debian> Message-ID: <9f2feba00909100453q77481c7ap5fb9253fea91f45f@mail.gmail.com> 2009/9/10 Wolfgang Spraul > Ignacio, > > > I would say that for a portable device the MOST important feature, by > far, > > is the power consumption, and even the latest low power devices have > > comparatively (to ASICs) high power requirements. > > What are the lowest power consumption FPGAs you know about? How much power > do they consume? > The lowest power I know are actualy CPLDs (coolrunner by Xilinx). That means they have non-volatile configuration and have less logic resources as compared to FPGAs. > > I think one idea was to just leave an unpopulated place for an FPGA on the > board, so we could still sell the device to regular users, but it would > have an easily accessible FPGA option for hacking projects. > Do you really have so much spare real state on the PCB ?. Note also that you need room not only for the FPGA itself but also for: 1- Connector (huge if you want to make all those I/O pins useful). 2- A CPLD to connect the FPGA programming interface to the SoC. 3- Power regulators (for example, Spartan 6 use 1.2V core voltage), and possibly power management circuitry too to save power when no in use. And no matter what FPGA/connector you choose you won't fullfill the needs of all the potential users, which I believe will be anyway a minority in the whole user base. > Or we offer two versions, one with and one without FPGA? > In order to make that practical you'd need to share same form factors, enclosure, etc, and thus you'd be making the device possible larger than needed. Seriously, I don't think the potential user base for tinkering justifies the inclusion of an FPGA in the design. If you want to provide extensive I/O capability, just add a host USB port. Supply of external power IS A MUST, but 100mA would be more than enough (and should be switchable from the SoC). And it must be a separate USB port, different from the device port used to connect to the PC. I you want to go a bit more far, add an special connector with I2C, SPI and power. That is more than enough for the average hacker. If your project is so complex or needs so much bandwidth that hostUSB+I2C+SPI is not enough, neither the FPGA would have been (assuming and low-end, cheap and non-power-hungry FPGA). Regards. P.S: got the Ingenic docs. Just haven't had time to properly review them. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cicamargoba at gmail.com Thu Sep 10 07:57:30 2009 From: cicamargoba at gmail.com (Carlos Camargo) Date: Thu, 10 Sep 2009 06:57:30 -0500 Subject: Lattice or Xilinx In-Reply-To: References: <19ebea720909092012ib20ae76q9ed4e54b1490dc50@mail.gmail.com> Message-ID: <19ebea720909100457m794869a3wb2fb0f74783d3f23@mail.gmail.com> Hi All On Thu, Sep 10, 2009 at 1:34 AM, deng_ya_nuo wrote: > Hi All, > > To my point : > 1. the capability : this decide how large project you can put into the > FPGA. > 1.1 the lattice XP2-5 's is 5k > 1.2 the Xilinx XC3S250E is 5 k > 1.3 I think 5K is a good start point for us. > > At present I'm working with Xilinx XCS250E, I agree is a good starting point, with enough capacity for many applications. > 2. the price, the size , the power consume, and etc. > 2.1 the Lattice's XP2 serial FPGA can be used directorily. No another > config FLASH is needed. > 2.2 the Xilinx, the Altera's FPGA need another config FLASH to work > together. So it need more size, more power consume. > I disagree, I'm using a Xilinx FPGA and ARM (ATMEL) processor right now, The processor configure the FPGA using the 4 JTAG lines and xc3sprog [1], so, we store the FPGA configuration file in SD card, and I change this file at any moment. This board has access to internet, so I can reconfigure the FPGA remotly. The Xilinx Spartan 3AN family have an internal SPI serial flash, so we can use it for store the configuration file. [1] http://sourceforge.net/projects/xc3sprog/ So, the remain thing is : what should we put into the FPGA ? we will > have to decide what capability the FPGA should have. > > This is a good point, As i said, I think that the FPGA will be useful for control many servos for robotic applications, or controlling an analog acquisition card. Carlos -- Carlos Iv?n Camargo Bare?o Profesor Asistente Departamento de Ingenier?a El?ctrica y Electr?nica Universidad Nacional de Colombia cicamargoba at unal.edu.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From cicamargoba at gmail.com Thu Sep 10 08:06:59 2009 From: cicamargoba at gmail.com (Carlos Camargo) Date: Thu, 10 Sep 2009 07:06:59 -0500 Subject: Lattice or Xilinx In-Reply-To: <9f2feba00909100142s66093d6dj1f9e991addcc4a1e@mail.gmail.com> References: <19ebea720909092012ib20ae76q9ed4e54b1490dc50@mail.gmail.com> <9f2feba00909100142s66093d6dj1f9e991addcc4a1e@mail.gmail.com> Message-ID: <19ebea720909100506i4f4b6ba0s1671c3e311f3e89e@mail.gmail.com> Hi Ignacio I would say that for a portable device the MOST important feature, by far, > is the power consumption, and even the latest low power devices have > comparatively (to ASICs) high power requirements. > I have a FPGA - ARM processor design, in wich the processor can control the FPGA clock, so, I can Enable the FPGA logic at any moment, but you're right, The FPGA increase the power consumption, so is necessary find a way to control it. > > That said, I sincerely think that adding an FPGA to the NanoNote is not a > good idea. IIRC, the idea is to allow the NN to be used as as the "brains" > of electronics projects. In that case, the FPGA offers the BEST flexibility > if you forget about the power consumption issues, but to make use of that > flexibility you must place a connector with a lot of pins. And that is a lot > of PCB real state, not to mention the design challenge of integrating the > high-pin-count connector in the enclosure. > > I agree, adding a FPGA is not an easy work, is necessary add an external connector with many pins, I like your idea, similar to David Reyes sugestion. If we using Nano as brain, and enable some ports for external use, like I2C, SPI, USB host, we can design a lot of interesting applications. I think that a good Idea woul be make accessible the data, address and control processor bus, so, the people can build custom boards with any FPGA. Cordial saludo Carlos If I was to use the NN as the controller of a project, I would just use an > external microcontroller with integrated USB device port. In this case it > would be certainly convenient to have +5V/100mA available in the NN port. > > 2009/9/10 Carlos Camargo > >> Hi >> >> >> As you know, we are planning add a FPGA to the new Nano. I want to start a >> discussion about what is the best family for nano, what I care about is: >> >> Power consumption >> Size >> Free tools for programming / configuration >> Price >> Available logic, RAM, multipliers, etc >> >> >> At present I'm using Xilinx Spartan 3E FPGAs, but I don't have enough >> experience with Altera, or Lattice, Can you please talk us about your >> experiences with Lattice and Altera FPGAs? >> >> >> Best Regards >> >> >> Carlos >> >> >> >> >> >> >> >> -- >> Carlos Iv?n Camargo Bare?o >> Profesor Asistente >> Departamento de Ingenier?a El?ctrica y Electr?nica >> Universidad Nacional de Colombia >> cicamargoba at unal.edu.co >> >> _______________________________________________ >> Qi Developer Mailing List >> Mail to list (members only): developer at lists.qi-hardware.com >> Subscribe or Unsubscribe: >> http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer >> > > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -- Carlos Iv?n Camargo Bare?o Profesor Asistente Departamento de Ingenier?a El?ctrica y Electr?nica Universidad Nacional de Colombia cicamargoba at unal.edu.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From cicamargoba at gmail.com Thu Sep 10 08:14:41 2009 From: cicamargoba at gmail.com (Carlos Camargo) Date: Thu, 10 Sep 2009 07:14:41 -0500 Subject: Lattice or Xilinx In-Reply-To: <9f2feba00909100453q77481c7ap5fb9253fea91f45f@mail.gmail.com> References: <19ebea720909092012ib20ae76q9ed4e54b1490dc50@mail.gmail.com> <9f2feba00909100142s66093d6dj1f9e991addcc4a1e@mail.gmail.com> <20090910094820.GA3284@debian> <9f2feba00909100453q77481c7ap5fb9253fea91f45f@mail.gmail.com> Message-ID: <19ebea720909100514g2ae9c674u1afbb0bceebb3e98@mail.gmail.com> Hola Ignacio > The lowest power I know are actualy CPLDs (coolrunner by Xilinx). That > means they have non-volatile configuration and have less logic resources as > compared to FPGAs. > But, the logic capacity is very low, but may be enough for some applications. > 1- Connector (huge if you want to make all those I/O pins useful). > 2- A CPLD to connect the FPGA programming interface to the SoC. > 3- Power regulators (for example, Spartan 6 use 1.2V core voltage), and > possibly power management circuitry too to save power when no in use. > > The CPLD is not necessary, as I said before you can use some processor GPIO pins for JTAG programming. And no matter what FPGA/connector you choose you won't fullfill the needs of > all the potential users, which I believe will be anyway a minority in the > whole user base. > I agree, I think that if place an internal connector with D0-D15, A0-A14, RD, WR, CSX, and some GPIOs many people (like me ) can build his own boards with any CPLD. The USB port idea is very good, we can design some reference boards, for use it. Carlos -- Carlos Iv?n Camargo Bare?o Profesor Asistente Departamento de Ingenier?a El?ctrica y Electr?nica Universidad Nacional de Colombia cicamargoba at unal.edu.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From wolfgang at qi-hardware.com Thu Sep 10 10:21:58 2009 From: wolfgang at qi-hardware.com (Wolfgang Spraul) Date: Thu, 10 Sep 2009 10:21:58 -0400 Subject: Lattice or Xilinx In-Reply-To: <9f2feba00909100453q77481c7ap5fb9253fea91f45f@mail.gmail.com> References: <19ebea720909092012ib20ae76q9ed4e54b1490dc50@mail.gmail.com> <9f2feba00909100142s66093d6dj1f9e991addcc4a1e@mail.gmail.com> <20090910094820.GA3284@debian> <9f2feba00909100453q77481c7ap5fb9253fea91f45f@mail.gmail.com> Message-ID: <20090910142158.GA3606@debian> Ignacio and Carlos, the FPGA discussion is actually a good way to better explain some of our plans at Qi Hardware. We believe in open innovation, and we believe in delivering real value to real people asap. These two are always a bit at odds with each other, maintaining the balance will be a big challenge for the Qi core team. With 'open innovation', we mean to take the best that the open community has developed, package it, and have it solve real problems of non-technical people today. While at the same time not cutting off the cycle of further _open_ innovation. Does that make sense? So we would not want to add a closed GUI on top of our open kernel. Or closed hardware underneath our open kernel. But while we strive for 100% openess (and copyleft to get some power behind it), we also have a razor-sharp focus on solving real problems in real life. Qi Hardware is not a supplier of geek toys. The list of ideas at the Ya NanoNote page is becoming impressive: http://www.qi-hardware.com/products/ya-nanonote/ But these are not all the things we will add, which would turn the NanoNote into the ultimate jack-of-all-trades, and guaranteed failure. These are all the things we want to keep the device open for! Maybe these are all the things we will not do, and someone else can take and produce a derivative device. Will we add a power-hungry, space-consuming and expensive FPGA to all Ya NanoNotes, even though it may only serve a real purpose for 1% of our NanoNote buyers? Of course not! But at the same time we believe in open innovation, and the innovation needs to come from somewhere. So one idea could be to only make a few small, ideally zero-cost improvements from the Ben to the Ya NanoNote. Routing a few more pins to test points, adding USB host (which is only another connector since it's already in the SoC), increasing SDRAM to 64 MB. But that would be it. And then we make a small-volume 2nd variant of the PCB. A 'hacker PCB' that would fit into the case, but you would have to cut a hole into the case on one side, and the hacker PCB would stick out by a few centimeters. Then that 'excess' PCB space could be filled with connectors, FPGA, etc. It would be ugly, but not uglier than an open Arduino board for example. We could make 500 of these hacker PCBs, or 1000, however large we are able to grow our developer community. But the main mass-market Ya NanoNote would not be affected. That one would still be a cheap, polished, low-cost computing device, delivering to the world the very best the free software and free culture scene have developed. Powered by a Linux kernel, offering Wikipedia, Wiktionary, OpenStreetMaps, MPlayer and other useful free software apps. As much as we can package and deliver in good quality. Does all of this make sense? Do we even all agree? Qi Hardware is young, so some of these thoughts are not battle tested yet, but I believe it's more or less the direction we are heading to. I hope it explains why we happily discuss FPGA chips, but at the same time are focused on making cheap mass-market devices. Feedback very welcome, Wolfgang On Thu, Sep 10, 2009 at 01:53:18PM +0200, Ignacio Garc?a P?rez wrote: > 2009/9/10 Wolfgang Spraul > > > Ignacio, > > > > > I would say that for a portable device the MOST important feature, by > > far, > > > is the power consumption, and even the latest low power devices have > > > comparatively (to ASICs) high power requirements. > > > > What are the lowest power consumption FPGAs you know about? How much power > > do they consume? > > > > The lowest power I know are actualy CPLDs (coolrunner by Xilinx). That means > they have non-volatile configuration and have less logic resources as > compared to FPGAs. > > > > > > I think one idea was to just leave an unpopulated place for an FPGA on the > > board, so we could still sell the device to regular users, but it would > > have an easily accessible FPGA option for hacking projects. > > > > Do you really have so much spare real state on the PCB ?. > > Note also that you need room not only for the FPGA itself but also for: > > 1- Connector (huge if you want to make all those I/O pins useful). > 2- A CPLD to connect the FPGA programming interface to the SoC. > 3- Power regulators (for example, Spartan 6 use 1.2V core voltage), and > possibly power management circuitry too to save power when no in use. > > And no matter what FPGA/connector you choose you won't fullfill the needs of > all the potential users, which I believe will be anyway a minority in the > whole user base. > > > > Or we offer two versions, one with and one without FPGA? > > > > In order to make that practical you'd need to share same form factors, > enclosure, etc, and thus you'd be making the device possible larger than > needed. > > Seriously, I don't think the potential user base for tinkering justifies the > inclusion of an FPGA in the design. If you want to provide extensive I/O > capability, just add a host USB port. Supply of external power IS A MUST, > but 100mA would be more than enough (and should be switchable from the SoC). > And it must be a separate USB port, different from the device port used to > connect to the PC. I you want to go a bit more far, add an special connector > with I2C, SPI and power. > > That is more than enough for the average hacker. If your project is so > complex or needs so much bandwidth that hostUSB+I2C+SPI is not enough, > neither the FPGA would have been (assuming and low-end, cheap and > non-power-hungry FPGA). > > Regards. > > P.S: got the Ingenic docs. Just haven't had time to properly review them. > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer From iggarpe at gmail.com Thu Sep 10 10:25:53 2009 From: iggarpe at gmail.com (=?ISO-8859-1?Q?Ignacio_Garc=EDa_P=E9rez?=) Date: Thu, 10 Sep 2009 16:25:53 +0200 Subject: Lattice or Xilinx In-Reply-To: <19ebea720909100506i4f4b6ba0s1671c3e311f3e89e@mail.gmail.com> References: <19ebea720909092012ib20ae76q9ed4e54b1490dc50@mail.gmail.com> <9f2feba00909100142s66093d6dj1f9e991addcc4a1e@mail.gmail.com> <19ebea720909100506i4f4b6ba0s1671c3e311f3e89e@mail.gmail.com> Message-ID: <9f2feba00909100725k289a7fb7of43dd0f8c34e8549@mail.gmail.com> > > > I agree, adding a FPGA is not an easy work, is necessary add an external > connector with many pins, I like your idea, similar to David Reyes > sugestion. If we using Nano as brain, and enable some ports for external > use, like I2C, SPI, USB host, we can design a lot of interesting > applications. > > I think that a good Idea woul be make accessible the data, address and > control processor bus, so, the people can build custom boards with any FPGA. > That would still require a huge connector with a lot of pins. I can't think of an application where USB or SPI (I've driven it sometimes at 25MHz) would not suffice. (Well, actually I can, but if one wants to build something with such a high bandwidth requirement to the CPU, you're better off using an embedded computer instead of a NN). Un saludo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rakshat at gmail.com Thu Sep 10 12:18:23 2009 From: rakshat at gmail.com (rakshat hooja) Date: Thu, 10 Sep 2009 21:48:23 +0530 Subject: flash player on MIPS Message-ID: <69a2e4550909100918o55662057nc8a01cc8505423cd@mail.gmail.com> I was just discussing the NanoNote with a colleague and he mentioned that there are no usable Flash players for MIPS. I googled and found Xip Flash player (http://www.xiptech.com/) but was wondering if anyone knows of other Flash players? Rakshat -- -------------- Please use Firefox as your web browser. Its protects you from spyware and is also a very feature rich browser. www.firefox.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From leonardkr at gmail.com Thu Sep 10 12:42:31 2009 From: leonardkr at gmail.com (Leonard Krajewski) Date: Thu, 10 Sep 2009 18:42:31 +0200 Subject: flash player on MIPS In-Reply-To: <69a2e4550909100918o55662057nc8a01cc8505423cd@mail.gmail.com> References: <69a2e4550909100918o55662057nc8a01cc8505423cd@mail.gmail.com> Message-ID: <422808530909100942u32c1a8b1u4d2c33d05a32301f@mail.gmail.com> What about porting gnash? 2009/9/10 rakshat hooja > I was just discussing the NanoNote with a colleague and he mentioned that > there are no usable Flash players for MIPS. I googled and found Xip Flash > player (http://www.xiptech.com/) but was wondering if anyone knows of > other Flash players? > > Rakshat > > -- > -------------- > Please use Firefox as your web browser. Its protects you from spyware and > is also a very feature rich browser. > www.firefox.com > > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -- Leonard Krajewski Cz?owiek z Charakterem :D -------------- next part -------------- An HTML attachment was scrubbed... URL: From cicamargoba at gmail.com Thu Sep 10 15:26:19 2009 From: cicamargoba at gmail.com (Carlos Camargo) Date: Thu, 10 Sep 2009 14:26:19 -0500 Subject: USB serial console Message-ID: <19ebea720909101226n21fb6c71j64996a76a87e7dc1@mail.gmail.com> HI I'm working with my custom JZ4725 board, I'm using linux 2.6.24.3 with g_serial driver. I can run one console on /dev/ttygserial, so, we don't need any USB/serial cable right now. I can't find the application getty on openwrt, I've already used mgetty, but it doesn't work. I try with an openembedded distro, this distro provide getty so, I can use it to enable the USB serial console. Is possible add getty to openwrt? Best Regards Carlos -- Carlos Iv?n Camargo Bare?o Profesor Asistente Departamento de Ingenier?a El?ctrica y Electr?nica Universidad Nacional de Colombia cicamargoba at unal.edu.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjeffries at gmail.com Thu Sep 10 16:01:08 2009 From: rjeffries at gmail.com (Ron K. Jeffries) Date: Thu, 10 Sep 2009 13:01:08 -0700 Subject: Wikitravel Message-ID: <886128c30909101301r54588a14uc6d55d66a7e2216e@mail.gmail.com> *Evan* Prodromou is one of two founders of Wikitravel.org, and also runs the http://identi.ca microblogging service which is totally FOSS. Today I opened an UNOFFICIAL "group" on identi.ca nanonote (a clever name, yes?) I hope qi-hardware developers will join and use identi.ca, the OPEN alternative to Twitter. ;) --- Ron K. Jeffries http://identri.ca/rkj -------------- next part -------------- An HTML attachment was scrubbed... URL: From uwe at hermann-uwe.de Thu Sep 10 16:27:04 2009 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 10 Sep 2009 22:27:04 +0200 Subject: Wikitravel In-Reply-To: <886128c30909101301r54588a14uc6d55d66a7e2216e@mail.gmail.com> References: <886128c30909101301r54588a14uc6d55d66a7e2216e@mail.gmail.com> Message-ID: <20090910202704.GA22053@greenwood> On Thu, Sep 10, 2009 at 01:01:08PM -0700, Ron K. Jeffries wrote: > *Evan* Prodromou is one of two founders of Wikitravel.org, and also runs the > http://identi.ca microblogging service which is totally FOSS. > > Today I opened an UNOFFICIAL "group" on identi.ca nanonote > (a clever name, yes?) > > I hope qi-hardware developers will join and use identi.ca, the OPEN > alternative to Twitter. ;) Some already do, see http://identi.ca/group/qihardware http://identi.ca/qihardware But an explicit group for the NanoNote is nice anyway as there will be more products in the future (IMHO). Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org From wolfgang at qi-hardware.com Thu Sep 10 21:14:50 2009 From: wolfgang at qi-hardware.com (Wolfgang Spraul) Date: Thu, 10 Sep 2009 21:14:50 -0400 Subject: flash player on MIPS In-Reply-To: <422808530909100942u32c1a8b1u4d2c33d05a32301f@mail.gmail.com> References: <69a2e4550909100918o55662057nc8a01cc8505423cd@mail.gmail.com> <422808530909100942u32c1a8b1u4d2c33d05a32301f@mail.gmail.com> Message-ID: <20090911011450.GA3717@debian> Rakshat, is xiptech free software? My first idea would also be gnash, but last time I checked it was seriously behind Adobe, and falling further behind. Of course the problem is also that Adobe keeps investing in more and more closed technology, so chasing them is kind of hard. One random example from many: Adobe is using their own proprietary back-end for LLVM (a BSD-style licensed compiler that companies like Apple, Nvidia, Adobe prefer over GCC), so even if they release source codes, you still cannot produce binaries with matching performance :-) Still, anyway, I'd say the long road starts with gnash. Or free formats right away, not Flash. Wolfgang On Thu, Sep 10, 2009 at 06:42:31PM +0200, Leonard Krajewski wrote: > What about porting gnash? > > 2009/9/10 rakshat hooja > > > I was just discussing the NanoNote with a colleague and he mentioned that > > there are no usable Flash players for MIPS. I googled and found Xip Flash > > player (http://www.xiptech.com/) but was wondering if anyone knows of > > other Flash players? > > > > Rakshat > > > > -- > > -------------- > > Please use Firefox as your web browser. Its protects you from spyware and > > is also a very feature rich browser. > > www.firefox.com > > > > > > _______________________________________________ > > Qi Developer Mailing List > > Mail to list (members only): developer at lists.qi-hardware.com > > Subscribe or Unsubscribe: > > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > > > > > -- > Leonard Krajewski Cz?owiek z Charakterem :D > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer From kzjeef at gmail.com Thu Sep 10 21:17:49 2009 From: kzjeef at gmail.com (ZhangJieJing) Date: Fri, 11 Sep 2009 09:17:49 +0800 Subject: USB serial console In-Reply-To: <19ebea720909101226n21fb6c71j64996a76a87e7dc1@mail.gmail.com> References: <19ebea720909101226n21fb6c71j64996a76a87e7dc1@mail.gmail.com> Message-ID: On Fri, Sep 11, 2009 at 3:26 AM, Carlos Camargo wrote: > HI > > I'm working with my custom JZ4725 board, I'm using linux 2.6.24.3 with > g_serial driver. I can run one console on /dev/ttygserial, so, we don't need > any USB/serial cable right now. > I think it means USB driver works. g_serial driver only work after this kernel module loaded, so it maybe cann't work when you debugging kernel. But it's Ok, if you focus on application level. > > I can't find the application getty on openwrt, I've already used mgetty, > but it doesn't work. I try with an openembedded distro, this distro provide > getty so, I can use it to enable the USB serial console. > > Is possible add getty to openwrt? > > I found a 'megetty' . kzj at kzj-desktop:~/project/openwrt-x-burst/scripts$ ./feeds search getty Search results in feed 'packages': mgetty A data/fax solution for your analog modem maybe you can try it. > > Best Regards > > Carlos > > > -- > Carlos Iv?n Camargo Bare?o > Profesor Asistente > Departamento de Ingenier?a El?ctrica y Electr?nica > Universidad Nacional de Colombia > cicamargoba at unal.edu.co > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yajinzhou at vm-kernel.org Thu Sep 10 21:23:41 2009 From: yajinzhou at vm-kernel.org (yajin) Date: Fri, 11 Sep 2009 09:23:41 +0800 Subject: flash player on MIPS In-Reply-To: <69a2e4550909100918o55662057nc8a01cc8505423cd@mail.gmail.com> References: <69a2e4550909100918o55662057nc8a01cc8505423cd@mail.gmail.com> Message-ID: <180e2c240909101823o5d45573fve9d7930a617c854b@mail.gmail.com> I have used swfdec my gdium, a loongson cpu based netbook and it works well. It can render youtube videos well. yajin http://vm-kernel.org On Fri, Sep 11, 2009 at 12:18 AM, rakshat hooja wrote: > I was just discussing the NanoNote with a colleague and he mentioned that > there are no usable Flash players for MIPS. I googled and found Xip Flash > player (http://www.xiptech.com/) but was wondering if anyone knows of other > Flash players? > > Rakshat > > -- > -------------- > Please use Firefox as your web browser. Its protects you from spyware and is > also a very feature rich browser. > www.firefox.com > > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > From wolfgang at qi-hardware.com Thu Sep 10 21:56:12 2009 From: wolfgang at qi-hardware.com (Wolfgang Spraul) Date: Thu, 10 Sep 2009 21:56:12 -0400 Subject: flash player on MIPS In-Reply-To: <180e2c240909101823o5d45573fve9d7930a617c854b@mail.gmail.com> References: <69a2e4550909100918o55662057nc8a01cc8505423cd@mail.gmail.com> <180e2c240909101823o5d45573fve9d7930a617c854b@mail.gmail.com> Message-ID: <20090911015612.GA3744@debian> Yajin, oh wow great, this seems better than gnash. Thanks a lot for the link, so maybe we should try swfdec first... Wolfgang On Fri, Sep 11, 2009 at 09:23:41AM +0800, yajin wrote: > I have used swfdec my gdium, a loongson cpu based netbook and it works > well. It can render youtube videos well. > > yajin > > http://vm-kernel.org > > > > On Fri, Sep 11, 2009 at 12:18 AM, rakshat hooja wrote: > > I was just discussing the NanoNote with a colleague and he mentioned that > > there are no usable Flash players for MIPS. I googled and found Xip Flash > > player (http://www.xiptech.com/) but was wondering if anyone knows of other > > Flash players? > > > > Rakshat > > > > -- > > -------------- > > Please use Firefox as your web browser. Its protects you from spyware and is > > also a very feature rich browser. > > www.firefox.com > > > > > > _______________________________________________ > > Qi Developer Mailing List > > Mail to list (members only): developer at lists.qi-hardware.com > > Subscribe or Unsubscribe: > > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer From adam at qi-hardware.com Fri Sep 11 04:38:02 2009 From: adam at qi-hardware.com (Adam Wang) Date: Fri, 11 Sep 2009 16:38:02 +0800 Subject: qi_avt2 v1.0 board status Message-ID: <4AAA0C6A.5050409@qi-hardware.com> Hi All, We're now on the process to produce small run of avt2 board, here is the top side of avt2 without jz4720 temporarily; http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/smt/pictures/top.jpg Will keep you posted later. Adam From iggarpe at gmail.com Fri Sep 11 05:27:17 2009 From: iggarpe at gmail.com (=?ISO-8859-1?Q?Ignacio_Garc=EDa_P=E9rez?=) Date: Fri, 11 Sep 2009 11:27:17 +0200 Subject: USB serial console In-Reply-To: <19ebea720909101226n21fb6c71j64996a76a87e7dc1@mail.gmail.com> References: <19ebea720909101226n21fb6c71j64996a76a87e7dc1@mail.gmail.com> Message-ID: <9f2feba00909110227q154b2eb6yaa298b144e9dba20@mail.gmail.com> Earlier releases of Dingux had a g_serial console too, but it had some inconveniences, for example file transfer is possible but a pain in the ass. So I moved to ethernet gadget. The interface is set as 10.1.0.2/30 and a DHCP server is configured to provide only one lease which is always 10.1.0.1/30. Inetd is also launched and telnet/ftp services are provided through it. When the system boots, the PC soon sees a new ethernet card which is autoconfigured v?a the DHCP server. Then you can access the console v?a telnet and transfer files v?a FTP. If you consider this approach, some remarks about the 2.6.24.3 Ingenic kernel: 1- You must modify the code to enable CDC mode in your code (drivers/usb/gadget/ether.c). 2- The code needs an small fix so Windows will recognize the ethernet card (see file above in the dingux kernel source). 3- Something is badly broken either in the Ingenic USB device or DMA code. The ethernet gadget only works reliably if you disable DMA (put jz4740_udc.use_dma=0 in the kernel command line). This halves throughput but works. I believe the DMA problem is not specific to the ethernet gadget code. I mean it should be present also when using the g_serial gadget. However, only shows up when using the full bandwidth, which rarely happens on a serial console. Regards. 2009/9/10 Carlos Camargo > HI > > I'm working with my custom JZ4725 board, I'm using linux 2.6.24.3 with > g_serial driver. I can run one console on /dev/ttygserial, so, we don't need > any USB/serial cable right now. > > I can't find the application getty on openwrt, I've already used mgetty, > but it doesn't work. I try with an openembedded distro, this distro provide > getty so, I can use it to enable the USB serial console. > > Is possible add getty to openwrt? > > > Best Regards > > Carlos > > > -- > Carlos Iv?n Camargo Bare?o > Profesor Asistente > Departamento de Ingenier?a El?ctrica y Electr?nica > Universidad Nacional de Colombia > cicamargoba at unal.edu.co > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iggarpe at gmail.com Fri Sep 11 05:36:33 2009 From: iggarpe at gmail.com (=?ISO-8859-1?Q?Ignacio_Garc=EDa_P=E9rez?=) Date: Fri, 11 Sep 2009 11:36:33 +0200 Subject: Lattice or Xilinx In-Reply-To: <20090910142158.GA3606@debian> References: <19ebea720909092012ib20ae76q9ed4e54b1490dc50@mail.gmail.com> <9f2feba00909100142s66093d6dj1f9e991addcc4a1e@mail.gmail.com> <20090910094820.GA3284@debian> <9f2feba00909100453q77481c7ap5fb9253fea91f45f@mail.gmail.com> <20090910142158.GA3606@debian> Message-ID: <9f2feba00909110236u4586b3ej7bf2c8ebf17eb455@mail.gmail.com> > > > > Will we add a power-hungry, space-consuming and expensive FPGA to all Ya > NanoNotes, even though it may only serve a real purpose for 1% of our > NanoNote buyers? Of course not! > But at the same time we believe in open innovation, and the innovation > needs to come from somewhere. So one idea could be to only make a few > small, ideally zero-cost improvements from the Ben to the Ya NanoNote. > Routing a few more pins to test points, adding USB host (which is only > another connector since it's already in the SoC), increasing SDRAM > to 64 MB. But that would be it. > I agree and I think I got the point from the beginning. It was hard to believe an FPGA was going to get its way into the NN, but it is always worth discussin the idea. > > And then we make a small-volume 2nd variant of the PCB. A 'hacker PCB' > that would fit into the case, but you would have to cut a hole into > the case on one side, and the hacker PCB would stick out by a few > centimeters. > Then that 'excess' PCB space could be filled with connectors, FPGA, > etc. It would be ugly, but not uglier than an open Arduino board for > example. We could make 500 of these hacker PCBs, or 1000, however > large we are able to grow our developer community. > But the main mass-market Ya NanoNote would not be affected. > I still think that if you want to empower the electronics hacker user base, you're better off providing a separate board which connects via USB/SPI/I2C to the NN. You end up with the same system and only have to manage one NN model. And it would be easier to modify the expansion board or even have several models with different FPGA, uC, etc. Those can be independent open hardware/software projects. Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From iggarpe at gmail.com Fri Sep 11 05:40:37 2009 From: iggarpe at gmail.com (=?ISO-8859-1?Q?Ignacio_Garc=EDa_P=E9rez?=) Date: Fri, 11 Sep 2009 11:40:37 +0200 Subject: configure mpd/mpc in openwrt. music player in Ben NanoNote In-Reply-To: References: <4AA463E5.5090802@qi-hardware.com> <19ebea720909071630t1a680beexf5d62ec2084090ba@mail.gmail.com> <4AA5B590.5000000@qi-hardware.com> Message-ID: <9f2feba00909110240s4169fe78mfe38db486e30fc1d@mail.gmail.com> I never got ALSA to work on the A320 (dingux). Instead I tried OSS and as it worked I forgot about ALSA. The OSS code, though, seems to be deprecated by Ingenic and is very very very ugly and buggy. Had to make several fixes to get sample rates other than S16_LE working. However, sticking to OSS because "it just works" is probably only acceptable in the A320 case because it is intended to be used as a gaming console and as such almost eveybody is using the SDL, which dingux provides precompiled and configured for OSS. 2009/9/8 ZhangJieJing > Hi, > > Sound card on my kernel tree is just can be found by alsa driver, But the > driver have problem with DMA(jz's driver use too old DMA method) I 'm trying > to fix it. > > The sound cann't play for now. > --- > Best regards, > Zhang Jiejing > > > > On Tue, Sep 8, 2009 at 9:38 AM, Xiangfu Liu wrote: > >> Carlos Camargo wrote: >> > Hi >> > >> > We are trying to test the sound driver, with alsa, mplayer, but doesn't >> > work :( The Qi kernel source support the JZ sound driver? If not, where >> > can I foun information about this driver? >> >> the Qi kernel not support JZ sound driver not. Jieijing Zhang and larsc >> work on that. >> >> you can find the Jieijing Zhange sound code: >> >> http://projects.qi-hardware.com/index.php/p/kzjeef-kernel/source/changes/master/ >> >> you can find JZ 2.6.27 sound driver at: >> http://downloads.qi-hardware.com/software/sources/linux-2.6.27.git.svn.tgz >> >> > >> > >> > $ scripts/feeds install mpd >> > $ scripts/feeds install mpc >> >> run 'scripts/feeds update' before install mpd/mpc. >> >> > >> > I try to run this command but I get the following error: >> > >> > Ignoring feed 'packages' - index missing >> > Ignoring feed 'xwrt' - index missing >> > Ignoring feed 'luci' - index missing >> > WARNING: No feed for package 'mpd' found, maybe it's already part of the >> > standard packages? >> > >> > >> > >> > Carlos >> > >> > >> > >> > On Sun, Sep 6, 2009 at 8:37 PM, Xiangfu Liu > > > wrote: >> > >> > >> > 1. in terminal, under openwrt folder run >> > >> > >> > >> > 2. run [make menuconfig] then select --> sound --> enable [mpc] >> [mpd] >> > 3. run [make menuconfig] --> Base System --> enable [libstdcpp] >> > >> > then you run make. you will get the [mpd] [mpc] in you rootfs. >> > you need change the [/etc/mpd.conf] to make the mpd work. >> > >> >> _______________________________________________ >> Qi Developer Mailing List >> Mail to list (members only): developer at lists.qi-hardware.com >> Subscribe or Unsubscribe: >> http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer >> > > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cicamargoba at gmail.com Fri Sep 11 07:55:27 2009 From: cicamargoba at gmail.com (Carlos Camargo) Date: Fri, 11 Sep 2009 06:55:27 -0500 Subject: qi_avt2 v1.0 board status In-Reply-To: <4AAA0C6A.5050409@qi-hardware.com> References: <4AAA0C6A.5050409@qi-hardware.com> Message-ID: <19ebea720909110455k69577555mdbe4ae1ea9d8b952@mail.gmail.com> Hi Adam This board looks very good. Carlos On Fri, Sep 11, 2009 at 3:38 AM, Adam Wang wrote: > Hi All, > > We're now on the process to produce small run of avt2 board, here is the > top side of avt2 without jz4720 temporarily; > http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/smt/pictures/top.jpg > Will keep you posted later. > Adam > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -- Carlos Iv?n Camargo Bare?o Profesor Asistente Departamento de Ingenier?a El?ctrica y Electr?nica Universidad Nacional de Colombia cicamargoba at unal.edu.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From yi at qi-hardware.com Fri Sep 11 11:03:55 2009 From: yi at qi-hardware.com (Yi Zhang) Date: Fri, 11 Sep 2009 23:03:55 +0800 Subject: FCC test passed Message-ID: <551A4C0B-73AB-4C80-99AA-197B6B505427@qi-hardware.com> All, We have passed FCC tests [1]! The "value above radiation standard" problem has been resolved by replacing BN1 and BN2 components with ferrite bead array ARZ3216-4-601(600ohm), and BD4 with ferrite bead PZ1608D221(220ohm) [2][3][4]. However, our ESD test for CE certification has failed. The problem is on USB connector. It is not grounded, close to the power button, therefore easy to produce static, the lab engineer has told me. The engineers of our vendor are working on the solutions. Thanks, Yi [1] http://downloads.qi-hardware.com/hardware/certification/ 2009_09_11/FCC_Test_Report_20090911.pdf [2] http://downloads.qi-hardware.com/hardware/certification/ 2009_09_11/FCC_test_report_20090911-01.JPG [3] http://downloads.qi-hardware.com/hardware/certification/ 2009_09_11/FCC_test_report_20090911-02.JPG [4] http://downloads.qi-hardware.com/hardware/certification/ 2009_09_11/FCC_test_report_20090911-03.JPG -------------- next part -------------- An HTML attachment was scrubbed... URL: From rakshat at gmail.com Fri Sep 11 11:13:34 2009 From: rakshat at gmail.com (rakshat hooja) Date: Fri, 11 Sep 2009 20:43:34 +0530 Subject: flash player on MIPS In-Reply-To: <20090911011450.GA3717@debian> References: <69a2e4550909100918o55662057nc8a01cc8505423cd@mail.gmail.com> <422808530909100942u32c1a8b1u4d2c33d05a32301f@mail.gmail.com> <20090911011450.GA3717@debian> Message-ID: <69a2e4550909110813h5e7bcd7gf73938dca148f10b@mail.gmail.com> On Fri, Sep 11, 2009 at 6:44 AM, Wolfgang Spraul wrote: > Rakshat, > is xiptech free software? > > I don't know. Their site in in a language I can't read! They do have something about a GNU Tool chain Ok I just got the english version - can't see the source code anywhere :( Rakshat -------------- next part -------------- An HTML attachment was scrubbed... URL: From kzjeef at gmail.com Fri Sep 11 12:24:48 2009 From: kzjeef at gmail.com (ZhangJieJing) Date: Sat, 12 Sep 2009 00:24:48 +0800 Subject: configure mpd/mpc in openwrt. music player in Ben NanoNote In-Reply-To: <9f2feba00909110240s4169fe78mfe38db486e30fc1d@mail.gmail.com> References: <4AA463E5.5090802@qi-hardware.com> <19ebea720909071630t1a680beexf5d62ec2084090ba@mail.gmail.com> <4AA5B590.5000000@qi-hardware.com> <9f2feba00909110240s4169fe78mfe38db486e30fc1d@mail.gmail.com> Message-ID: 2009/9/11 Ignacio Garc?a P?rez > I never got ALSA to work on the A320 (dingux). Instead I tried OSS and as > it worked I forgot about ALSA. The OSS what type OSS, from I know , ALSA have an emulated OSS plugin, or a pure OSS driver? code, though, seems to be deprecated by Ingenic and is very very very ugly > and buggy. Had to make several fixes to get sample rates other than S16_LE > working. However, sticking to OSS because "it just works" is probably only > acceptable in the A320 case because it is intended to be used as a gaming > console and as such almost eveybody is using the SDL, which dingux provides > precompiled and configured for OSS. > > 2009/9/8 ZhangJieJing > > Hi, >> >> Sound card on my kernel tree is just can be found by alsa driver, But the >> driver have problem with DMA(jz's driver use too old DMA method) I 'm trying >> to fix it. >> >> The sound cann't play for now. >> --- >> Best regards, >> Zhang Jiejing >> >> >> >> On Tue, Sep 8, 2009 at 9:38 AM, Xiangfu Liu wrote: >> >>> Carlos Camargo wrote: >>> > Hi >>> > >>> > We are trying to test the sound driver, with alsa, mplayer, but doesn't >>> > work :( The Qi kernel source support the JZ sound driver? If not, >>> where >>> > can I foun information about this driver? >>> >>> the Qi kernel not support JZ sound driver not. Jieijing Zhang and larsc >>> work on that. >>> >>> you can find the Jieijing Zhange sound code: >>> >>> http://projects.qi-hardware.com/index.php/p/kzjeef-kernel/source/changes/master/ >>> >>> you can find JZ 2.6.27 sound driver at: >>> >>> http://downloads.qi-hardware.com/software/sources/linux-2.6.27.git.svn.tgz >>> >>> > >>> > >>> > $ scripts/feeds install mpd >>> > $ scripts/feeds install mpc >>> >>> run 'scripts/feeds update' before install mpd/mpc. >>> >>> > >>> > I try to run this command but I get the following error: >>> > >>> > Ignoring feed 'packages' - index missing >>> > Ignoring feed 'xwrt' - index missing >>> > Ignoring feed 'luci' - index missing >>> > WARNING: No feed for package 'mpd' found, maybe it's already part of >>> the >>> > standard packages? >>> > >>> > >>> > >>> > Carlos >>> > >>> > >>> > >>> > On Sun, Sep 6, 2009 at 8:37 PM, Xiangfu Liu >> > > wrote: >>> > >>> > >>> > 1. in terminal, under openwrt folder run >>> > >>> > >>> > >>> > 2. run [make menuconfig] then select --> sound --> enable [mpc] >>> [mpd] >>> > 3. run [make menuconfig] --> Base System --> enable [libstdcpp] >>> > >>> > then you run make. you will get the [mpd] [mpc] in you rootfs. >>> > you need change the [/etc/mpd.conf] to make the mpd work. >>> > >>> >>> _______________________________________________ >>> Qi Developer Mailing List >>> Mail to list (members only): developer at lists.qi-hardware.com >>> Subscribe or Unsubscribe: >>> http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer >>> >> >> >> _______________________________________________ >> Qi Developer Mailing List >> Mail to list (members only): developer at lists.qi-hardware.com >> Subscribe or Unsubscribe: >> http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer >> > > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjeffries at gmail.com Fri Sep 11 13:43:09 2009 From: rjeffries at gmail.com (Ron K. Jeffries) Date: Fri, 11 Sep 2009 10:43:09 -0700 Subject: Feedback re NanoNote from Santa Barbara Liux Users Group Message-ID: <886128c30909111043m49382c3dk832c3bf70170cbf6@mail.gmail.com> (I apologize for the length of this. Maybe I should have put it on my blog. I am obviously responsible for any errors .). Thursday Sept. 10, 2009 I shared the proto Nanonote (Chinese version) with a dozen members of the Santa Barbara Linux Users Group. Feedback: 1. USB Host capability is required. Period. 2 Bigger battery required. (USB host drives this) >> Aside: a member replaced NN battery with battery from his Nokia 2555 (or was it 3555?) it works! ;) People appreciate NN uses a widely available and inexpensive battery. 3. 2nd micro SD slot would be very useful, one slot is used for memory, the other for add-on gadgets e.g. wifi (until it is built in) or GPS or ? 4. 64 MB RAM will greatly expand what NN can be used for 5. built-in WiFi highly desirable (but see notes below about apps without WiFi) 6. Lots of discussion about possible uses cases. Considerable discussion about how smart phones can be used for same apps (and more). However, in favor of NN is no requirement for service plan. 7. Also discussion of netbook as competing device, since netbook prices are inevitably headed down. (Already under $200 USD for early 9-in ASUS models (clearance) and the MIPS book variants from China. However... NN slips into a pocket or a woman's purse. The smallness makes it unique for some apps. Just as many geeks own a notebook PLUS a netbook, there was discussion that at $99 (prefer lower price) a significant number of geeks would buy NN just to play around. Note WiFi is taken for granted in that scenario. 8. Use case for NN WITHOUT WiFi: 8a Graphing Calculator. A statistics prof from local college said that purpose built graphing calculators cost over $100. NN can be a first class replacement plus do other appps. 8b one member reported that an elementary school REQUIRES kids to purchase (unknown model) of Franklin spelling/dictionary http://www.franklin.com/ that was a shocker to me. I will investigate to get details. 8c Lack of WiFi is an ADVANTAGE for classroom use. wireless can be a way to cheat during a test, etc. 8d Language learning app, with audible pronunciation 8e Language Translation aid 8f Open Street Map as portable atlas. does not require GPS 8g Wikipedia and Wikitravel were considered interesting. "Hitchikers Guide to the Universe" 8h Use of NN in engineering classes, so students can take lab to dorm with totally open hardware 9. Serial port would be very useful. 10. JTAG connection (internal) was suggested by hardware hackers 11. I briefly mentioned adding touchscreen. feedback was mixed. There was concern it would diminish video clarity, that cost might be excessive, and that having two UI methods may be bad idea. Having said that, Palm sold a lot of Treos with keyboard + Touch.;) 12. A negative: the LCD on this proto seemed to show a checkerboard effect. This was shown while looking at built-in English/Chinese dictionary. SUMMARY: a majority of people were very intrigued by Nanonote Stephanie Lockwood-Childs, leader of the SBLUG group, said she hopes NanoNote will be available in time for Christmas. Fortunately, her husband was in the room.;) --- Ron K. Jeffries http://identi.ca/rkj From michaelshiloh1010 at gmail.com Fri Sep 11 14:08:00 2009 From: michaelshiloh1010 at gmail.com (Michael Shiloh) Date: Fri, 11 Sep 2009 11:08:00 -0700 Subject: Feedback re NanoNote from Santa Barbara Liux Users Group In-Reply-To: <886128c30909111043m49382c3dk832c3bf70170cbf6@mail.gmail.com> References: <886128c30909111043m49382c3dk832c3bf70170cbf6@mail.gmail.com> Message-ID: <4AAA9200.4020506@gmail.com> great feedback ron - thanks. one comment: many usb to serial port adapters exist (some with excellent linux support) so is a serial port really needed? sure, nice to have, but given alternate uses for pins, space, resources, i'd give this up first. otherwise i like and agree with everything your group observed. thanks for the excellent writeup and thanks to your group for the excellent analysis michael Ron K. Jeffries wrote: > (I apologize for the length of this. Maybe I should have put it on my blog. > I am obviously responsible for any errors .). > > Thursday Sept. 10, 2009 I shared the proto Nanonote (Chinese version) > with a dozen members of the Santa Barbara Linux Users Group. Feedback: > > 1. USB Host capability is required. Period. > > 2 Bigger battery required. (USB host drives this) >>> Aside: a member replaced NN battery with battery from his Nokia 2555 > (or was it 3555?) it works! ;) People appreciate NN uses a widely available > and inexpensive battery. > > 3. 2nd micro SD slot would be very useful, one slot is used for memory, > the other for add-on gadgets e.g. wifi (until it is built in) or GPS or ? > > 4. 64 MB RAM will greatly expand what NN can be used for > > 5. built-in WiFi highly desirable (but see notes below about apps without WiFi) > > 6. Lots of discussion about possible uses cases. Considerable discussion > about how smart phones can be used for same apps (and more). However, > in favor of NN is no requirement for service plan. > > 7. Also discussion of netbook as competing device, since netbook > prices are inevitably headed down. (Already under $200 USD for > early 9-in ASUS models (clearance) and the MIPS book variants > from China. > > However... NN slips into a pocket or a woman's purse. The smallness > makes it unique for some apps. Just as many geeks own a notebook > PLUS a netbook, there was discussion that at $99 (prefer lower price) > a significant number of geeks would buy NN just to play around. Note > WiFi is taken for granted in that scenario. > > 8. Use case for NN WITHOUT WiFi: > > 8a Graphing Calculator. A statistics prof from local college said that > purpose built graphing calculators cost over $100. NN can be > a first class replacement plus do other appps. > > 8b one member reported that an elementary school REQUIRES > kids to purchase (unknown model) of Franklin spelling/dictionary > http://www.franklin.com/ that was a shocker to me. I will investigate > to get details. > > 8c Lack of WiFi is an ADVANTAGE for classroom use. wireless > can be a way to cheat during a test, etc. > > 8d Language learning app, with audible pronunciation > > 8e Language Translation aid > > 8f Open Street Map as portable atlas. does not require GPS > > 8g Wikipedia and Wikitravel were considered interesting. > "Hitchikers Guide to the Universe" > > 8h Use of NN in engineering classes, so students can take lab to dorm > with totally open hardware > > 9. Serial port would be very useful. > > 10. JTAG connection (internal) was suggested by hardware hackers > > 11. I briefly mentioned adding touchscreen. feedback was mixed. > There was concern it would diminish video clarity, that cost might > be excessive, and that having two UI methods may be bad idea. > Having said that, Palm sold a lot of Treos with keyboard + Touch.;) > > 12. A negative: the LCD on this proto seemed to show > a checkerboard effect. This was shown while looking at built-in > English/Chinese dictionary. > > SUMMARY: a majority of people were very intrigued by Nanonote > > Stephanie Lockwood-Childs, leader of the SBLUG group, > said she hopes NanoNote will be available in time for Christmas. > Fortunately, her husband was in the room.;) > > --- > Ron K. Jeffries > http://identi.ca/rkj > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > From steve at qi-hardware.com Fri Sep 11 15:29:57 2009 From: steve at qi-hardware.com (Steve Mosher) Date: Fri, 11 Sep 2009 12:29:57 -0700 Subject: Feedback re NanoNote from Santa Barbara Liux Users Group In-Reply-To: <886128c30909111043m49382c3dk832c3bf70170cbf6@mail.gmail.com> References: <886128c30909111043m49382c3dk832c3bf70170cbf6@mail.gmail.com> Message-ID: <2b311fa30909111229j6eb019b1qcbbb458fa9d05b12@mail.gmail.com> Thanks Ron. Blogging about this would be great. talk to miro about getting syndicated on our page, like the openwrt guys are On Fri, Sep 11, 2009 at 10:43 AM, Ron K. Jeffries wrote: > (I apologize for the length of this. Maybe I should have put it on my blog. > I am obviously responsible for any errors .). > > Thursday Sept. 10, 2009 I shared the proto Nanonote (Chinese version) > with a dozen members of the Santa Barbara Linux Users Group. Feedback: > > 1. USB Host capability is required. Period. > > 2 Bigger battery required. (USB host drives this) > >> Aside: a member replaced NN battery with battery from his Nokia 2555 > (or was it 3555?) it works! ;) People appreciate NN uses a widely > available > and inexpensive battery. > > 3. 2nd micro SD slot would be very useful, one slot is used for memory, > the other for add-on gadgets e.g. wifi (until it is built in) or GPS or > ? > > 4. 64 MB RAM will greatly expand what NN can be used for > > 5. built-in WiFi highly desirable (but see notes below about apps without > WiFi) > > 6. Lots of discussion about possible uses cases. Considerable discussion > about how smart phones can be used for same apps (and more). However, > in favor of NN is no requirement for service plan. > > 7. Also discussion of netbook as competing device, since netbook > prices are inevitably headed down. (Already under $200 USD for > early 9-in ASUS models (clearance) and the MIPS book variants > from China. > > However... NN slips into a pocket or a woman's purse. The smallness > makes it unique for some apps. Just as many geeks own a notebook > PLUS a netbook, there was discussion that at $99 (prefer lower price) > a significant number of geeks would buy NN just to play around. Note > WiFi is taken for granted in that scenario. > > 8. Use case for NN WITHOUT WiFi: > > 8a Graphing Calculator. A statistics prof from local college said that > purpose built graphing calculators cost over $100. NN can be > a first class replacement plus do other appps. > > 8b one member reported that an elementary school REQUIRES > kids to purchase (unknown model) of Franklin spelling/dictionary > http://www.franklin.com/ that was a shocker to me. I will > investigate > to get details. > > 8c Lack of WiFi is an ADVANTAGE for classroom use. wireless > can be a way to cheat during a test, etc. > > 8d Language learning app, with audible pronunciation > > 8e Language Translation aid > > 8f Open Street Map as portable atlas. does not require GPS > > 8g Wikipedia and Wikitravel were considered interesting. > "Hitchikers Guide to the Universe" > > 8h Use of NN in engineering classes, so students can take lab to dorm > with totally open hardware > > 9. Serial port would be very useful. > > 10. JTAG connection (internal) was suggested by hardware hackers > > 11. I briefly mentioned adding touchscreen. feedback was mixed. > There was concern it would diminish video clarity, that cost might > be excessive, and that having two UI methods may be bad idea. > Having said that, Palm sold a lot of Treos with keyboard + Touch.;) > > 12. A negative: the LCD on this proto seemed to show > a checkerboard effect. This was shown while looking at built-in > English/Chinese dictionary. > > SUMMARY: a majority of people were very intrigued by Nanonote > > Stephanie Lockwood-Childs, leader of the SBLUG group, > said she hopes NanoNote will be available in time for Christmas. > Fortunately, her husband was in the room.;) > > --- > Ron K. Jeffries > http://identi.ca/rkj > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michaelshiloh1010 at gmail.com Fri Sep 11 18:05:35 2009 From: michaelshiloh1010 at gmail.com (Michael Shiloh) Date: Fri, 11 Sep 2009 15:05:35 -0700 Subject: [Fwd: Rare Kit-Form Chumbys Inbound to the Maker Shed] Message-ID: <4AAAC9AF.9040301@michaelshiloh.com> another open source hardware thing. might be good to form an alliance. many of you probably know about chumby - the inventor, bunnie huang, is a good friend of sean's. -------- Original Message -------- Subject: Rare Kit-Form Chumbys Inbound to the Maker Shed Date: Sat, 12 Sep 2009 07:53:46 +1000 From: Dan Woods, Maker Shed Reply-To: custserv at makermedia.com To: michael at michaelshiloh.com MakerSHED Dear Loyal Maker Shed Customer, During the last Maker Faire, we unveiled a truly unique product in the Maker Shed store ? an actual Chumby in kit form. The open?source Chumby is Linux?based with plenty of widgets already coded. Produced and packaged expressly for Maker Shed by Chumby, the kit contained everything you need to build your own Chumby or to hack it into into a form factor of your own choosing, including an accelerometer, 3.5" touchscreen LCD, USB WiFi dongle, 3 USB 2.0 ports, and a powerful motherboard. The price was just $99. We sold out within 3 hours. Through a special arrangement with our good friends at Chumby, we have managed to acquire another small quantity of these rare Chumby Kits. These kits are presently en route from the factory and we expect them to sell out in record time. And so I thought "why not make them available exclusively to our very best and most loyal Maker Shed customers first, before offering them for sale to the public?" Think of it as our way of thanking you for your patronage. This is an exclusive invitation to pre-order your own kit-form Chumby for just $99. To review product details and pre-order, please visit this unpublished Maker Shed link. Again, this is a special offer that we are making first to our very best customers. There is a limit of 3 kits per customer, and when they're gone, they're gone. I'll try to get more, but I cannot guarantee that we'll see these again. All The Best, Dan Dan Woods General Manager, Maker Shed We sent you this e-mail because we thought you'd want to know about this exclusive offer. If you prefer not to receive e-mails like this in the future, you can unsubscribe instantly here. From cicamargoba at gmail.com Fri Sep 11 20:17:17 2009 From: cicamargoba at gmail.com (Carlos Camargo) Date: Fri, 11 Sep 2009 19:17:17 -0500 Subject: [Fwd: Rare Kit-Form Chumbys Inbound to the Maker Shed] In-Reply-To: <4AAAC9AF.9040301@michaelshiloh.com> References: <4AAAC9AF.9040301@michaelshiloh.com> Message-ID: <19ebea720909111717m484e42dfw6f98df1fe64bdae3@mail.gmail.com> Hi I've already had two chumbies, This kit have the same chumby components, without case. We make some products based on cumby, the only available port is the USB host. I remember that one frequent petition on chumb's list was the posiiblitity of buy one chumby without case. I think that Nano can use this idea, for some products, we don't need the keyboard, LCD or case, just the CPU, as use it as device's brain (as Ignacio suggested some days ago), Nano can provide some hardware reference projects for different applications for example one USB dongle with analog ports, or one FPGA with many PWM for robotics, etc Carlos On Fri, Sep 11, 2009 at 5:05 PM, Michael Shiloh wrote: > another open source hardware thing. might be good to form an alliance. > > many of you probably know about chumby - the inventor, bunnie huang, is a > good friend of sean's. > > -------- Original Message -------- > Subject: Rare Kit-Form Chumbys Inbound to the Maker Shed > Date: Sat, 12 Sep 2009 07:53:46 +1000 > From: Dan Woods, Maker Shed > Reply-To: custserv at makermedia.com > To: michael at michaelshiloh.com > > > > MakerSHED > > Dear Loyal Maker Shed Customer, > > During the last Maker Faire, we unveiled a truly unique product in the > Maker Shed store ? an actual Chumby in kit form. The open?source Chumby > is Linux?based with plenty of widgets already coded. Produced and > packaged expressly for Maker Shed by Chumby, the kit contained > everything you need to build your own Chumby or to hack it into into a > form factor of your own choosing, including an accelerometer, 3.5" > touchscreen LCD, USB WiFi dongle, 3 USB 2.0 ports, and a powerful > motherboard. The price was just $99. We sold out within 3 hours. > > Through a special arrangement with our good friends at Chumby, we have > managed to acquire another small quantity of these rare Chumby Kits. > These kits are presently en route from the factory and we expect them to > sell out in record time. And so I thought "why not make them available > exclusively to our very best and most loyal Maker Shed customers first, > before offering them for sale to the public?" Think of it as our way of > thanking you for your patronage. > > This is an exclusive invitation to pre-order your own kit-form Chumby > for just $99. To review product details and pre-order, please visit this > unpublished Maker Shed link. > > > Again, this is a special offer that we are making first to our very best > customers. There is a limit of 3 kits per customer, and when they're > gone, they're gone. I'll try to get more, but I cannot guarantee that > we'll see these again. > > All The Best, > > Dan > > Dan Woods > General Manager, Maker Shed > > > > We sent you this e-mail because we thought you'd want to know about this > exclusive offer. If you prefer not to receive e-mails like this in the > future, you can unsubscribe instantly here. > > > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer -- Carlos Iv?n Camargo Bare?o Profesor Asistente Departamento de Ingenier?a El?ctrica y Electr?nica Universidad Nacional de Colombia cicamargoba at unal.edu.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiangfu.z at gmail.com Sat Sep 12 10:08:16 2009 From: xiangfu.z at gmail.com (xiangfu liu) Date: Sat, 12 Sep 2009 22:08:16 +0800 Subject: why there is no KEY_ALTGR in input.h In-Reply-To: References: Message-ID: hi list why there is no KEY_ALTGR in input.h ? http://www.qi-hardware.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From kzjeef at gmail.com Sat Sep 12 10:39:39 2009 From: kzjeef at gmail.com (ZhangJieJing) Date: Sat, 12 Sep 2009 22:39:39 +0800 Subject: why there is no KEY_ALTGR in input.h In-Reply-To: References: Message-ID: What is KEY_ALTGR ? Do you mean KEY_ALTER? --- Best regards, Zhang Jiejing On Sat, Sep 12, 2009 at 10:08 PM, xiangfu liu wrote: > hi list > why there is no KEY_ALTGR in input.h ? > > http://www.qi-hardware.com > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiangfu at qi-hardware.com Sat Sep 12 11:29:25 2009 From: xiangfu at qi-hardware.com (Xiangfu Liu) Date: Sat, 12 Sep 2009 23:29:25 +0800 Subject: why there is no KEY_ALTGR in input.h In-Reply-To: References: Message-ID: <4AABBE55.8020500@qi-hardware.com> ZhangJieJing wrote: > What is KEY_ALTGR ? > Do you mean KEY_ALTER? http://en.wikipedia.org/wiki/Altgr > --- > Best regards, > Zhang Jiejing > > > On Sat, Sep 12, 2009 at 10:08 PM, xiangfu liu > wrote: > > hi list > why there is no KEY_ALTGR in input.h ? > > http://www.qi-hardware.com > > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer From kzjeef at gmail.com Sat Sep 12 11:43:22 2009 From: kzjeef at gmail.com (ZhangJieJing) Date: Sat, 12 Sep 2009 23:43:22 +0800 Subject: why there is no KEY_ALTGR in input.h In-Reply-To: References: Message-ID: Hi, I think these two is what you want? #define KEY_LEFTALT 56 #define KEY_RIGHTALT 100 left alt , and right alt key. --- Best regards, Zhang Jiejing On Sat, Sep 12, 2009 at 10:08 PM, xiangfu liu wrote: > hi list > why there is no KEY_ALTGR in input.h ? > > http://www.qi-hardware.com > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cicamargoba at gmail.com Sat Sep 12 12:17:53 2009 From: cicamargoba at gmail.com (Carlos Camargo) Date: Sat, 12 Sep 2009 11:17:53 -0500 Subject: USB serial console In-Reply-To: <9f2feba00909110227q154b2eb6yaa298b144e9dba20@mail.gmail.com> References: <19ebea720909101226n21fb6c71j64996a76a87e7dc1@mail.gmail.com> <9f2feba00909110227q154b2eb6yaa298b144e9dba20@mail.gmail.com> Message-ID: <19ebea720909120917x6ee68bb6p794b9fabd5faa802@mail.gmail.com> Thanks a lot Ignacio Saludos Carlos On Fri, Sep 11, 2009 at 4:27 AM, Ignacio Garc?a P?rez wrote: > Earlier releases of Dingux had a g_serial console too, but it had some > inconveniences, for example file transfer is possible but a pain in the ass. > > So I moved to ethernet gadget. The interface is set as 10.1.0.2/30 and a > DHCP server is configured to provide only one lease which is always > 10.1.0.1/30. Inetd is also launched and telnet/ftp services are provided > through it. When the system boots, the PC soon sees a new ethernet card > which is autoconfigured v?a the DHCP server. Then you can access the console > v?a telnet and transfer files v?a FTP. > > If you consider this approach, some remarks about the 2.6.24.3 Ingenic > kernel: > > 1- You must modify the code to enable CDC mode in your code > (drivers/usb/gadget/ether.c). > 2- The code needs an small fix so Windows will recognize the ethernet card > (see file above in the dingux kernel source). > 3- Something is badly broken either in the Ingenic USB device or DMA code. > The ethernet gadget only works reliably if you disable DMA (put > jz4740_udc.use_dma=0 in the kernel command line). This halves throughput but > works. > > I believe the DMA problem is not specific to the ethernet gadget code. I > mean it should be present also when using the g_serial gadget. However, only > shows up when using the full bandwidth, which rarely happens on a serial > console. > > Regards. > > 2009/9/10 Carlos Camargo > >> HI >> >> I'm working with my custom JZ4725 board, I'm using linux 2.6.24.3 with >> g_serial driver. I can run one console on /dev/ttygserial, so, we don't need >> any USB/serial cable right now. >> >> I can't find the application getty on openwrt, I've already used mgetty, >> but it doesn't work. I try with an openembedded distro, this distro provide >> getty so, I can use it to enable the USB serial console. >> >> Is possible add getty to openwrt? >> >> >> Best Regards >> >> Carlos >> >> >> -- >> Carlos Iv?n Camargo Bare?o >> Profesor Asistente >> Departamento de Ingenier?a El?ctrica y Electr?nica >> Universidad Nacional de Colombia >> cicamargoba at unal.edu.co >> >> _______________________________________________ >> Qi Developer Mailing List >> Mail to list (members only): developer at lists.qi-hardware.com >> Subscribe or Unsubscribe: >> http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer >> > > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -- Carlos Iv?n Camargo Bare?o Profesor Asistente Departamento de Ingenier?a El?ctrica y Electr?nica Universidad Nacional de Colombia cicamargoba at unal.edu.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From cicamargoba at gmail.com Sat Sep 12 13:35:27 2009 From: cicamargoba at gmail.com (Carlos Camargo) Date: Sat, 12 Sep 2009 12:35:27 -0500 Subject: Nano hardware-developers kit Message-ID: <19ebea720909121035o7864f582n8c03342ec70bf0f1@mail.gmail.com> Hi All We are talking with Wolfgang about additional Nano's feature, As some people said, Nano would be useful as brain in a custom electronic device. We (emQbit) are thinking in build a power quality measurement device based on Nano. Maybe some people in this list thinking similarly. Because of that Wolfgang has an idea: Build a developer board, or a commercial board for companies like us, with additional resources like JTAG, 232 level shifter, SPI, I2C ports, additional AVR for make mano Arduino-compatible, an FPGA for robotic applications, etc. The first approach for this (Wolfgang idea), is make only one board, the commercial Nano would be a sub-set of this board, so, we have only one pcb and we can build both cards from the same design. Wolfgang think use the same case for both versions. Is necessary, define some topics: 1. Switch the hardware design to Kicad. 2. What kind of interfaces will support the developer platform (I2C, JTAG, SPI, FPGA, AVR microcontroller, etc)? 3. How this additional hardware will be connected with the JZ4720, Data, address, control bus lines, SPI, I2C, USB host? I'm starting the discussion showing some advantages of the different possibilities: 1. Using Address, Data and Control processor's Bus signals [1]: If you have access to this signals, you can connect any peripheral to Nano, and you can map the FPGA logic as a simple RAM memory [2]. But there are many signals: Data (8-16) + Control (4), Address (13 ?) = 33. 2. SPI port [3]. The main advantage is that this protocol use only 4 wires, but we need one (CS) for each peripheral. 3. I2C [4] This protocol use two wires only, but is slow. 4. FPGA. For use one FPGA we need the signals in 1. and some GPIOs for configuration process (TDI, TDO, TMS, TCK). Unless that the FPGA implement a I2C or SPI device. 5. AVR. The Atmega8 family [5] provide a wide range of peripherals like ADCs, SPI, I2C, ports, Timers, and allow the ISP [6], so we can use an external Atmega through SPI or I2C processor ports, and we can programming it with 4 GPIOs. Please comment on this and add additional features do you like, Best Regards Carlos [1] http://downloads.qi-hardware.com/hardware/hacking/computer-simple.png [2] http://downloads.qi-hardware.com/hardware/hacking/sw_hw_fpga_arch.png [3] http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus [4] http://en.wikipedia.org/wiki/I%C2%B2C [5] http://www.atmel.com/dyn/products/devices.asp?family_id=607 [6] http://en.wikipedia.org/wiki/In-System_Programming -- Carlos Iv?n Camargo Bare?o Profesor Asistente Departamento de Ingenier?a El?ctrica y Electr?nica Universidad Nacional de Colombia cicamargoba at unal.edu.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From sjl at ross154.net Sat Sep 12 16:36:17 2009 From: sjl at ross154.net (sjl at ross154.net) Date: Sat, 12 Sep 2009 13:36:17 -0700 Subject: Suggestion: NanoNote Personalities Program Message-ID: <20090912203617.GE10957@ross154.net> NanoNote Personalities Program[1] You know the changable cellphone cover fad, where they snapped on different colorful plastic covers? The NanoNote should offer different "spins" offering different types of functionality, aka "personalities". Example personalities: * graphing calculator * electronic spelling dictionary / translator * travel buddy (wikitravel / openstreetmap) * puzzle games * beginner programming languages (python, pascal, etc) * PDA * Gutenberg ebooks reader Every personality would be available both as a downloadable image and preinstalled on SD cards sold as NN accessories. Every SD card would have a custom sticker to show at a glance which personality is installed on it. There would be a little case or slipcover for the NN that would include a little compartment for an SD collection. Company responsibilities: * Pay an artist to work with personality development teams on a a splashscreen + tiny SD sticker art for each team * Pay good tech writers to develop user guides for each personality; bonus points for paying tech writers to help out on developer docs!! * Provide hosting for personality development teams, but also support mirroring of install images for teams that want to use their own server * Hire knowledgable and good-tempered customer support engineers willing to shield developers from grumpy customers and customers from grumpy developers * Handle retail of the pre-installed SDs, including the custom stickers for branding (also offer stickers separately for those who want to download images to already-owned SD) * Offer to donate some portion of pre-installed SD / sticker profit to project designated by leaders of corresponding dev team Developer team responsibilities: Most of the personalities would use the openwrt base, but some of the ones intended for hacking might slap the NN kernel into another embedded distro, e.g. a gentoo embedded experiment (gentoo has mips support). * Work with artist to come up with custom splashscreen and SD sticker art * Make sure the official splashscreen for the personality gets displayed at boot * Answer questions from tech writer regarding user guide [1] "program" in the sense of "something you can participate in", not in the sense of "code a computer executes" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From wolfgang at qi-hardware.com Sun Sep 13 00:57:30 2009 From: wolfgang at qi-hardware.com (Wolfgang Spraul) Date: Sun, 13 Sep 2009 00:57:30 -0400 Subject: Feedback re NanoNote from Santa Barbara Liux Users Group In-Reply-To: <886128c30909111043m49382c3dk832c3bf70170cbf6@mail.gmail.com> References: <886128c30909111043m49382c3dk832c3bf70170cbf6@mail.gmail.com> Message-ID: <20090913045730.GA2081@debian> Ron, great list, thanks a lot! I just pick out two right now... > 10. JTAG connection (internal) was suggested by hardware hackers Carlos (who is a hardware hacker) seems to think JTAG is not necessary as it is typically mostly used to reflash devices and in our case that capability is coming from the BOOT ROM in the CPU. On the other hand I just sent a 4740 EVB to Lars because he needed JTAG to track down a particular bug and couldn't do it with the NanoNote board. So if you ever run into someone again who wants JTAG, ask them why, or ask to write on this list so we better understand their needs. > 12. A negative: the LCD on this proto seemed to show > a checkerboard effect. This was shown while looking at built-in > English/Chinese dictionary. Some LCM bugs were fixed recently, but maybe what you mean is the pixels not being 'in line'? I noticed that too, and first thought something is wrong. But then I was told this is a new type of TFT, often found in digital cameras and other devices that typically display pictures, images, movies. I guess the checkerboard effect (if we mean the same thing) makes pictures look better? For pixel fonts, for sure it means that ideally the pixel fonts should be specially crafted for these types of LCM. Same for the freetype outline rendering, etc. There are several ways to go with this: We can accept it and use it to our advantage, or we try to replace the LCM with a 'classical' type in the Ya NanoNote. For the Ben we will definitely use the LCM (from Giantplus) we have in our latest samples (there also was a change, not sure which prototype/sample you have). It would be helpful if we could find some TFT expert who could tell us the whole story about this checkerboard 'innovation' :-) Wolfgang On Fri, Sep 11, 2009 at 10:43:09AM -0700, Ron K. Jeffries wrote: > (I apologize for the length of this. Maybe I should have put it on my blog. > I am obviously responsible for any errors .). > > Thursday Sept. 10, 2009 I shared the proto Nanonote (Chinese version) > with a dozen members of the Santa Barbara Linux Users Group. Feedback: > > 1. USB Host capability is required. Period. > > 2 Bigger battery required. (USB host drives this) > >> Aside: a member replaced NN battery with battery from his Nokia 2555 > (or was it 3555?) it works! ;) People appreciate NN uses a widely available > and inexpensive battery. > > 3. 2nd micro SD slot would be very useful, one slot is used for memory, > the other for add-on gadgets e.g. wifi (until it is built in) or GPS or ? > > 4. 64 MB RAM will greatly expand what NN can be used for > > 5. built-in WiFi highly desirable (but see notes below about apps without WiFi) > > 6. Lots of discussion about possible uses cases. Considerable discussion > about how smart phones can be used for same apps (and more). However, > in favor of NN is no requirement for service plan. > > 7. Also discussion of netbook as competing device, since netbook > prices are inevitably headed down. (Already under $200 USD for > early 9-in ASUS models (clearance) and the MIPS book variants > from China. > > However... NN slips into a pocket or a woman's purse. The smallness > makes it unique for some apps. Just as many geeks own a notebook > PLUS a netbook, there was discussion that at $99 (prefer lower price) > a significant number of geeks would buy NN just to play around. Note > WiFi is taken for granted in that scenario. > > 8. Use case for NN WITHOUT WiFi: > > 8a Graphing Calculator. A statistics prof from local college said that > purpose built graphing calculators cost over $100. NN can be > a first class replacement plus do other appps. > > 8b one member reported that an elementary school REQUIRES > kids to purchase (unknown model) of Franklin spelling/dictionary > http://www.franklin.com/ that was a shocker to me. I will investigate > to get details. > > 8c Lack of WiFi is an ADVANTAGE for classroom use. wireless > can be a way to cheat during a test, etc. > > 8d Language learning app, with audible pronunciation > > 8e Language Translation aid > > 8f Open Street Map as portable atlas. does not require GPS > > 8g Wikipedia and Wikitravel were considered interesting. > "Hitchikers Guide to the Universe" > > 8h Use of NN in engineering classes, so students can take lab to dorm > with totally open hardware > > 9. Serial port would be very useful. > > 10. JTAG connection (internal) was suggested by hardware hackers > > 11. I briefly mentioned adding touchscreen. feedback was mixed. > There was concern it would diminish video clarity, that cost might > be excessive, and that having two UI methods may be bad idea. > Having said that, Palm sold a lot of Treos with keyboard + Touch.;) > > 12. A negative: the LCD on this proto seemed to show > a checkerboard effect. This was shown while looking at built-in > English/Chinese dictionary. > > SUMMARY: a majority of people were very intrigued by Nanonote > > Stephanie Lockwood-Childs, leader of the SBLUG group, > said she hopes NanoNote will be available in time for Christmas. > Fortunately, her husband was in the room.;) > > --- > Ron K. Jeffries > http://identi.ca/rkj > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer From wijnen at debian.org Sun Sep 13 03:36:42 2009 From: wijnen at debian.org (Bas Wijnen) Date: Sun, 13 Sep 2009 09:36:42 +0200 Subject: Ben NanoNote booting Message-ID: <20090913073641.GB8185@a82-93-13-222.adsl.xs4all.nl> Hi, Last week, I received my Ben prototype (thanks Mirko!). Now I want to make it boot Iris. Preferably I don't want to install it on an SD card. That should be possible, right? Under the battery are two pads which say that the device uses "usb boot" when they are closed. I'll probably solder them closed. However, my first attempt to close them with a screwdriver while powering up didn't make anything special happen. Also, my system logs don't show anything about new devices being plugged in. The wiki says something about a "usbboot" utility which is part of the openwrt tree(?) I'll probably be adjusting it so it will boot Iris instead of Linux. Summarizing, what I would prefer is the easiest possible way to boot a new system from my main computer on the Ben. Best would be if it can be triggered by a command on the main computer. Also good would be to power-cycle the Ben. Not so good would be if the cable needs to be replugged. Still worse would be to write every image to an SD card before it can be booted. I have no problem at all if the USB cable needs to be connected continuously. Eventually that isn't good of course, but now I'm only developing. Thanks, Bas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From adam at qi-hardware.com Sun Sep 13 04:52:59 2009 From: adam at qi-hardware.com (Adam Wang) Date: Sun, 13 Sep 2009 16:52:59 +0800 Subject: qi_avt2 v1.0 board status In-Reply-To: <4AAA0C6A.5050409@qi-hardware.com> References: <4AAA0C6A.5050409@qi-hardware.com> Message-ID: <4AACB2EB.7030601@qi-hardware.com> Hi All, The picture of avt2_v1.0 board with die is here[1]. And it just works and shown up[2]. I'll keep do more basic IO tests. Adam [1] http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/smt/pictures/top_jz4720.jpg [2] http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/report/photos/avt2_v1.0_works.JPG Adam Wang wrote: > Hi All, > > We're now on the process to produce small run of avt2 board, here is > the top side of avt2 without jz4720 temporarily; > http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/smt/pictures/top.jpg > > Will keep you posted later. > Adam From kzjeef at gmail.com Sun Sep 13 06:45:04 2009 From: kzjeef at gmail.com (ZhangJieJing) Date: Sun, 13 Sep 2009 18:45:04 +0800 Subject: About i2s BIT_CLK and SYNCD of NanoBen Message-ID: Hi all, I 'm checking the initializing instruction of jz4740 sound driver of NanoBen, I found I2S register AICFR.BCKD(jz4740 program manual 13.2.1) and AICFR.SYNCD are set to 0 in jz4740 i2s driver. these two bit's function are: BCKD : BIT_CLK Direction. This bit specifies input/output direction of BIT_CLK. 0 = BIT_CLK is input from an external source. 1 = BIT_CLK is generated internally and driven out to the CODEC. SYNCD: SYNC Direction. This bit specifies input/output direction of SYNC in I2S/MSB-justified format. 0 = SYNC is input from an external source. 1 = SYNC is generated internally and driven out to the CODEC. My question is : what direction the BIT_CLK and SYNC of ben was ? I just want to ensure the is that right. Since I have no *oscillograph*, so I cann't sure the CODEC and I2S works fine or not, so I just check the init instruction of programming manual. thanks. --- Best regards, Zhang Jiejing -------------- next part -------------- An HTML attachment was scrubbed... URL: From kzjeef at gmail.com Sun Sep 13 07:03:40 2009 From: kzjeef at gmail.com (ZhangJieJing) Date: Sun, 13 Sep 2009 19:03:40 +0800 Subject: About i2s BIT_CLK and SYNCD of NanoBen In-Reply-To: References: Message-ID: I found some collision in jz4740 programming manual. programming manual 13.2.1 said about BCKD is 1 = BIT_CLK is generated internally and driven out to the CODEC. but 13.4.1 said Initialization 3: "" If internal CODEC is used, select 12MHz clock input (via set proper value in CFCR.I2S and I2SCDR), I2S format (I2SCR.AMSL=0), input BIT_CLK (AICFR.BCKD=0), input SYNC (AICFR.SYNCD=0)."" here BCKD = 0 is internally codec, but 13.2.1 said BCKD = 1 is internal code. I'm confused. maybe Ingenic engineer can explain that. --- Best regards, Zhang Jiejing On Sun, Sep 13, 2009 at 6:45 PM, ZhangJieJing wrote: > Hi all, > > I 'm checking the initializing instruction of jz4740 sound driver of > NanoBen, I found I2S register AICFR.BCKD(jz4740 program manual 13.2.1) and > AICFR.SYNCD are set to 0 in jz4740 i2s driver. > > these two bit's function are: > BCKD : BIT_CLK Direction. This bit specifies input/output direction of > BIT_CLK. > 0 = BIT_CLK is input from an external source. > 1 = BIT_CLK is generated internally and driven out to the CODEC. > > SYNCD: SYNC Direction. This bit specifies input/output direction of SYNC in > I2S/MSB-justified format. > 0 = SYNC is input from an external source. > 1 = SYNC is generated internally and driven out to the CODEC. > > My question is : > > what direction the BIT_CLK and SYNC of ben was ? I just want to ensure the > is that right. > > Since I have no *oscillograph*, so I cann't sure the CODEC and I2S works > fine or not, so I just check the init instruction of programming manual. > > thanks. > > --- > Best regards, > Zhang Jiejing > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cicamargoba at gmail.com Sun Sep 13 08:42:52 2009 From: cicamargoba at gmail.com (Carlos Camargo) Date: Sun, 13 Sep 2009 07:42:52 -0500 Subject: Ben NanoNote booting In-Reply-To: <20090913073641.GB8185@a82-93-13-222.adsl.xs4all.nl> References: <20090913073641.GB8185@a82-93-13-222.adsl.xs4all.nl> Message-ID: <19ebea720909130542m152b1b9l49c00b17559d52e0@mail.gmail.com> hi adam, good job. i want one new board :). when finish all tests, please check the kicad brd file. we want that the next board will be designed in kicad. we've already uploaded pcb and footprints files, all components placed, and remove a lot of test points Carlos On 9/13/09, Bas Wijnen wrote: > Hi, > > Last week, I received my Ben prototype (thanks Mirko!). Now I want to > make it boot Iris. Preferably I don't want to install it on an SD card. > That should be possible, right? Under the battery are two pads which > say that the device uses "usb boot" when they are closed. I'll probably > solder them closed. However, my first attempt to close them with a > screwdriver while powering up didn't make anything special happen. > Also, my system logs don't show anything about new devices being plugged > in. > > The wiki says something about a "usbboot" utility which is part of the > openwrt tree(?) I'll probably be adjusting it so it will boot Iris > instead of Linux. > > Summarizing, what I would prefer is the easiest possible way to boot a > new system from my main computer on the Ben. Best would be if it can be > triggered by a command on the main computer. Also good would be to > power-cycle the Ben. Not so good would be if the cable needs to be > replugged. Still worse would be to write every image to an SD card > before it can be booted. > > I have no problem at all if the USB cable needs to be connected > continuously. Eventually that isn't good of course, but now I'm only > developing. > > Thanks, > Bas > -- Carlos Iv?n Camargo Bare?o Profesor Asistente Departamento de Ingenier?a El?ctrica y Electr?nica Universidad Nacional de Colombia cicamargoba at unal.edu.co From uwe at hermann-uwe.de Sun Sep 13 09:09:41 2009 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sun, 13 Sep 2009 15:09:41 +0200 Subject: Ben NanoNote booting In-Reply-To: <20090913073641.GB8185@a82-93-13-222.adsl.xs4all.nl> References: <20090913073641.GB8185@a82-93-13-222.adsl.xs4all.nl> Message-ID: <20090913130941.GC22053@greenwood> Hi, On Sun, Sep 13, 2009 at 09:36:42AM +0200, Bas Wijnen wrote: > Last week, I received my Ben prototype (thanks Mirko!). Now I want to Same here, thanks! :) > make it boot Iris. Preferably I don't want to install it on an SD card. > That should be possible, right? Yes, you can put it on the NAND flash. > Under the battery are two pads which > say that the device uses "usb boot" when they are closed. I'll probably > solder them closed. You shouldn't (permanently) do that, you'll want to sometimes "boot" from USB (which is an incorrect term actually, it only allows you to reflash the NAND via this mechanism, I don't think you can actually boot and OS that way). > However, my first attempt to close them with a > screwdriver while powering up didn't make anything special happen. Do this on your PC/laptop as root: $ watch lsusb Then shorten the two "usbboot" pins with the screwdriver and attach the USB cable to power the device (hold the screwdriver there for 2-3 seconds). If it worked a new USB device 601a:4740 will appear on your PC side. Instead of plugging the USB cable you can also shorten "usbboot" and (while keeping it shorted with the screwdriver) press the reset button (on the back side of the device). > Also, my system logs don't show anything about new devices being plugged > in. If there's no 601a:4740 in lsusb it didn't work. Just retry. I have the same problems, you often have to try multiple times until you get a successful "boot". Not sure if this is a problem with me shorting the pins reliably or some software instability or whatever. > The wiki says something about a "usbboot" utility which is part of the > openwrt tree(?) I'll probably be adjusting it so it will boot Iris > instead of Linux. usbboot is a Linux command line utility which allows you to flash the NAND of the NanoNote via USB. It's not in the openwrt repo, it has it's own repository. http://projects.qi-hardware.com/index.php/p/xburst-tools/ http://downloads.qi-hardware.com/software/xburst-tools/ > Summarizing, what I would prefer is the easiest possible way to boot a > new system from my main computer on the Ben. Best would be if it can be > triggered by a command on the main computer. Also good would be to > power-cycle the Ben. Not so good would be if the cable needs to be > replugged. Still worse would be to write every image to an SD card > before it can be booted. > > I have no problem at all if the USB cable needs to be connected > continuously. Eventually that isn't good of course, but now I'm only > developing. Hm, not sure if this can be achieved, maybe other can comment. For reflashing you definately need to short "usbboot" and afterwards reset the device (with "usbboot" not shorted) to actually run the image you flashed. You might also want to setup your serial console, for debugging output, I'll document that process some more in the wiki, for now here's a quick basic HOWTO: http://wiki.qi-hardware.com/index.php/Serial_console The wiki doesn't yet allow uploads so I put some photos here for now: http://randomprojects.org/wiki/Qi_Hardware_Ben_NanoNote Hope that helps, Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org From cicamargoba at gmail.com Sun Sep 13 09:30:47 2009 From: cicamargoba at gmail.com (Carlos Camargo) Date: Sun, 13 Sep 2009 08:30:47 -0500 Subject: qi_avt2 v1.0 board status In-Reply-To: <4AACB2EB.7030601@qi-hardware.com> References: <4AAA0C6A.5050409@qi-hardware.com> <4AACB2EB.7030601@qi-hardware.com> Message-ID: <19ebea720909130630u154dad1w6d206965830aa342@mail.gmail.com> hi adam, good job. i want one new board :). when finish all tests, please check the kicad brd file. we want that the next board will be designed in kicad. We've already uploaded pcb and footprints files, all components placed, and remove a lot of test-points Can you please check if the placement and size are right ? Best Regards Carlos On Sun, Sep 13, 2009 at 3:52 AM, Adam Wang wrote: > Hi All, > > The picture of avt2_v1.0 board with die is here[1]. > And it just works and shown up[2]. > I'll keep do more basic IO tests. > Adam > > [1] > http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/smt/pictures/top_jz4720.jpg > [2] > http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/report/photos/avt2_v1.0_works.JPG > > > Adam Wang wrote: > >> Hi All, >> >> We're now on the process to produce small run of avt2 board, here is the >> top side of avt2 without jz4720 temporarily; >> >> http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/smt/pictures/top.jpg >> Will keep you posted later. >> Adam >> > > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -- Carlos Iv?n Camargo Bare?o Profesor Asistente Departamento de Ingenier?a El?ctrica y Electr?nica Universidad Nacional de Colombia cicamargoba at unal.edu.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From cicamargoba at gmail.com Sun Sep 13 09:47:26 2009 From: cicamargoba at gmail.com (Carlos Camargo) Date: Sun, 13 Sep 2009 08:47:26 -0500 Subject: Ben NanoNote booting In-Reply-To: <20090913073641.GB8185@a82-93-13-222.adsl.xs4all.nl> References: <20090913073641.GB8185@a82-93-13-222.adsl.xs4all.nl> Message-ID: <19ebea720909130647m3266f3a2o560c38da080dc99e@mail.gmail.com> Hi This links can help you: http://wiki.qi-hardware.com/index.php/Ben_source_code http://wiki.qi-hardware.com/index.php/How_to_reflash? Carlos -- Carlos Iv?n Camargo Bare?o Profesor Asistente Departamento de Ingenier?a El?ctrica y Electr?nica Universidad Nacional de Colombia cicamargoba at unal.edu.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From cicamargoba at gmail.com Sun Sep 13 09:48:37 2009 From: cicamargoba at gmail.com (Carlos Camargo) Date: Sun, 13 Sep 2009 08:48:37 -0500 Subject: qi_avt2 v1.0 board status In-Reply-To: <19ebea720909130630u154dad1w6d206965830aa342@mail.gmail.com> References: <4AAA0C6A.5050409@qi-hardware.com> <4AACB2EB.7030601@qi-hardware.com> <19ebea720909130630u154dad1w6d206965830aa342@mail.gmail.com> Message-ID: <19ebea720909130648xf701545v2920050efd67a4f0@mail.gmail.com> Hi Adam Can you please upload a processor close-up photo? Best Regards Carlos On Sun, Sep 13, 2009 at 8:30 AM, Carlos Camargo wrote: > hi adam, good job. i want one new board :). > when finish all tests, please check the kicad brd file. we want that > the next board will be designed in kicad. > We've already uploaded pcb and footprints files, all components placed, and > remove a lot of test-points > > Can you please check if the placement and size are right ? > > Best Regards > > > Carlos > > > On Sun, Sep 13, 2009 at 3:52 AM, Adam Wang wrote: > >> Hi All, >> >> The picture of avt2_v1.0 board with die is here[1]. >> And it just works and shown up[2]. >> I'll keep do more basic IO tests. >> Adam >> >> [1] >> http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/smt/pictures/top_jz4720.jpg >> [2] >> http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/report/photos/avt2_v1.0_works.JPG >> >> >> Adam Wang wrote: >> >>> Hi All, >>> >>> We're now on the process to produce small run of avt2 board, here is the >>> top side of avt2 without jz4720 temporarily; >>> >>> http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/smt/pictures/top.jpg >>> Will keep you posted later. >>> Adam >>> >> >> >> _______________________________________________ >> Qi Developer Mailing List >> Mail to list (members only): developer at lists.qi-hardware.com >> Subscribe or Unsubscribe: >> http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer >> > > > > -- > Carlos Iv?n Camargo Bare?o > Profesor Asistente > Departamento de Ingenier?a El?ctrica y Electr?nica > Universidad Nacional de Colombia > cicamargoba at unal.edu.co > -- Carlos Iv?n Camargo Bare?o Profesor Asistente Departamento de Ingenier?a El?ctrica y Electr?nica Universidad Nacional de Colombia cicamargoba at unal.edu.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjeffries at gmail.com Sun Sep 13 10:23:44 2009 From: rjeffries at gmail.com (Ron K. Jeffries) Date: Sun, 13 Sep 2009 07:23:44 -0700 Subject: Ben NanoNote booting In-Reply-To: <19ebea720909130647m3266f3a2o560c38da080dc99e@mail.gmail.com> References: <20090913073641.GB8185@a82-93-13-222.adsl.xs4all.nl> <19ebea720909130647m3266f3a2o560c38da080dc99e@mail.gmail.com> Message-ID: <886128c30909130723s5b02ca61xf0f8ca39014317c2@mail.gmail.com> I am (obviously) not a hard-core developer. But... would someone suggest which FTDI cable to purchase? I've looked at http://mouser.com; TMI ;) --- Ron K. Jeffries http://blog.eronj.com 2009/9/13 Carlos Camargo : > > > Hi > > This links can help you: > > ?http://wiki.qi-hardware.com/index.php/Ben_source_code > ?http://wiki.qi-hardware.com/index.php/How_to_reflash? > > > Carlos > > > > -- > Carlos Iv?n Camargo Bare?o > Profesor Asistente > Departamento de Ingenier?a El?ctrica y Electr?nica > Universidad Nacional de Colombia > cicamargoba at unal.edu.co > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > From adam at qi-hardware.com Sun Sep 13 11:20:09 2009 From: adam at qi-hardware.com (Adam Wang) Date: Sun, 13 Sep 2009 23:20:09 +0800 Subject: qi_avt2 v1.0 board status In-Reply-To: <19ebea720909130630u154dad1w6d206965830aa342@mail.gmail.com> References: <4AAA0C6A.5050409@qi-hardware.com> <4AACB2EB.7030601@qi-hardware.com> <19ebea720909130630u154dad1w6d206965830aa342@mail.gmail.com> Message-ID: <4AAD0DA9.1000003@qi-hardware.com> Hi Carlos, Carlos Camargo wrote: > hi adam, good job. i want one new board :). I'll tell list that test results after verification. > when finish all tests, please check the kicad brd file. we want that > the next board will be designed in kicad. Yeah, next board should be used in kicad. :-) > We've already uploaded pcb and footprints files, all components > placed, and remove a lot of test-points > > Can you please check if the placement and size are right ? > Next week the procesess will be kept cob and manual soldering for safe reason, i want test boards before gluing; so will spend time to check all size after maybe next week later. sorry for this. Adam > Best Regards > > > Carlos > > On Sun, Sep 13, 2009 at 3:52 AM, Adam Wang > wrote: > > Hi All, > > The picture of avt2_v1.0 board with die is here[1]. > And it just works and shown up[2]. > I'll keep do more basic IO tests. > Adam > > [1] > http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/smt/pictures/top_jz4720.jpg > [2] > http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/report/photos/avt2_v1.0_works.JPG > > > > Adam Wang wrote: > > Hi All, > > We're now on the process to produce small run of avt2 board, > here is the top side of avt2 without jz4720 temporarily; > http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/smt/pictures/top.jpg > > Will keep you posted later. > Adam > > > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > > > > -- > Carlos Iv?n Camargo Bare?o > Profesor Asistente > Departamento de Ingenier?a El?ctrica y Electr?nica > Universidad Nacional de Colombia > cicamargoba at unal.edu.co > ------------------------------------------------------------------------ > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer -------------- next part -------------- An HTML attachment was scrubbed... URL: From cicamargoba at gmail.com Sun Sep 13 13:17:13 2009 From: cicamargoba at gmail.com (Carlos Camargo) Date: Sun, 13 Sep 2009 12:17:13 -0500 Subject: qi_avt2 v1.0 board status In-Reply-To: <4AAD0DA9.1000003@qi-hardware.com> References: <4AAA0C6A.5050409@qi-hardware.com> <4AACB2EB.7030601@qi-hardware.com> <19ebea720909130630u154dad1w6d206965830aa342@mail.gmail.com> <4AAD0DA9.1000003@qi-hardware.com> Message-ID: <19ebea720909131017t4427e960j888fdb74322c825e@mail.gmail.com> Hi Adam Next week the procesess will be kept cob and manual soldering for safe > reason, i want test boards before gluing; > so will spend time to check all size after maybe next week later. sorry for > this. > Adam > No problem, I understand :) Can you tell me if the last file uploaded [1] corresponds with the PCB under test? Best Regards Carlos -- Carlos Iv?n Camargo Bare?o Profesor Asistente Departamento de Ingenier?a El?ctrica y Electr?nica Universidad Nacional de Colombia cicamargoba at unal.edu.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From cicamargoba at gmail.com Sun Sep 13 13:18:19 2009 From: cicamargoba at gmail.com (Carlos Camargo) Date: Sun, 13 Sep 2009 12:18:19 -0500 Subject: qi_avt2 v1.0 board status In-Reply-To: <19ebea720909131017t4427e960j888fdb74322c825e@mail.gmail.com> References: <4AAA0C6A.5050409@qi-hardware.com> <4AACB2EB.7030601@qi-hardware.com> <19ebea720909130630u154dad1w6d206965830aa342@mail.gmail.com> <4AAD0DA9.1000003@qi-hardware.com> <19ebea720909131017t4427e960j888fdb74322c825e@mail.gmail.com> Message-ID: <19ebea720909131018u69cceb4ka8ce55ad2603fa9a@mail.gmail.com> Upps the link is [1] http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/orcad_sch/qi_avt2_v1.0-0902jy.dsn Carlos On Sun, Sep 13, 2009 at 12:17 PM, Carlos Camargo wrote: > Hi Adam > > > > Next week the procesess will be kept cob and manual soldering for safe >> reason, i want test boards before gluing; >> so will spend time to check all size after maybe next week later. sorry >> for this. >> Adam >> > > > No problem, I understand :) > > > Can you tell me if the last file uploaded [1] corresponds with the PCB > under test? > > > Best Regards > > > > Carlos > > > > -- > Carlos Iv?n Camargo Bare?o > Profesor Asistente > Departamento de Ingenier?a El?ctrica y Electr?nica > Universidad Nacional de Colombia > cicamargoba at unal.edu.co > -- Carlos Iv?n Camargo Bare?o Profesor Asistente Departamento de Ingenier?a El?ctrica y Electr?nica Universidad Nacional de Colombia cicamargoba at unal.edu.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From michaelshiloh1010 at gmail.com Sun Sep 13 16:29:49 2009 From: michaelshiloh1010 at gmail.com (Michael Shiloh) Date: Sun, 13 Sep 2009 13:29:49 -0700 Subject: Ben NanoNote booting In-Reply-To: <20090913073641.GB8185@a82-93-13-222.adsl.xs4all.nl> References: <20090913073641.GB8185@a82-93-13-222.adsl.xs4all.nl> Message-ID: <4AAD563D.8040305@gmail.com> Easiest way I found to short those pads together is with a small piece of carbonized rubber, such as is found in almost all computer keyboards and other consumer electronic pushbuttons. After taking the keyboard apart I cut out one of the small the rubberized carbon regions, and use that to make the connection. Very reliable and tends to stick in place. You can even wedge it under the battery for a semi-permanent connection. Bas Wijnen wrote: > Hi, > > Last week, I received my Ben prototype (thanks Mirko!). Now I want to > make it boot Iris. Preferably I don't want to install it on an SD card. > That should be possible, right? Under the battery are two pads which > say that the device uses "usb boot" when they are closed. I'll probably > solder them closed. However, my first attempt to close them with a > screwdriver while powering up didn't make anything special happen. > Also, my system logs don't show anything about new devices being plugged > in. > > The wiki says something about a "usbboot" utility which is part of the > openwrt tree(?) I'll probably be adjusting it so it will boot Iris > instead of Linux. > > Summarizing, what I would prefer is the easiest possible way to boot a > new system from my main computer on the Ben. Best would be if it can be > triggered by a command on the main computer. Also good would be to > power-cycle the Ben. Not so good would be if the cable needs to be > replugged. Still worse would be to write every image to an SD card > before it can be booted. > > I have no problem at all if the USB cable needs to be connected > continuously. Eventually that isn't good of course, but now I'm only > developing. > > Thanks, > Bas > > > ------------------------------------------------------------------------ > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer From wolfgang at qi-hardware.com Sun Sep 13 19:06:40 2009 From: wolfgang at qi-hardware.com (Wolfgang Spraul) Date: Sun, 13 Sep 2009 19:06:40 -0400 Subject: Ben NanoNote booting In-Reply-To: <886128c30909130723s5b02ca61xf0f8ca39014317c2@mail.gmail.com> References: <20090913073641.GB8185@a82-93-13-222.adsl.xs4all.nl> <19ebea720909130647m3266f3a2o560c38da080dc99e@mail.gmail.com> <886128c30909130723s5b02ca61xf0f8ca39014317c2@mail.gmail.com> Message-ID: <20090913230640.GA2473@debian> Ron, you need one with level shifter, because the NanoNote serial operates at 3.3V. I am using FTDI TTL-232R-3V3-WE, Mouser has them. 'WE' stands for wire-ended. Another option is TTL-232R-3V3-2MM, which ends in a 2mm connector. To be more flexible, you should not solder the cable directly to the NanoNote, but instead solder some thin wires to the NanoNote and then connect those to your cable in whatever way is most convenient to you. Another way to get a serial console for kernel development is the g_ether approach Carlos suggested... Wolfgang On Sun, Sep 13, 2009 at 07:23:44AM -0700, Ron K. Jeffries wrote: > I am (obviously) not a hard-core developer. But... > would someone suggest which FTDI cable to purchase? > > I've looked at http://mouser.com; TMI ;) > --- > Ron K. Jeffries > http://blog.eronj.com > > > > > > > > > > 2009/9/13 Carlos Camargo : > > > > > > Hi > > > > This links can help you: > > > > ?http://wiki.qi-hardware.com/index.php/Ben_source_code > > ?http://wiki.qi-hardware.com/index.php/How_to_reflash? > > > > > > Carlos > > > > > > > > -- > > Carlos Iv?n Camargo Bare?o > > Profesor Asistente > > Departamento de Ingenier?a El?ctrica y Electr?nica > > Universidad Nacional de Colombia > > cicamargoba at unal.edu.co > > > > _______________________________________________ > > Qi Developer Mailing List > > Mail to list (members only): developer at lists.qi-hardware.com > > Subscribe or Unsubscribe: > > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer From adam at qi-hardware.com Sun Sep 13 20:58:50 2009 From: adam at qi-hardware.com (Adam Wang) Date: Mon, 14 Sep 2009 08:58:50 +0800 Subject: qi_avt2 v1.0 board status In-Reply-To: <19ebea720909131018u69cceb4ka8ce55ad2603fa9a@mail.gmail.com> References: <4AAA0C6A.5050409@qi-hardware.com> <4AACB2EB.7030601@qi-hardware.com> <19ebea720909130630u154dad1w6d206965830aa342@mail.gmail.com> <4AAD0DA9.1000003@qi-hardware.com> <19ebea720909131017t4427e960j888fdb74322c825e@mail.gmail.com> <19ebea720909131018u69cceb4ka8ce55ad2603fa9a@mail.gmail.com> Message-ID: <4AAD954A.9000409@qi-hardware.com> Hi Calos, Carlos Camargo wrote: > Upps the link is > > [1] > http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/orcad_sch/qi_avt2_v1.0-0902jy.dsn > Yes, this file is the correspondence. Adam > > Carlos > > > On Sun, Sep 13, 2009 at 12:17 PM, Carlos Camargo > > wrote: > > Hi Adam > > > > Next week the procesess will be kept cob and manual soldering > for safe reason, i want test boards before gluing; > so will spend time to check all size after maybe next week > later. sorry for this. > Adam > > > > No problem, I understand :) > > > Can you tell me if the last file uploaded [1] corresponds with the > PCB under test? > > > Best Regards > > > > Carlos > > > > -- > Carlos Iv?n Camargo Bare?o > Profesor Asistente > Departamento de Ingenier?a El?ctrica y Electr?nica > Universidad Nacional de Colombia > cicamargoba at unal.edu.co > > > > > -- > Carlos Iv?n Camargo Bare?o > Profesor Asistente > Departamento de Ingenier?a El?ctrica y Electr?nica > Universidad Nacional de Colombia > cicamargoba at unal.edu.co > ------------------------------------------------------------------------ > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer -------------- next part -------------- An HTML attachment was scrubbed... URL: From michaelshiloh1010 at gmail.com Sun Sep 13 22:57:13 2009 From: michaelshiloh1010 at gmail.com (Michael Shiloh) Date: Sun, 13 Sep 2009 19:57:13 -0700 Subject: is usbboot available anywhere so i don't have to get source and build my own? In-Reply-To: <2b311fa30907131227s6efb1c60n129eb63c42931d06@mail.gmail.com> References: <2b311fa30907111831g65c90746u40e2769806205dd0@mail.gmail.com> <4A59705C.5060000@gmail.com> <2b311fa30907131139y1f0d964du59744e097647f379@mail.gmail.com> <2b311fa30907131227s6efb1c60n129eb63c42931d06@mail.gmail.com> Message-ID: <4AADB109.4080309@gmail.com> working w/ steve right now to boot his new nnnt. following http://wiki.qi-hardware.com/index.php/How_to_reflash downloaded those 4 files, all good, but now need usbboot. following http://wiki.qi-hardware.com/index.php/Ben_source_code#xburst-tools_.28usbboot_tools.29 but download of git tree takes awhile. faster if i could find a pre-built usbboot. i'm on ubuntu. m From michaelshiloh1010 at gmail.com Sun Sep 13 23:07:30 2009 From: michaelshiloh1010 at gmail.com (Michael Shiloh) Date: Sun, 13 Sep 2009 20:07:30 -0700 Subject: Ben NanoNote booting In-Reply-To: <20090913230640.GA2473@debian> References: <20090913073641.GB8185@a82-93-13-222.adsl.xs4all.nl> <19ebea720909130647m3266f3a2o560c38da080dc99e@mail.gmail.com> <886128c30909130723s5b02ca61xf0f8ca39014317c2@mail.gmail.com> <20090913230640.GA2473@debian> Message-ID: <4AADB372.70806@gmail.com> These are pretty standard devices in the hobbyist world, due to the popularity of the FTDI chip due to its ease of use and available drivers for all 3 operating systems. For instance, many Arduino derivitives use this level shifting FTDI cable. Look at sources like adafruit, sparkfun, and even maker shed. Michael Wolfgang Spraul wrote: > Ron, > you need one with level shifter, because the NanoNote serial operates > at 3.3V. I am using FTDI TTL-232R-3V3-WE, Mouser has them. > 'WE' stands for wire-ended. > Another option is TTL-232R-3V3-2MM, which ends in a 2mm connector. > To be more flexible, you should not solder the cable directly to the > NanoNote, but instead solder some thin wires to the NanoNote and then > connect those to your cable in whatever way is most convenient to you. > > Another way to get a serial console for kernel development is the > g_ether approach Carlos suggested... > Wolfgang > > On Sun, Sep 13, 2009 at 07:23:44AM -0700, Ron K. Jeffries wrote: >> I am (obviously) not a hard-core developer. But... >> would someone suggest which FTDI cable to purchase? >> >> I've looked at http://mouser.com; TMI ;) >> --- >> Ron K. Jeffries >> http://blog.eronj.com >> >> >> >> >> >> >> >> >> >> 2009/9/13 Carlos Camargo : >>> >>> Hi >>> >>> This links can help you: >>> >>> http://wiki.qi-hardware.com/index.php/Ben_source_code >>> http://wiki.qi-hardware.com/index.php/How_to_reflash? >>> >>> >>> Carlos >>> >>> >>> >>> -- >>> Carlos Iv?n Camargo Bare?o >>> Profesor Asistente >>> Departamento de Ingenier?a El?ctrica y Electr?nica >>> Universidad Nacional de Colombia >>> cicamargoba at unal.edu.co >>> >>> _______________________________________________ >>> Qi Developer Mailing List >>> Mail to list (members only): developer at lists.qi-hardware.com >>> Subscribe or Unsubscribe: >>> http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer >>> >> _______________________________________________ >> Qi Developer Mailing List >> Mail to list (members only): developer at lists.qi-hardware.com >> Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > From wolfgang at qi-hardware.com Sun Sep 13 23:38:37 2009 From: wolfgang at qi-hardware.com (Wolfgang Spraul) Date: Sun, 13 Sep 2009 23:38:37 -0400 Subject: is usbboot available anywhere so i don't have to get source and build my own? In-Reply-To: <4AADB109.4080309@gmail.com> References: <2b311fa30907111831g65c90746u40e2769806205dd0@mail.gmail.com> <4A59705C.5060000@gmail.com> <2b311fa30907131139y1f0d964du59744e097647f379@mail.gmail.com> <2b311fa30907131227s6efb1c60n129eb63c42931d06@mail.gmail.com> <4AADB109.4080309@gmail.com> Message-ID: <20090914033837.GA2185@debian> Michael, look at http://downloads.qi-hardware.com/software/xburst-tools Wolfgang On Sun, Sep 13, 2009 at 07:57:13PM -0700, Michael Shiloh wrote: > working w/ steve right now to boot his new nnnt. following > > http://wiki.qi-hardware.com/index.php/How_to_reflash > > downloaded those 4 files, all good, but now need usbboot. following > > http://wiki.qi-hardware.com/index.php/Ben_source_code#xburst-tools_.28usbboot_tools.29 > > but download of git tree takes awhile. faster if i could find a > pre-built usbboot. > > i'm on ubuntu. > > m > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer From wolfgang at qi-hardware.com Sun Sep 13 23:41:35 2009 From: wolfgang at qi-hardware.com (Wolfgang Spraul) Date: Sun, 13 Sep 2009 23:41:35 -0400 Subject: Suggestion: NanoNote Personalities Program In-Reply-To: <20090912203617.GE10957@ross154.net> References: <20090912203617.GE10957@ross154.net> Message-ID: <20090914034135.GB2185@debian> sjl, Yes! Thank you very much for writing this up in such a nice way. Right now we are all focused on a stable kernel (and getting the product out :-)), but right after that I believe something like the personalities program is where we should take the product and the company. If anyone can start going down that direction now with some preparations, that would be fantastic. Also, I do like the emphasis you put on manuals and customer service, and seeing 'programming' as participating rather than coding. Way to go, thanks again! Wolfgang P.S.: If you don't mind, I will copy the personalities plan to our wiki at http://wiki.qi-hardware.com so we can follow up easier over time... On Sat, Sep 12, 2009 at 01:36:17PM -0700, sjl at ross154.net wrote: > NanoNote Personalities Program[1] > > You know the changable cellphone cover fad, where they snapped on > different colorful plastic covers? The NanoNote should offer > different "spins" offering different types of functionality, > aka "personalities". > > Example personalities: > * graphing calculator > * electronic spelling dictionary / translator > * travel buddy (wikitravel / openstreetmap) > * puzzle games > * beginner programming languages (python, pascal, etc) > * PDA > * Gutenberg ebooks reader > > Every personality would be available both as a downloadable > image and preinstalled on SD cards sold as NN accessories. > Every SD card would have a custom sticker to show at a > glance which personality is installed on it. > There would be a little case or slipcover for the NN > that would include a little compartment for an SD collection. > > Company responsibilities: > > * Pay an artist to work with personality development teams on a > a splashscreen + tiny SD sticker art for each team > * Pay good tech writers to develop user guides for each personality; > bonus points for paying tech writers to help out on developer docs!! > * Provide hosting for personality development teams, but also support > mirroring of install images for teams that want to use their > own server > * Hire knowledgable and good-tempered customer support engineers > willing to shield developers from grumpy customers and > customers from grumpy developers > * Handle retail of the pre-installed SDs, including the custom > stickers for branding (also offer stickers separately for those > who want to download images to already-owned SD) > * Offer to donate some portion of pre-installed SD / sticker profit to > project designated by leaders of corresponding dev team > > Developer team responsibilities: > > Most of the personalities would use the openwrt base, but some of > the ones intended for hacking might slap the NN kernel into another > embedded distro, e.g. a gentoo embedded experiment (gentoo has > mips support). > > * Work with artist to come up with custom splashscreen > and SD sticker art > * Make sure the official splashscreen for the personality gets > displayed at boot > * Answer questions from tech writer regarding user guide > > [1] "program" in the sense of "something you can participate in", > not in the sense of "code a computer executes" > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer From michaelshiloh1010 at gmail.com Sun Sep 13 23:43:46 2009 From: michaelshiloh1010 at gmail.com (Michael Shiloh) Date: Sun, 13 Sep 2009 20:43:46 -0700 Subject: is usbboot available anywhere so i don't have to get source and build my own? In-Reply-To: <20090914033837.GA2185@debian> References: <2b311fa30907111831g65c90746u40e2769806205dd0@mail.gmail.com> <4A59705C.5060000@gmail.com> <2b311fa30907131139y1f0d964du59744e097647f379@mail.gmail.com> <2b311fa30907131227s6efb1c60n129eb63c42931d06@mail.gmail.com> <4AADB109.4080309@gmail.com> <20090914033837.GA2185@debian> Message-ID: <4AADBBF2.6050806@michaelshiloh.com> Hi Wolfgang, I looked in the .tgz file but didn't find it. Looks like source only, same as I'd get from git. Still have to compile, and therefore set up first the cross development tools. I'm doing that too, but that will take awhile. Haven't tried the .deb package yet. I'll do so now. M Wolfgang Spraul wrote: > Michael, > look at http://downloads.qi-hardware.com/software/xburst-tools > Wolfgang > > On Sun, Sep 13, 2009 at 07:57:13PM -0700, Michael Shiloh wrote: >> working w/ steve right now to boot his new nnnt. following >> >> http://wiki.qi-hardware.com/index.php/How_to_reflash >> >> downloaded those 4 files, all good, but now need usbboot. following >> >> http://wiki.qi-hardware.com/index.php/Ben_source_code#xburst-tools_.28usbboot_tools.29 >> >> but download of git tree takes awhile. faster if i could find a >> pre-built usbboot. >> >> i'm on ubuntu. >> >> m >> >> _______________________________________________ >> Qi Developer Mailing List >> Mail to list (members only): developer at lists.qi-hardware.com >> Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > From michaelshiloh1010 at gmail.com Sun Sep 13 23:44:35 2009 From: michaelshiloh1010 at gmail.com (Michael Shiloh) Date: Sun, 13 Sep 2009 20:44:35 -0700 Subject: is usbboot available anywhere so i don't have to get source and build my own? In-Reply-To: <20090914033837.GA2185@debian> References: <2b311fa30907111831g65c90746u40e2769806205dd0@mail.gmail.com> <4A59705C.5060000@gmail.com> <2b311fa30907131139y1f0d964du59744e097647f379@mail.gmail.com> <2b311fa30907131227s6efb1c60n129eb63c42931d06@mail.gmail.com> <4AADB109.4080309@gmail.com> <20090914033837.GA2185@debian> Message-ID: <4AADBC23.3030201@michaelshiloh.com> yup, it's in the .deb package. installing now. m Wolfgang Spraul wrote: > Michael, > look at http://downloads.qi-hardware.com/software/xburst-tools > Wolfgang > > On Sun, Sep 13, 2009 at 07:57:13PM -0700, Michael Shiloh wrote: >> working w/ steve right now to boot his new nnnt. following >> >> http://wiki.qi-hardware.com/index.php/How_to_reflash >> >> downloaded those 4 files, all good, but now need usbboot. following >> >> http://wiki.qi-hardware.com/index.php/Ben_source_code#xburst-tools_.28usbboot_tools.29 >> >> but download of git tree takes awhile. faster if i could find a >> pre-built usbboot. >> >> i'm on ubuntu. >> >> m >> >> _______________________________________________ >> Qi Developer Mailing List >> Mail to list (members only): developer at lists.qi-hardware.com >> Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > From realrichardsharpe at gmail.com Sun Sep 13 23:46:06 2009 From: realrichardsharpe at gmail.com (Richard Sharpe) Date: Sun, 13 Sep 2009 20:46:06 -0700 Subject: Did I hear that there is a Chinese English with the Nanonote? Message-ID: <46b8a8850909132046s245e7753kf748375b83a80b75@mail.gmail.com> Also, Is there a calculator app that could replace a TI-89 etc? -- Regards, Richard Sharpe From xiangfu at qi-hardware.com Sun Sep 13 23:46:06 2009 From: xiangfu at qi-hardware.com (Xiangfu Liu) Date: Mon, 14 Sep 2009 11:46:06 +0800 Subject: is usbboot available anywhere so i don't have to get source and build my own? In-Reply-To: <4AADB109.4080309@gmail.com> References: <2b311fa30907111831g65c90746u40e2769806205dd0@mail.gmail.com> <4A59705C.5060000@gmail.com> <2b311fa30907131139y1f0d964du59744e097647f379@mail.gmail.com> <2b311fa30907131227s6efb1c60n129eb63c42931d06@mail.gmail.com> <4AADB109.4080309@gmail.com> Message-ID: <4AADBC7E.1040805@qi-hardware.com> Michael Shiloh wrote: > working w/ steve right now to boot his new nnnt. following > > http://wiki.qi-hardware.com/index.php/How_to_reflash > > downloaded those 4 files, all good, but now need usbboot. following > > http://wiki.qi-hardware.com/index.php/Ben_source_code#xburst-tools_.28usbboot_tools.29 > > > but download of git tree takes awhile. faster if i could find a > pre-built usbboot. > here is a deb package: http://downloads.qi-hardware.com/software/xburst-tools/xburst-tools_0.0+200906-1_i386.deb downloads it. then just double click on it. > i'm on ubuntu. > > m > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer From michaelshiloh1010 at gmail.com Sun Sep 13 23:53:22 2009 From: michaelshiloh1010 at gmail.com (Michael Shiloh) Date: Sun, 13 Sep 2009 20:53:22 -0700 Subject: is usbboot available anywhere so i don't have to get source and build my own? In-Reply-To: <4AADBC7E.1040805@qi-hardware.com> References: <2b311fa30907111831g65c90746u40e2769806205dd0@mail.gmail.com> <4A59705C.5060000@gmail.com> <2b311fa30907131139y1f0d964du59744e097647f379@mail.gmail.com> <2b311fa30907131227s6efb1c60n129eb63c42931d06@mail.gmail.com> <4AADB109.4080309@gmail.com> <4AADBC7E.1040805@qi-hardware.com> Message-ID: <4AADBE32.3000408@michaelshiloh.com> good news! took only two retries to get nnnt into "usb boot" mode, ran the shell script, and indeed flashed the device. right now it's on the openwrt splash screen. hopefully kernel is booting underneath, or else it's hung. i'll give it a few minutes. personally, at this stage, i wish there weren't a splash screen, so i could see the process. *Update* it's booted into a terminal. steve's reaction: OMG! Xiangfu Liu wrote: > Michael Shiloh wrote: >> working w/ steve right now to boot his new nnnt. following >> >> http://wiki.qi-hardware.com/index.php/How_to_reflash >> >> downloaded those 4 files, all good, but now need usbboot. following >> >> http://wiki.qi-hardware.com/index.php/Ben_source_code#xburst-tools_.28usbboot_tools.29 >> >> >> but download of git tree takes awhile. faster if i could find a >> pre-built usbboot. >> > here is a deb package: > http://downloads.qi-hardware.com/software/xburst-tools/xburst-tools_0.0+200906-1_i386.deb > > downloads it. then just double click on it. > >> i'm on ubuntu. >> >> m >> >> _______________________________________________ >> Qi Developer Mailing List >> Mail to list (members only): developer at lists.qi-hardware.com >> Subscribe or Unsubscribe: >> http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > From xiangfu at qi-hardware.com Mon Sep 14 00:42:55 2009 From: xiangfu at qi-hardware.com (Xiangfu Liu) Date: Mon, 14 Sep 2009 12:42:55 +0800 Subject: is usbboot available anywhere so i don't have to get source and build my own? In-Reply-To: <4AADBE32.3000408@michaelshiloh.com> References: <2b311fa30907111831g65c90746u40e2769806205dd0@mail.gmail.com> <4A59705C.5060000@gmail.com> <2b311fa30907131139y1f0d964du59744e097647f379@mail.gmail.com> <2b311fa30907131227s6efb1c60n129eb63c42931d06@mail.gmail.com> <4AADB109.4080309@gmail.com> <4AADBC7E.1040805@qi-hardware.com> <4AADBE32.3000408@michaelshiloh.com> Message-ID: <4AADC9CF.1010301@qi-hardware.com> Michael Shiloh wrote: > good news! took only two retries to get nnnt into "usb boot" mode, ran > the shell script, and indeed flashed the device. > > right now it's on the openwrt splash screen. hopefully kernel is booting > underneath, or else it's hung. > > i'll give it a few minutes. > > personally, at this stage, i wish there weren't a splash screen, so i > could see the process. > > *Update* Hi here is my jabber: xiangfu at qi-hardware.com you can add me. From michaelshiloh1010 at gmail.com Mon Sep 14 00:44:04 2009 From: michaelshiloh1010 at gmail.com (Michael Shiloh) Date: Sun, 13 Sep 2009 21:44:04 -0700 Subject: Couple of quick observations on the Ben NanoNote Message-ID: <4AADCA14.8010103@gmail.com> It's great to have a Linux console in such a small size. Keyboard is very usable for its size Boot time is wonderful. I suspect this will excite geeks to no end. Including vi was brilliant. The blue Fn key and the red arrow key don't seem to be performing their functions. The Fn key does nothing, the red arrow key generates a space. Is it possible to get USB networking working? What steps do I take to do this? I've made some minor tweaks to the wiki "How to reflash" page, and added a rough page on how to boot into USB_BOOT mode. Please correct if wrong. Michael From michaelshiloh1010 at gmail.com Mon Sep 14 00:50:37 2009 From: michaelshiloh1010 at gmail.com (Michael Shiloh) Date: Sun, 13 Sep 2009 21:50:37 -0700 Subject: is usbboot available anywhere so i don't have to get source and build my own? In-Reply-To: <4AADC9CF.1010301@qi-hardware.com> References: <2b311fa30907111831g65c90746u40e2769806205dd0@mail.gmail.com> <4A59705C.5060000@gmail.com> <2b311fa30907131139y1f0d964du59744e097647f379@mail.gmail.com> <2b311fa30907131227s6efb1c60n129eb63c42931d06@mail.gmail.com> <4AADB109.4080309@gmail.com> <4AADBC7E.1040805@qi-hardware.com> <4AADBE32.3000408@michaelshiloh.com> <4AADC9CF.1010301@qi-hardware.com> Message-ID: <4AADCB9D.1080600@michaelshiloh.com> Xiangfu Liu wrote: > Michael Shiloh wrote: >> good news! took only two retries to get nnnt into "usb boot" mode, ran >> the shell script, and indeed flashed the device. >> >> right now it's on the openwrt splash screen. hopefully kernel is booting >> underneath, or else it's hung. >> >> i'll give it a few minutes. >> >> personally, at this stage, i wish there weren't a splash screen, so i >> could see the process. >> >> *Update* > Hi > > here is my jabber: xiangfu at qi-hardware.com > you can add me. > cool. i'll add you later. i'm going home now. thanks, m From xiangfu at qi-hardware.com Mon Sep 14 01:57:55 2009 From: xiangfu at qi-hardware.com (Xiangfu Liu) Date: Mon, 14 Sep 2009 13:57:55 +0800 Subject: Couple of quick observations on the Ben NanoNote In-Reply-To: <4AADCA14.8010103@gmail.com> References: <4AADCA14.8010103@gmail.com> Message-ID: <4AADDB63.4020909@qi-hardware.com> Michael Shiloh wrote: > It's great to have a Linux console in such a small size. > > Keyboard is very usable for its size > > Boot time is wonderful. I suspect this will excite geeks to no end. > > Including vi was brilliant. > > The blue Fn key and the red arrow key don't seem to be performing their > functions. The Fn key does nothing, the red arrow key generates a space. > I upload a new kernel[1] the [red arrow key] is work. but the Fn key not work. I make the [red arrow key] + F[1~8] = 1 ~ 8 [red arrow key] + Z = 9 [red arrow key] + X = 0 [1]http://downloads.qi-hardware.com/software/images/Ben_NanoNote_2GB_NAND/openwrt-xburst-uImage.bin > Is it possible to get USB networking working? What steps do I take to do > this? > > I've made some minor tweaks to the wiki "How to reflash" page, and added > a rough page on how to boot into USB_BOOT mode. Please correct if wrong. > > Michael > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer From xiangfu at qi-hardware.com Mon Sep 14 02:00:22 2009 From: xiangfu at qi-hardware.com (Xiangfu Liu) Date: Mon, 14 Sep 2009 14:00:22 +0800 Subject: Did I hear that there is a Chinese English with the Nanonote? In-Reply-To: <46b8a8850909132046s245e7753kf748375b83a80b75@mail.gmail.com> References: <46b8a8850909132046s245e7753kf748375b83a80b75@mail.gmail.com> Message-ID: <4AADDBF6.3090605@qi-hardware.com> Richard Sharpe wrote: > Also, > > Is there a calculator app that could replace a TI-89 etc? > what you mean "Chinese English with Nanonote"? From xiangfu at qi-hardware.com Mon Sep 14 04:05:30 2009 From: xiangfu at qi-hardware.com (Xiangfu Liu) Date: Mon, 14 Sep 2009 16:05:30 +0800 Subject: keyboard driver Message-ID: <4AADF94A.3040800@qi-hardware.com> Hi some problem need fix in keyboard driver like: a w u | | | | s j | | | Shift Alt Ctrl press = output 1. [Shift] + [w] = W 2. [Shift] + [u] = U 3. a = a ----------- 1. [Shift] + [a] = a 2. a = A 3. a = a ----------- so problem is: if the keys and modifier in same column it's will not correct generate the keys at the first time. any one have some idea on this? [1] is the diff. [2] is the keypad picture. seems if I want make the [Fn] keys work I must look into the driver code. because there is only [SHIFT] [CONTROL] [ALTGR] three modifier keys. [1] http://projects.qi-hardware.com/index.php/p/openwrt-xburst/source/commit/1035dea0049c584b82d60643d0c4f56881e97866/ [2] http://downloads.qi-hardware.com/hardware/mechanical/ben/2009_08_26/keyboard_problem_2.JPG From uwe at hermann-uwe.de Mon Sep 14 08:27:30 2009 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Mon, 14 Sep 2009 14:27:30 +0200 Subject: Wiki: upload facility and favicon Message-ID: <20090914122730.GD22053@greenwood> Hi, please consider enabling the upload functionality in MediaWiki (for photos, e.g. those from http://randomprojects.org/wiki/Qi_Hardware_Ben_NanoNote and more that will follow. Also, the wiki.qi-hardware.com subdomain doesn't seem to have the favicon, please add that too to make it easier to find the Qi Hardware browser TABs if you have lots of them open (like I do pretty often). Thanks, Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org From lars at metafoo.de Mon Sep 14 09:17:58 2009 From: lars at metafoo.de (Lars-Peter Clausen) Date: Mon, 14 Sep 2009 15:17:58 +0200 Subject: Couple of quick observations on the Ben NanoNote In-Reply-To: <4AADCA14.8010103@gmail.com> References: <4AADCA14.8010103@gmail.com> Message-ID: <4AAE4286.30307@metafoo.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Michael Shiloh wrote: > > Is it possible to get USB networking working? What steps do I take > to do this? To get usb networking you have to enable the usb ethernet gadget in kernel config and rebuild the kernel. You can find it in menuconfig under Device Drivers->USB support->USB Gadget Support. But I guess we should enable it by default. I'll commit a change to do so soon. - - Lars -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkquQoUACgkQBX4mSR26RiPiMwCeMrb7YHlhKhjVi0rTn8r+Ny1Y /RoAn3h2nYZ9PYLNZIF7DL+i8o2e+Eu2 =i6vb -----END PGP SIGNATURE----- From michaelshiloh1010 at gmail.com Mon Sep 14 12:48:43 2009 From: michaelshiloh1010 at gmail.com (Michael Shiloh) Date: Mon, 14 Sep 2009 09:48:43 -0700 Subject: Couple of quick observations on the Ben NanoNote In-Reply-To: <4AAE4286.30307@metafoo.de> References: <4AADCA14.8010103@gmail.com> <4AAE4286.30307@metafoo.de> Message-ID: <4AAE73EB.2020804@michaelshiloh.com> Yes, please do. To me, that would be a requirement. As I told Steve last night: I'm a hard-core command line Linux geek, and I know there are many like us. Not enough to support a business, but enough to be the early users and evangelists. If I had USB networking I would immediately have copied my calendar, todo list, and shopping lists, all of which are plain text, into the Ben. With vi and a command line, that's all I need. Any chance you could do this this week? I'm showing the Ben at GadgetOff next week, and it would be great. Then onwards towards total victory! Michael Lars-Peter Clausen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi > > Michael Shiloh wrote: >> Is it possible to get USB networking working? What steps do I take >> to do this? > To get usb networking you have to enable the usb ethernet gadget in > kernel config and rebuild the kernel. You can find it in menuconfig > under Device Drivers->USB support->USB Gadget Support. > But I guess we should enable it by default. I'll commit a change to do > so soon. > > - - Lars > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkquQoUACgkQBX4mSR26RiPiMwCeMrb7YHlhKhjVi0rTn8r+Ny1Y > /RoAn3h2nYZ9PYLNZIF7DL+i8o2e+Eu2 > =i6vb > -----END PGP SIGNATURE----- > > From lars at metafoo.de Mon Sep 14 13:00:20 2009 From: lars at metafoo.de (Lars-Peter Clausen) Date: Mon, 14 Sep 2009 19:00:20 +0200 Subject: Couple of quick observations on the Ben NanoNote In-Reply-To: <4AAE73EB.2020804@michaelshiloh.com> References: <4AADCA14.8010103@gmail.com> <4AAE4286.30307@metafoo.de> <4AAE73EB.2020804@michaelshiloh.com> Message-ID: <4AAE76A4.8030605@metafoo.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Shiloh wrote: > Yes, please do. To me, that would be a requirement. > > As I told Steve last night: I'm a hard-core command line Linux > geek, and I know there are many like us. Not enough to support a > business, but enough to be the early users and evangelists. > > If I had USB networking I would immediately have copied my > calendar, todo list, and shopping lists, all of which are plain > text, into the Ben. With vi and a command line, that's all I need. > > Any chance you could do this this week? I'm showing the Ben at > GadgetOff next week, and it would be great. > > Then onwards towards total victory! > > Michael Hi Michael It's already done :) If you don't want to build your own kernel you'll have to wait for Xiangfu to upload a new image, though. - - Lars -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqudqMACgkQBX4mSR26RiPWDACfWkJoIWayb3q3k1EzZhVAt+Bi 2V0An13v0NhJbnjdj8qDyogJG4ffqLDY =Sw6/ -----END PGP SIGNATURE----- From michaelshiloh1010 at gmail.com Mon Sep 14 13:19:48 2009 From: michaelshiloh1010 at gmail.com (Michael Shiloh) Date: Mon, 14 Sep 2009 10:19:48 -0700 Subject: Couple of quick observations on the Ben NanoNote In-Reply-To: <4AAE76A4.8030605@metafoo.de> References: <4AADCA14.8010103@gmail.com> <4AAE4286.30307@metafoo.de> <4AAE73EB.2020804@michaelshiloh.com> <4AAE76A4.8030605@metafoo.de> Message-ID: <4AAE7B34.2050406@michaelshiloh.com> Lars-Peter Clausen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Michael Shiloh wrote: >> Yes, please do. To me, that would be a requirement. >> >> As I told Steve last night: I'm a hard-core command line Linux >> geek, and I know there are many like us. Not enough to support a >> business, but enough to be the early users and evangelists. >> >> If I had USB networking I would immediately have copied my >> calendar, todo list, and shopping lists, all of which are plain >> text, into the Ben. With vi and a command line, that's all I need. >> >> Any chance you could do this this week? I'm showing the Ben at >> GadgetOff next week, and it would be great. >> >> Then onwards towards total victory! >> >> Michael > > Hi Michael > > It's already done :) Sweet!! > If you don't want to build your own kernel you'll have to wait for > Xiangfu to upload a new image, though. Xiangfu, if you can do this within a day or two, I'll wait for yours, otherwise, I'll start setting up a kernel build tree. From steve at qi-hardware.com Mon Sep 14 17:07:59 2009 From: steve at qi-hardware.com (Steve Mosher) Date: Mon, 14 Sep 2009 14:07:59 -0700 Subject: Nano hardware-developers kit In-Reply-To: <19ebea720909121035o7864f582n8c03342ec70bf0f1@mail.gmail.com> References: <19ebea720909121035o7864f582n8c03342ec70bf0f1@mail.gmail.com> Message-ID: <2b311fa30909141407o2c74e1f5i5c25661034f51c8@mail.gmail.com> Great idea. On Sat, Sep 12, 2009 at 10:35 AM, Carlos Camargo wrote: > Hi All > > We are talking with Wolfgang about additional Nano's feature, As some > people said, Nano would be useful as brain in a custom electronic device. We > (emQbit) are thinking in build a power quality measurement device based on > Nano. Maybe some people in this list thinking similarly. > > Because of that Wolfgang has an idea: Build a developer board, or a > commercial board for companies like us, with additional resources like JTAG, > 232 level shifter, SPI, I2C ports, additional AVR for make mano > Arduino-compatible, an FPGA for robotic applications, etc. > > The first approach for this (Wolfgang idea), is make only one board, the > commercial Nano would be a sub-set of this board, so, we have only one pcb > and we can build both cards from the same design. Wolfgang think use the > same case for both versions. > > > Is necessary, define some topics: > 1. Switch the hardware design to Kicad. > 2. What kind of interfaces will support the developer platform (I2C, JTAG, > SPI, FPGA, AVR microcontroller, etc)? > 3. How this additional hardware will be connected with the JZ4720, Data, > address, control bus lines, SPI, I2C, USB host? > I'm starting the discussion showing some advantages of the different > possibilities: > > 1. Using Address, Data and Control processor's Bus signals [1]: If you have > access to this signals, you can connect any peripheral to Nano, and you can > map the FPGA logic as a simple RAM memory [2]. But there are many signals: > Data (8-16) + Control (4), Address (13 ?) = 33. > > 2. SPI port [3]. The main advantage is that this protocol use only 4 wires, > but we need one (CS) for each peripheral. > > 3. I2C [4] This protocol use two wires only, but is slow. > > 4. FPGA. For use one FPGA we need the signals in 1. and some GPIOs for > configuration process (TDI, TDO, TMS, TCK). Unless that the FPGA implement a > I2C or SPI device. > > 5. AVR. The Atmega8 family [5] provide a wide range of peripherals like > ADCs, SPI, I2C, ports, Timers, and allow the ISP [6], so we can use an > external Atmega through SPI or I2C processor ports, and we can programming > it with 4 GPIOs. > > > Please comment on this and add additional features do you like, > > > Best Regards > > Carlos > > > [1] http://downloads.qi-hardware.com/hardware/hacking/computer-simple.png > [2] http://downloads.qi-hardware.com/hardware/hacking/sw_hw_fpga_arch.png > [3] http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus > [4] http://en.wikipedia.org/wiki/I%C2%B2C > [5] http://www.atmel.com/dyn/products/devices.asp?family_id=607 > [6] http://en.wikipedia.org/wiki/In-System_Programming > > > > > > > -- > Carlos Iv?n Camargo Bare?o > Profesor Asistente > Departamento de Ingenier?a El?ctrica y Electr?nica > Universidad Nacional de Colombia > cicamargoba at unal.edu.co > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at qi-hardware.com Mon Sep 14 18:09:47 2009 From: steve at qi-hardware.com (Steve Mosher) Date: Mon, 14 Sep 2009 15:09:47 -0700 Subject: Ben NanoNote booting In-Reply-To: <4AAD563D.8040305@gmail.com> References: <20090913073641.GB8185@a82-93-13-222.adsl.xs4all.nl> <4AAD563D.8040305@gmail.com> Message-ID: <2b311fa30909141509u4e69913an8dcef31e9304307e@mail.gmail.com> Michael showed me his little trick. Its very cool. On Sun, Sep 13, 2009 at 1:29 PM, Michael Shiloh wrote: > Easiest way I found to short those pads together is with a small piece of > carbonized rubber, such as is found in almost all computer keyboards and > other consumer electronic pushbuttons. After taking the keyboard apart I cut > out one of the small the rubberized carbon regions, and use that to make the > connection. Very reliable and tends to stick in place. You can even wedge it > under the battery for a semi-permanent connection. > > Bas Wijnen wrote: > >> Hi, >> >> Last week, I received my Ben prototype (thanks Mirko!). Now I want to >> make it boot Iris. Preferably I don't want to install it on an SD card. >> That should be possible, right? Under the battery are two pads which >> say that the device uses "usb boot" when they are closed. I'll probably >> solder them closed. However, my first attempt to close them with a >> screwdriver while powering up didn't make anything special happen. >> Also, my system logs don't show anything about new devices being plugged >> in. >> >> The wiki says something about a "usbboot" utility which is part of the >> openwrt tree(?) I'll probably be adjusting it so it will boot Iris >> instead of Linux. >> >> Summarizing, what I would prefer is the easiest possible way to boot a >> new system from my main computer on the Ben. Best would be if it can be >> triggered by a command on the main computer. Also good would be to >> power-cycle the Ben. Not so good would be if the cable needs to be >> replugged. Still worse would be to write every image to an SD card >> before it can be booted. >> >> I have no problem at all if the USB cable needs to be connected >> continuously. Eventually that isn't good of course, but now I'm only >> developing. >> >> Thanks, >> Bas >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Qi Developer Mailing List >> Mail to list (members only): developer at lists.qi-hardware.com >> Subscribe or Unsubscribe: >> http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer >> > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at qi-hardware.com Mon Sep 14 18:14:11 2009 From: steve at qi-hardware.com (Steve Mosher) Date: Mon, 14 Sep 2009 15:14:11 -0700 Subject: Suggestion: NanoNote Personalities Program In-Reply-To: <20090912203617.GE10957@ross154.net> References: <20090912203617.GE10957@ross154.net> Message-ID: <2b311fa30909141514w26a8ed71hebe64a57adde93e7@mail.gmail.com> As a goal that is exactly what we had in mind. As wolfgang notes right now we are focused on the everything below the kernel. That way the "personalities" or flavors have a solid basis. Further, I would Also like to see people step forward and OWN some of these business opportunities. They would buy hardware from us at a discount, do all the tasks you outline on company side. There is no reason for Qi to do all this business. we grow faster if we share that opportunity with the community. On Sat, Sep 12, 2009 at 1:36 PM, wrote: > NanoNote Personalities Program[1] > > You know the changable cellphone cover fad, where they snapped on > different colorful plastic covers? The NanoNote should offer > different "spins" offering different types of functionality, > aka "personalities". > > Example personalities: > * graphing calculator > * electronic spelling dictionary / translator > * travel buddy (wikitravel / openstreetmap) > * puzzle games > * beginner programming languages (python, pascal, etc) > * PDA > * Gutenberg ebooks reader > > Every personality would be available both as a downloadable > image and preinstalled on SD cards sold as NN accessories. > Every SD card would have a custom sticker to show at a > glance which personality is installed on it. > There would be a little case or slipcover for the NN > that would include a little compartment for an SD collection. > > Company responsibilities: > > * Pay an artist to work with personality development teams on a > a splashscreen + tiny SD sticker art for each team > * Pay good tech writers to develop user guides for each personality; > bonus points for paying tech writers to help out on developer docs!! > * Provide hosting for personality development teams, but also support > mirroring of install images for teams that want to use their > own server > * Hire knowledgable and good-tempered customer support engineers > willing to shield developers from grumpy customers and > customers from grumpy developers > * Handle retail of the pre-installed SDs, including the custom > stickers for branding (also offer stickers separately for those > who want to download images to already-owned SD) > * Offer to donate some portion of pre-installed SD / sticker profit to > project designated by leaders of corresponding dev team > > Developer team responsibilities: > > Most of the personalities would use the openwrt base, but some of > the ones intended for hacking might slap the NN kernel into another > embedded distro, e.g. a gentoo embedded experiment (gentoo has > mips support). > > * Work with artist to come up with custom splashscreen > and SD sticker art > * Make sure the official splashscreen for the personality gets > displayed at boot > * Answer questions from tech writer regarding user guide > > [1] "program" in the sense of "something you can participate in", > not in the sense of "code a computer executes" > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.5 (GNU/Linux) > > iD8DBQFKrAZB/NoSW7FuNV8RAi5uAKDSvKAFEw28rebPhq1BKE2X3TcavwCaAgJf > infXmKdaCQ5NhhCd0ts/nIg= > =00+9 > -----END PGP SIGNATURE----- > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wolfgang at qi-hardware.com Mon Sep 14 21:01:00 2009 From: wolfgang at qi-hardware.com (Wolfgang Spraul) Date: Mon, 14 Sep 2009 21:01:00 -0400 Subject: mailing list malfunction Message-ID: <20090915010100.GA2582@debian> Hi, I made a small but significant mistake last night re-configuring our server (we are moving to a bigger server with several VMs, more about that later). Result was that 8 mails were not delivered to most/all subscribers (they arrived at the list though and are archived): Uwe Hermann - Wiki: upload facility and favicon http://lists.qi-hardware.com/pipermail/developer/2009-September/000553.html Lars-Peter Clausen & Michael Shiloh - Couple of quick observations on the Ben NanoNote http://lists.qi-hardware.com/pipermail/developer/2009-September/000554.html http://lists.qi-hardware.com/pipermail/developer/2009-September/000555.html http://lists.qi-hardware.com/pipermail/developer/2009-September/000556.html http://lists.qi-hardware.com/pipermail/developer/2009-September/000557.html Steve Mosher - Nano hardware-developers kit http://lists.qi-hardware.com/pipermail/developer/2009-September/000558.html Steve Mosher - Ben NanoNote booting http://lists.qi-hardware.com/pipermail/developer/2009-September/000559.html Steve Mosher - Suggestion: NanoNote Personalities Program http://lists.qi-hardware.com/pipermail/developer/2009-September/000560.html Sorry about the inconvenience, keep your fingers crossed - the next few days we are moving and upgrading more stuff... Wolfgang From wolfgang at qi-hardware.com Tue Sep 15 01:46:13 2009 From: wolfgang at qi-hardware.com (Wolfgang Spraul) Date: Tue, 15 Sep 2009 01:46:13 -0400 Subject: 64MB RAM chip for Ya NanoNote Message-ID: <20090915054613.GA3226@debian> Adam, (Carlos already went to sleep in Colombia, so I am posting his suggestion from jabber here...) Carlos said it might be relatively easy to upgrade the SDRAM chip on our board to this one to get 64 MB memory: http://www.micron.com/products/partdetail?part=MT48LC32M16A2P-75 Do you think it will work? Can we use it as a drop-in replacement on AVT2, or do you have to make changes? Wolfgang From xiangfu at qi-hardware.com Tue Sep 15 02:58:26 2009 From: xiangfu at qi-hardware.com (Xiangfu Liu) Date: Tue, 15 Sep 2009 14:58:26 +0800 Subject: Couple of quick observations on the Ben NanoNote Message-ID: <4AAF3B12.7010905@qi-hardware.com> Lars-Peter Clausen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Michael Shiloh wrote: >> Yes, please do. To me, that would be a requirement. >> >> As I told Steve last night: I'm a hard-core command line Linux >> geek, and I know there are many like us. Not enough to support a >> business, but enough to be the early users and evangelists. >> >> If I had USB networking I would immediately have copied my >> calendar, todo list, and shopping lists, all of which are plain >> text, into the Ben. With vi and a command line, that's all I need. >> >> Any chance you could do this this week? I'm showing the Ben at >> GadgetOff next week, and it would be great. >> >> Then onwards towards total victory! >> >> Michael > > Hi Michael > > It's already done :) Sweet!! > If you don't want to build your own kernel you'll have to wait for > Xiangfu to upload a new image, though. Xiangfu, if you can do this within a day or two, I'll wait for yours, otherwise, I'll start setting up a kernel build tree. yes. I will try to upload the new kernel today. now. I am try to fix the patch error. From adam at qi-hardware.com Tue Sep 15 04:17:07 2009 From: adam at qi-hardware.com (Adam Wang) Date: Tue, 15 Sep 2009 16:17:07 +0800 Subject: 64MB RAM chip for Ya NanoNote In-Reply-To: <20090915054613.GA3226@debian> References: <20090915054613.GA3226@debian> Message-ID: <4AAF4D83.2080900@qi-hardware.com> Hi, Wolfgang Spraul wrote: > Adam, > (Carlos already went to sleep in Colombia, so I am posting his suggestion > from jabber here...) > > Carlos said it might be relatively easy to upgrade the SDRAM chip on our > board to this one to get 64 MB memory: > http://www.micron.com/products/partdetail?part=MT48LC32M16A2P-75 > > this micron's part is 8 Meg * 16 * 4 banks = 512Mbit, should use 15 wiring addressing (A0~A12, A13/A14) to manage 4 banks, so this is 32M for 16 bits data line. of course it can be configured 64M but for 8 bits length = 16 Meg * 8 * 4 banks, > Do you think it will work? > Can we use it as a drop-in replacement on AVT2, or do you have to make > changes? > From the jz4720 datasheet, it shpws A0~A14 can be used as for SDRAM, so MT48LC32M16A2P should be drop-in for 32M for 16 bits data line. But A15 pin(PB15) will be as for NAND flash command latch if using nand, so this is the jz4720's limitation on pin allocation. if find a 64M for 16 bits data line, it can not replace directly on avt2's design, have to make change; like Ingenic's reference design to use dual 32M SDRAM with extra two GPIOs to allocate and assign the UDQM/LDQM pins of SDRAM, and then can reach 64M capacity. Adam > Wolfgang > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > From xiangfu at qi-hardware.com Tue Sep 15 04:42:04 2009 From: xiangfu at qi-hardware.com (Xiangfu Liu) Date: Tue, 15 Sep 2009 16:42:04 +0800 Subject: Couple of quick observations on the Ben NanoNote In-Reply-To: <4AAF3B12.7010905@qi-hardware.com> References: <4AAF3B12.7010905@qi-hardware.com> Message-ID: <4AAF535C.6070109@qi-hardware.com> Xiangfu Liu wrote: > Lars-Peter Clausen wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Michael Shiloh wrote: >>> Yes, please do. To me, that would be a requirement. >>> >>> As I told Steve last night: I'm a hard-core command line Linux >>> geek, and I know there are many like us. Not enough to support a >>> business, but enough to be the early users and evangelists. >>> >>> If I had USB networking I would immediately have copied my >>> calendar, todo list, and shopping lists, all of which are plain >>> text, into the Ben. With vi and a command line, that's all I need. >>> >>> Any chance you could do this this week? I'm showing the Ben at >>> GadgetOff next week, and it would be great. >>> >>> Then onwards towards total victory! >>> >>> Michael >> Hi Michael >> >> It's already done :) > > Sweet!! > > >> If you don't want to build your own kernel you'll have to wait for >> Xiangfu to upload a new image, though. > > Xiangfu, if you can do this within a day or two, I'll wait for yours, > otherwise, I'll start setting up a kernel build tree. > > yes. I will try to upload the new kernel today. > now. I am try to fix the patch error. Hi Lars I try to compile you commit. but it's not work in my system. attach is the patch. the kernel can compile, and there is 'usb0' network interface in my system. but the when I press any key in Ben, it will cause kernel panic. -------------- next part -------------- A non-text attachment was scrubbed... Name: 999-fix-kerenl-compile-error.patch Type: text/x-patch Size: 3329 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: fix-patch-error.patch Type: text/x-patch Size: 3440 bytes Desc: not available URL: From cicamargoba at gmail.com Tue Sep 15 08:08:20 2009 From: cicamargoba at gmail.com (Carlos Camargo) Date: Tue, 15 Sep 2009 07:08:20 -0500 Subject: 64MB RAM chip for Ya NanoNote In-Reply-To: <4AAF4D83.2080900@qi-hardware.com> References: <20090915054613.GA3226@debian> <4AAF4D83.2080900@qi-hardware.com> Message-ID: <19ebea720909150508s2637ac7ew2af33f8f39c78bc1@mail.gmail.com> Hi >From SDRAM's Data-sheet [1] pag 8: Address: A0 - A12, BA0, BA1 13 lines for Columns, 10 for Rows. pag 16: DQML, DQMH: Input/output mask: DQM is an input mask signal for write accesses and an output enable signal for read accesses. Input data is masked when DQM is sampled HIGH during a WRITE cycle. The output buffers are placed in a High-Z state (two-clock latency) when DQM is sampled HIGH during a READ cycle. On the x4 and x8, DQML (Pin 15) is a NC and DQMH is DQM. On the x16, DQML corresponds to DQ0?DQ7, and DQMH corresponds to DQ8?DQ15. DQML and DQMH are considered same state when referenced as DQM. >From JZ4740 DataSheet: Byte enable 0 WE0# / For non-byte-control static memory , D7-0 write enable signal, BE0# / For byte-control static memory , D7-0 selection signal DQM0 / For SDRAM, D7?D0 selection signal Byte enable 1 WE1# / For non-byte-control static memory , D15-8 write enable signal BE1# / For byte-control static memory , D15-8 selection signal DQM1/ For SDRAM, D15?D8 selection signal So, this memory use the same number of rows, and one more column bit that 32MB memory, If you change to: ROWADDR = 13 #Row address width in bits (11-13) COLADDR = 10 #Column address width in bits (8-12) In usbboot config file you can use 64MD SDRAM Best Regards [1] http://download.micron.com/pdf/datasheets/dram/sdram/512MbSDRAM.pdf On Tue, Sep 15, 2009 at 3:17 AM, Adam Wang wrote: > Hi, > > Wolfgang Spraul wrote: > >> Adam, >> (Carlos already went to sleep in Colombia, so I am posting his suggestion >> from jabber here...) >> >> Carlos said it might be relatively easy to upgrade the SDRAM chip on our >> board to this one to get 64 MB memory: >> http://www.micron.com/products/partdetail?part=MT48LC32M16A2P-75 >> >> >> > this micron's part is 8 Meg * 16 * 4 banks = 512Mbit, should use 15 wiring > addressing (A0~A12, A13/A14) to manage 4 banks, so this is 32M for 16 bits > data line. > of course it can be configured 64M but for 8 bits length = 16 Meg * 8 * 4 > banks, > >> Do you think it will work? >> Can we use it as a drop-in replacement on AVT2, or do you have to make >> changes? >> >> > From the jz4720 datasheet, it shpws A0~A14 can be used as for SDRAM, so > MT48LC32M16A2P should be drop-in for 32M for 16 bits data line. > But A15 pin(PB15) will be as for NAND flash command latch if using nand, so > this is the jz4720's limitation on pin allocation. > > if find a 64M for 16 bits data line, it can not replace directly on avt2's > design, have to make change; like Ingenic's reference design to use dual 32M > SDRAM with > extra two GPIOs to allocate and assign the UDQM/LDQM pins of SDRAM, and > then can reach 64M capacity. > Adam > > Wolfgang >> >> _______________________________________________ >> Qi Developer Mailing List >> Mail to list (members only): developer at lists.qi-hardware.com >> Subscribe or Unsubscribe: >> http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer >> >> > > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -- Carlos Iv?n Camargo Bare?o Profesor Asistente Departamento de Ingenier?a El?ctrica y Electr?nica Universidad Nacional de Colombia cicamargoba at unal.edu.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From andres.calderon at emqbit.com Tue Sep 15 08:24:50 2009 From: andres.calderon at emqbit.com (=?ISO-8859-1?Q?Andr=E9s_Calder=F3n?=) Date: Tue, 15 Sep 2009 07:24:50 -0500 Subject: 64MB RAM chip for Ya NanoNote In-Reply-To: <4AAF4D83.2080900@qi-hardware.com> References: <20090915054613.GA3226@debian> <4AAF4D83.2080900@qi-hardware.com> Message-ID: <6e36f2f00909150524o48cb0248md559ebead519c17c@mail.gmail.com> On Tue, Sep 15, 2009 at 3:17 AM, Adam Wang wrote: > Hi, > > Wolfgang Spraul wrote: >> >> Adam, >> (Carlos already went to sleep in Colombia, so I am posting his suggestion >> from jabber here...) >> >> Carlos said it might be relatively easy to upgrade the SDRAM chip on our >> board to this one to get 64 MB memory: >> http://www.micron.com/products/partdetail?part=MT48LC32M16A2P-75 >> >> > > this micron's part is 8 Meg * 16 * 4 banks = 512Mbit, should use 15 wiring > addressing (A0~A12, A13/A14) to manage 4 banks, so this is 32M for 16 bits > data line. > of course it can be configured 64M but for 8 bits length = 16 Meg * 8 * 4 > banks, >> >> Do you think it will work? >> Can we use it as a drop-in replacement on AVT2, or do you have to make >> changes? >> > > From the jz4720 datasheet, it shpws A0~A14 can be used as for SDRAM, so > MT48LC32M16A2P should be drop-in for 32M for 16 bits data line. > But A15 pin(PB15) will be as for NAND flash command latch if using nand, so > this is the jz4720's limitation on pin allocation. > > if find a 64M for 16 bits data line, it can not replace directly on avt2's > design, have to make change; like Ingenic's reference design to use dual 32M > SDRAM with > extra two GPIOs to allocate and assign the UDQM/LDQM pins of SDRAM, and then > can reach 64M capacity. > Adam >> Hi, In the AVT2 are connected 13 address lines between de JZ4720 and the SDRAM, enough for the row addressing of 64MBytes (16 bits) SDRAM. Number of addressing lines of de 512Mb SDRAM (32Mwords x 16 bits): Row addressing A0-A12 (AVT2 compliant) Columns addressing A0-A9 (AVT2 compliant) Bank addressing BA0-BA1 (AVT2 compliant) Andr?s Calder?n Cel: +57 (300) 275 3666 Email: andres.calderon at emqbit.com Web: www.emqbit.com >> Wolfgang >> >> _______________________________________________ >> Qi Developer Mailing List >> Mail to list (members only): developer at lists.qi-hardware.com >> Subscribe or Unsubscribe: >> http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer >> > > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > From kzjeef at gmail.com Tue Sep 15 11:22:02 2009 From: kzjeef at gmail.com (ZhangJieJing) Date: Tue, 15 Sep 2009 23:22:02 +0800 Subject: HW ECC correction error on LB60. Message-ID: Hi Everyone, I found that my board(LB60) have ECC error with NAND flash, kernel will continue dumping message like [1] forever. After trace this error code, I found that was print by jz nand driver([2]:174), jz nand driver default use Hardware nand ECC, in([2]:308). I fix this problem just replace HW ECC by SW ECC[3], So, I think we maybe we don't set corrent HW parameter to the controller. maybe someone can check it. I suggest before this the right HW parameter found, we can just use SW ECC, It's also fast enough for me. [1]: uncorrectable ecc: 0xd 0x2e 0xfc 0xff 0xff 0xff 0xff 0xff 0xff uncorrectable data: 0xfb 0x97 0x46 0x73 0x7f 0x9b 0x3 0xf9 0x6a 0xff 0x96 0xf7 e [2]: http://projects.qi-hardware.com/index.php/p/openwrt-xburst/source/tree/xburst/target/linux/xburst/files-2.6.31/drivers/mtd/nand/jz4740_nand.c [3]: # based on openwrt, xburst branch on projects.qi-hardware.com diff --git a/target/linux/xburst/files-2.6.31/drivers/mtd/nand/jz4740_nand.c b/target/linux/xburst/files-2.6.31/drivers/mtd/nand/jz4740_nand.c index 7b378c0..1e53852 100644 --- a/target/linux/xburst/files-2.6.31/drivers/mtd/nand/jz4740_nand.c +++ b/target/linux/xburst/files-2.6.31/drivers/mtd/nand/jz4740_nand.c @@ -305,7 +305,9 @@ static int __devinit jz_nand_probe(struct platform_device *pdev) chip->ecc.calculate = jz_nand_calculate_ecc_rs; chip->ecc.correct = jz_nand_correct_ecc_rs; - chip->ecc.mode = NAND_ECC_HW; + /* chip->ecc.mode = NAND_ECC_HW; */ + /* FIXME: jz's HW ECC correction dump too many, use a soft ecc + * instead */ chip->ecc.size = 512; chip->ecc.bytes = 9; if (pdata) --- Best regards, Zhang Jiejing -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at qi-hardware.com Wed Sep 16 05:02:27 2009 From: adam at qi-hardware.com (Adam Wang) Date: Wed, 16 Sep 2009 17:02:27 +0800 Subject: 64MB RAM chip for Ya NanoNote In-Reply-To: <6e36f2f00909150524o48cb0248md559ebead519c17c@mail.gmail.com> References: <20090915054613.GA3226@debian> <4AAF4D83.2080900@qi-hardware.com> <6e36f2f00909150524o48cb0248md559ebead519c17c@mail.gmail.com> Message-ID: <4AB0A9A3.6050509@qi-hardware.com> Hi Carlos & Andr?s Andr?s Calder?n wrote: > On Tue, Sep 15, 2009 at 3:17 AM, Adam Wang wrote: > >> Hi, >> >> Wolfgang Spraul wrote: >> >>> Adam, >>> (Carlos already went to sleep in Colombia, so I am posting his suggestion >>> from jabber here...) >>> >>> Carlos said it might be relatively easy to upgrade the SDRAM chip on our >>> board to this one to get 64 MB memory: >>> http://www.micron.com/products/partdetail?part=MT48LC32M16A2P-75 >>> >>> >>> >> this micron's part is 8 Meg * 16 * 4 banks = 512Mbit, should use 15 wiring >> addressing (A0~A12, A13/A14) to manage 4 banks, so this is 32M for 16 bits >> data line. >> of course it can be configured 64M but for 8 bits length = 16 Meg * 8 * 4 >> banks, >> >>> Do you think it will work? >>> Can we use it as a drop-in replacement on AVT2, or do you have to make >>> changes? >>> >>> > > >> From the jz4720 datasheet, it shpws A0~A14 can be used as for SDRAM, so >> MT48LC32M16A2P should be drop-in for 32M for 16 bits data line. >> But A15 pin(PB15) will be as for NAND flash command latch if using nand, so >> this is the jz4720's limitation on pin allocation. >> >> if find a 64M for 16 bits data line, it can not replace directly on avt2's >> design, have to make change; like Ingenic's reference design to use dual 32M >> SDRAM with >> extra two GPIOs to allocate and assign the UDQM/LDQM pins of SDRAM, and then >> can reach 64M capacity. >> Adam >> > > Hi, > > In the AVT2 are connected 13 address lines between de JZ4720 and the > SDRAM, enough for the row addressing of 64MBytes (16 bits) SDRAM. > > You are right on this chip, sorry that I treated 64MB to be configured as(64M * 16 bits data lines), so now the chip provided from you of course can be replaced on avt2. So I'll try to get this part locally and replace them. Will inform you once finish. Adam > Number of addressing lines of de 512Mb SDRAM (32Mwords x 16 bits): > Row addressing A0-A12 (AVT2 compliant) > Columns addressing A0-A9 (AVT2 compliant) > Bank addressing BA0-BA1 (AVT2 compliant) > > Andr?s Calder?n > Cel: +57 (300) 275 3666 > Email: andres.calderon at emqbit.com > Web: www.emqbit.com > > > >>> Wolfgang >>> >>> _______________________________________________ >>> Qi Developer Mailing List >>> Mail to list (members only): developer at lists.qi-hardware.com >>> Subscribe or Unsubscribe: >>> http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer >>> >>> >> _______________________________________________ >> Qi Developer Mailing List >> Mail to list (members only): developer at lists.qi-hardware.com >> Subscribe or Unsubscribe: >> http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer >> >> > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cicamargoba at gmail.com Wed Sep 16 07:35:14 2009 From: cicamargoba at gmail.com (Carlos Camargo) Date: Wed, 16 Sep 2009 06:35:14 -0500 Subject: 64MB RAM chip for Ya NanoNote In-Reply-To: <4AB0A9A3.6050509@qi-hardware.com> References: <20090915054613.GA3226@debian> <4AAF4D83.2080900@qi-hardware.com> <6e36f2f00909150524o48cb0248md559ebead519c17c@mail.gmail.com> <4AB0A9A3.6050509@qi-hardware.com> Message-ID: <19ebea720909160435t591d5cf9wd271317fec646284@mail.gmail.com> Hi Adam I'll be waiting for you report :) Best Regards Carlos On Wed, Sep 16, 2009 at 4:02 AM, Adam Wang wrote: > Hi Carlos & Andr?s > > > Andr?s Calder?n wrote: > > On Tue, Sep 15, 2009 at 3:17 AM, Adam Wang wrote: > > > Hi, > > Wolfgang Spraul wrote: > > > Adam, > (Carlos already went to sleep in Colombia, so I am posting his suggestion > from jabber here...) > > Carlos said it might be relatively easy to upgrade the SDRAM chip on our > board to this one to get 64 MB memory:http://www.micron.com/products/partdetail?part=MT48LC32M16A2P-75 > > > this micron's part is 8 Meg * 16 * 4 banks = 512Mbit, should use 15 wiring > addressing (A0~A12, A13/A14) to manage 4 banks, so this is 32M for 16 bits > data line. > of course it can be configured 64M but for 8 bits length = 16 Meg * 8 * 4 > banks, > > > Do you think it will work? > Can we use it as a drop-in replacement on AVT2, or do you have to make > changes? > > > > From the jz4720 datasheet, it shpws A0~A14 can be used as for SDRAM, so > MT48LC32M16A2P should be drop-in for 32M for 16 bits data line. > But A15 pin(PB15) will be as for NAND flash command latch if using nand, so > this is the jz4720's limitation on pin allocation. > > if find a 64M for 16 bits data line, it can not replace directly on avt2's > design, have to make change; like Ingenic's reference design to use dual 32M > SDRAM with > extra two GPIOs to allocate and assign the UDQM/LDQM pins of SDRAM, and then > can reach 64M capacity. > Adam > > > Hi, > > In the AVT2 are connected 13 address lines between de JZ4720 and the > SDRAM, enough for the row addressing of 64MBytes (16 bits) SDRAM. > > > > You are right on this chip, sorry that I treated 64MB to be configured > as(64M * 16 bits data lines), so now the chip provided from you of course > can be replaced on avt2. So I'll try to get this part locally and replace > them. Will inform you once finish. > Adam > > Number of addressing lines of de 512Mb SDRAM (32Mwords x 16 bits): > Row addressing A0-A12 (AVT2 compliant) > Columns addressing A0-A9 (AVT2 compliant) > Bank addressing BA0-BA1 (AVT2 compliant) > > Andr?s Calder?n > Cel: +57 (300) 275 3666 > Email: andres.calderon at emqbit.com > Web: www.emqbit.com > > > Wolfgang > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe:http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe:http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -- Carlos Iv?n Camargo Bare?o Profesor Asistente Departamento de Ingenier?a El?ctrica y Electr?nica Universidad Nacional de Colombia cicamargoba at unal.edu.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at metafoo.de Wed Sep 16 15:45:11 2009 From: lars at metafoo.de (Lars-Peter Clausen) Date: Wed, 16 Sep 2009 21:45:11 +0200 Subject: HW ECC correction error on LB60. In-Reply-To: References: Message-ID: <4AB14047.8050101@metafoo.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ZhangJieJing wrote: > Hi Everyone, > > I found that my board(LB60) have ECC error with NAND flash, kernel will > continue dumping message like [1] forever. > Hi I did some investigation on the nand ecc issue today: The image is usually padded with 0xff bytes up to the eraseblock size. Depending on the image size this can fill whole pages. When flashing the image and writing a page usbboot will calculate the ecc data even for those pages filled 0xff and write it to the oob section of that page. Now, when the linux kernel mounts the image it thinks that these pages containing only 0xff are empty and can be written to without being haved erased before. So if data is written to such a page the ecc data for that page will be written ontop of the ecc data, which was previously written while flashing the image. Due to the nature of nand chips this will result in wrong ecc data and on the next read from that page it will show ecc errors. To fix it I wrote a simple patch[1] for usbboot which skips empty pages during write. So far I haven't seen a single ecc error. Xiangfu could you please apply that patch? (Or grant me commit access to usbboot) - Lars [1] http://metafoo.de/usbboot_dont_flash_empty_pages.patch -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqxQDEACgkQBX4mSR26RiNP2QCePXDwSAiHRjzDt0eQCXgS7HQj 81gAmwcfl4TCGZe3S6gXiSjt4HrTBDHX =E+KA -----END PGP SIGNATURE----- From cicamargoba at gmail.com Wed Sep 16 20:02:48 2009 From: cicamargoba at gmail.com (Carlos Camargo) Date: Wed, 16 Sep 2009 19:02:48 -0500 Subject: USB serial console In-Reply-To: <19ebea720909120917x6ee68bb6p794b9fabd5faa802@mail.gmail.com> References: <19ebea720909101226n21fb6c71j64996a76a87e7dc1@mail.gmail.com> <9f2feba00909110227q154b2eb6yaa298b144e9dba20@mail.gmail.com> <19ebea720909120917x6ee68bb6p794b9fabd5faa802@mail.gmail.com> Message-ID: <19ebea720909161702k28707087odaa3e7b4c87befa6@mail.gmail.com> Hi Ignacio Thanks again for your information, I replace the file drivers/usb/gadget/ether.c for Dignux kernel's file (kernel 2.6.24.3), add an entry to /etc/network/interfaces, auto usb0 iface usb0 inet static address 10.0.0.30 netmask 255.255.255.0 network 10.0.0.0 gateway 10.0.0.10 and all works fine!! Saludos Carlos On Sat, Sep 12, 2009 at 11:17 AM, Carlos Camargo wrote: > Thanks a lot Ignacio > > Saludos > > > Carlos > > > > > On Fri, Sep 11, 2009 at 4:27 AM, Ignacio Garc?a P?rez wrote: > >> Earlier releases of Dingux had a g_serial console too, but it had some >> inconveniences, for example file transfer is possible but a pain in the ass. >> >> So I moved to ethernet gadget. The interface is set as 10.1.0.2/30 and a >> DHCP server is configured to provide only one lease which is always >> 10.1.0.1/30. Inetd is also launched and telnet/ftp services are provided >> through it. When the system boots, the PC soon sees a new ethernet card >> which is autoconfigured v?a the DHCP server. Then you can access the console >> v?a telnet and transfer files v?a FTP. >> >> If you consider this approach, some remarks about the 2.6.24.3 Ingenic >> kernel: >> >> 1- You must modify the code to enable CDC mode in your code >> (drivers/usb/gadget/ether.c). >> 2- The code needs an small fix so Windows will recognize the ethernet card >> (see file above in the dingux kernel source). >> 3- Something is badly broken either in the Ingenic USB device or DMA code. >> The ethernet gadget only works reliably if you disable DMA (put >> jz4740_udc.use_dma=0 in the kernel command line). This halves throughput but >> works. >> >> I believe the DMA problem is not specific to the ethernet gadget code. I >> mean it should be present also when using the g_serial gadget. However, only >> shows up when using the full bandwidth, which rarely happens on a serial >> console. >> >> Regards. >> >> 2009/9/10 Carlos Camargo >> >>> HI >>> >>> I'm working with my custom JZ4725 board, I'm using linux 2.6.24.3 with >>> g_serial driver. I can run one console on /dev/ttygserial, so, we don't need >>> any USB/serial cable right now. >>> >>> I can't find the application getty on openwrt, I've already used mgetty, >>> but it doesn't work. I try with an openembedded distro, this distro provide >>> getty so, I can use it to enable the USB serial console. >>> >>> Is possible add getty to openwrt? >>> >>> >>> Best Regards >>> >>> Carlos >>> >>> >>> -- >>> Carlos Iv?n Camargo Bare?o >>> Profesor Asistente >>> Departamento de Ingenier?a El?ctrica y Electr?nica >>> Universidad Nacional de Colombia >>> cicamargoba at unal.edu.co >>> >>> _______________________________________________ >>> Qi Developer Mailing List >>> Mail to list (members only): developer at lists.qi-hardware.com >>> Subscribe or Unsubscribe: >>> http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer >>> >> >> >> _______________________________________________ >> Qi Developer Mailing List >> Mail to list (members only): developer at lists.qi-hardware.com >> Subscribe or Unsubscribe: >> http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer >> > > > > -- > Carlos Iv?n Camargo Bare?o > Profesor Asistente > Departamento de Ingenier?a El?ctrica y Electr?nica > Universidad Nacional de Colombia > cicamargoba at unal.edu.co > -- Carlos Iv?n Camargo Bare?o Profesor Asistente Departamento de Ingenier?a El?ctrica y Electr?nica Universidad Nacional de Colombia cicamargoba at unal.edu.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From wolfgang at qi-hardware.com Wed Sep 16 21:52:25 2009 From: wolfgang at qi-hardware.com (Wolfgang Spraul) Date: Wed, 16 Sep 2009 21:52:25 -0400 Subject: [Company] Weekly Operations Update 37/2009 Message-ID: <20090917015225.GA4943@debian> Hi, about last week: ---1 FCC passed, now ESD test failed A fix for the failed FCC radiation test was found, but unfortunately the next test uncovered another issue, this time an ESD issue because the USB connector was not grounded properly. Testing and fixing continues... http://lists.qi-hardware.com/pipermail/developer/2009-September/000504.html ---2 NanoNote Personalities Program I great proposal came in on our list that we could not have written better ourselves - the NanoNote Personalities Program: http://lists.qi-hardware.com/pipermail/developer/2009-September/000518.html Basically this is where we want to take things, and thanks a lot to SJLC (?) for writing this all up and sharing your enthousiasm with us! ---3 Adam's next-gen boards boot Adam got the first 4 boards of our next-gen hardware built, and they are booting OpenWrt already! http://lists.qi-hardware.com/pipermail/developer/2009-September/000521.html The process of defining our next generation hardware will continue, more boards will be made, feedback processed into another round, etc. If you are an electrical engineer there are many things you can contribute, we are also looking for more ways to open up the process. Suggestions welcome... That's all from last week, cu soon. Wolfgang From xiangfu at qi-hardware.com Wed Sep 16 22:26:13 2009 From: xiangfu at qi-hardware.com (Xiangfu Liu) Date: Thu, 17 Sep 2009 10:26:13 +0800 Subject: HW ECC correction error on LB60. In-Reply-To: <4AB14047.8050101@metafoo.de> References: <4AB14047.8050101@metafoo.de> Message-ID: <4AB19E45.1010207@qi-hardware.com> Lars-Peter Clausen wrote: > ZhangJieJing wrote: >> Hi Everyone, > >> I found that my board(LB60) have ECC error with NAND flash, kernel will >> continue dumping message like [1] forever. > > Hi > > I did some investigation on the nand ecc issue today: > The image is usually padded with 0xff bytes up to the eraseblock size. > Depending on the image size this can fill whole pages. When flashing > the image and writing a page usbboot will calculate the ecc data even > for those pages filled 0xff and write it to the oob section of that page. > > Now, when the linux kernel mounts the image it thinks that these pages > containing only 0xff are empty and can be written to without being > haved erased before. > So if data is written to such a page the ecc data for that page will > be written ontop of the ecc data, which was previously written while > flashing the image. Due to the nature of nand chips this will result > in wrong ecc data and on the next read from that page it will show ecc > errors. > > To fix it I wrote a simple patch[1] for usbboot which skips empty > pages during write. So far I haven't seen a single ecc error. > Xiangfu could you please apply that patch? (Or grant me commit access > to usbboot) thanks Lars. patch applied. also add your account to the usbboot. > > - Lars > > [1] http://metafoo.de/usbboot_dont_flash_empty_pages.patch From rjeffries at gmail.com Wed Sep 16 23:03:43 2009 From: rjeffries at gmail.com (Ron K. Jeffries) Date: Wed, 16 Sep 2009 20:03:43 -0700 Subject: [Company] Weekly Operations Update 37/2009 In-Reply-To: <20090917015225.GA4943@debian> References: <20090917015225.GA4943@debian> Message-ID: <886128c30909162003gfa46405h29935832b4bcc7c2@mail.gmail.com> for clarification When you say "our next generation board" do you mean the first Nanonote that will be sold commercially? On photos we see QI_AVT2 Rev 1.0 p.s. Stephanie Lockwood-Childs, leader of Santa Barbara Linux Group, is author of NanoNote Personalities Program: http://lists.qi-hardware.com/pipermail/developer/2009-September/000518.html --- Ron K. Jeffries On Wed, Sep 16, 2009 at 18:52, Wolfgang Spraul wrote: > Hi, > about last week: > ---3 Adam's next-gen boards boot > Adam got the first 4 boards of our next-gen hardware built, and they are > booting OpenWrt already! > http://lists.qi-hardware.com/pipermail/developer/2009-September/000521.html > The process of defining our next generation hardware will continue, more > boards will be made, feedback processed into another round, etc. > If you are an electrical engineer there are many things you can contribute, > we are also looking for more ways to open up the process. Suggestions > welcome... From wolfgang at qi-hardware.com Thu Sep 17 02:13:17 2009 From: wolfgang at qi-hardware.com (Wolfgang Spraul) Date: Thu, 17 Sep 2009 02:13:17 -0400 Subject: [Company] Weekly Operations Update 37/2009 In-Reply-To: <886128c30909162003gfa46405h29935832b4bcc7c2@mail.gmail.com> References: <20090917015225.GA4943@debian> <886128c30909162003gfa46405h29935832b4bcc7c2@mail.gmail.com> Message-ID: <20090917061317.GA5667@debian> Ron, > When you say "our next generation board" do you mean > the first Nanonote that will be sold commercially? > On photos we see QI_AVT2 Rev 1.0 No this meant the work towards Ya. The work that Adam and Carlos are doing right now is test runs and boards towards Ya. For our first commercial product, the Ben NanoNote, hardware design is hopefully finished, except for certification or production-related fixes. Wolfgang On Wed, Sep 16, 2009 at 08:03:43PM -0700, Ron K. Jeffries wrote: > for clarification > > When you say "our next generation board" do you mean > the first Nanonote that will be sold commercially? > On photos we see QI_AVT2 Rev 1.0 > > > p.s. Stephanie Lockwood-Childs, leader of Santa Barbara Linux Group, > is author of NanoNote Personalities Program: > http://lists.qi-hardware.com/pipermail/developer/2009-September/000518.html > --- > Ron K. Jeffries > > > > > > > > > > On Wed, Sep 16, 2009 at 18:52, Wolfgang Spraul wrote: > > Hi, > > about last week: > > > ---3 Adam's next-gen boards boot > > Adam got the first 4 boards of our next-gen hardware built, and they are > > booting OpenWrt already! > > http://lists.qi-hardware.com/pipermail/developer/2009-September/000521.html > > The process of defining our next generation hardware will continue, more > > boards will be made, feedback processed into another round, etc. > > If you are an electrical engineer there are many things you can contribute, > > we are also looking for more ways to open up the process. Suggestions > > welcome... > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer From iggarpe at gmail.com Thu Sep 17 04:27:02 2009 From: iggarpe at gmail.com (=?ISO-8859-1?Q?Ignacio_Garc=EDa_P=E9rez?=) Date: Thu, 17 Sep 2009 10:27:02 +0200 Subject: USB serial console In-Reply-To: <19ebea720909161702k28707087odaa3e7b4c87befa6@mail.gmail.com> References: <19ebea720909101226n21fb6c71j64996a76a87e7dc1@mail.gmail.com> <9f2feba00909110227q154b2eb6yaa298b144e9dba20@mail.gmail.com> <19ebea720909120917x6ee68bb6p794b9fabd5faa802@mail.gmail.com> <19ebea720909161702k28707087odaa3e7b4c87befa6@mail.gmail.com> Message-ID: <9f2feba00909170127i64fe4cd9y73d57bcf704fea71@mail.gmail.com> Since the network is point-to-point, you can restrict the net mask to a 30 bit one: iface usb0 inet static address 10.1.0.2 netmask 255.255.255.252 network 10.1.0.0 gateway 10.1.0.1 Also, just add a /etc/resolv.conf to the NN and configure your PC to route and you can access the internel from the NN. In your PC: echo 1 > /proc/sys/net/ipv4/ip_forward iptables -t nat -A POSTROUTING -s 10.1.0.2 -j MASQUERADE 2009/9/17 Carlos Camargo > Hi Ignacio > > Thanks again for your information, I replace the file > drivers/usb/gadget/ether.c for Dignux kernel's file (kernel 2.6.24.3), add > an entry to /etc/network/interfaces, > > auto usb0 > iface usb0 inet static > address 10.0.0.30 > netmask 255.255.255.0 > network 10.0.0.0 > gateway 10.0.0.10 > > and all works fine!! > > > Saludos > > > Carlos > > > > > On Sat, Sep 12, 2009 at 11:17 AM, Carlos Camargo wrote: > >> Thanks a lot Ignacio >> >> Saludos >> >> >> Carlos >> >> >> >> >> On Fri, Sep 11, 2009 at 4:27 AM, Ignacio Garc?a P?rez wrote: >> >>> Earlier releases of Dingux had a g_serial console too, but it had some >>> inconveniences, for example file transfer is possible but a pain in the ass. >>> >>> So I moved to ethernet gadget. The interface is set as 10.1.0.2/30 and a >>> DHCP server is configured to provide only one lease which is always >>> 10.1.0.1/30. Inetd is also launched and telnet/ftp services are provided >>> through it. When the system boots, the PC soon sees a new ethernet card >>> which is autoconfigured v?a the DHCP server. Then you can access the console >>> v?a telnet and transfer files v?a FTP. >>> >>> If you consider this approach, some remarks about the 2.6.24.3 Ingenic >>> kernel: >>> >>> 1- You must modify the code to enable CDC mode in your code >>> (drivers/usb/gadget/ether.c). >>> 2- The code needs an small fix so Windows will recognize the ethernet >>> card (see file above in the dingux kernel source). >>> 3- Something is badly broken either in the Ingenic USB device or DMA >>> code. The ethernet gadget only works reliably if you disable DMA (put >>> jz4740_udc.use_dma=0 in the kernel command line). This halves throughput but >>> works. >>> >>> I believe the DMA problem is not specific to the ethernet gadget code. I >>> mean it should be present also when using the g_serial gadget. However, only >>> shows up when using the full bandwidth, which rarely happens on a serial >>> console. >>> >>> Regards. >>> >>> 2009/9/10 Carlos Camargo >>> >>>> HI >>>> >>>> I'm working with my custom JZ4725 board, I'm using linux 2.6.24.3 with >>>> g_serial driver. I can run one console on /dev/ttygserial, so, we don't need >>>> any USB/serial cable right now. >>>> >>>> I can't find the application getty on openwrt, I've already used mgetty, >>>> but it doesn't work. I try with an openembedded distro, this distro provide >>>> getty so, I can use it to enable the USB serial console. >>>> >>>> Is possible add getty to openwrt? >>>> >>>> >>>> Best Regards >>>> >>>> Carlos >>>> >>>> >>>> -- >>>> Carlos Iv?n Camargo Bare?o >>>> Profesor Asistente >>>> Departamento de Ingenier?a El?ctrica y Electr?nica >>>> Universidad Nacional de Colombia >>>> cicamargoba at unal.edu.co >>>> >>>> _______________________________________________ >>>> Qi Developer Mailing List >>>> Mail to list (members only): developer at lists.qi-hardware.com >>>> Subscribe or Unsubscribe: >>>> http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer >>>> >>> >>> >>> _______________________________________________ >>> Qi Developer Mailing List >>> Mail to list (members only): developer at lists.qi-hardware.com >>> Subscribe or Unsubscribe: >>> http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer >>> >> >> >> >> -- >> Carlos Iv?n Camargo Bare?o >> Profesor Asistente >> Departamento de Ingenier?a El?ctrica y Electr?nica >> Universidad Nacional de Colombia >> cicamargoba at unal.edu.co >> > > > > -- > Carlos Iv?n Camargo Bare?o > Profesor Asistente > Departamento de Ingenier?a El?ctrica y Electr?nica > Universidad Nacional de Colombia > cicamargoba at unal.edu.co > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sjl at ross154.net Fri Sep 18 02:34:59 2009 From: sjl at ross154.net (sjl at ross154.net) Date: Thu, 17 Sep 2009 23:34:59 -0700 Subject: Feedback re NanoNote from Santa Barbara Liux Users Group Message-ID: <20090918063459.GB6969@ross154.net> Wolfgang Spraul wrote: > > 10. JTAG connection (internal) was suggested by hardware hackers > > Carlos (who is a hardware hacker) seems to think JTAG is not necessary > as it is typically mostly used to reflash devices and in our case that > capability is coming from the BOOT ROM in the CPU. > On the other hand I just sent a 4740 EVB to Lars because he needed JTAG > to track down a particular bug and couldn't do it with the NanoNote board. > So if you ever run into someone again who wants JTAG, ask them why, or ask > to write on this list so we better understand their needs. JTAG port can be very valuable for kernel debugging. Simulators like qemu work great for many things... but sometimes a hardware debugger like an abatron makes all the difference. --SJLC -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From xiangfu.z at gmail.com Fri Sep 18 03:43:22 2009 From: xiangfu.z at gmail.com (Xiangfu Liu) Date: Fri, 18 Sep 2009 15:43:22 +0800 Subject: Ben_Nanonote keyboard driver bug Message-ID: <4AB33A1A.7090508@gmail.com> Hi with Dmitry's help, our keyboard is work. we use the matrix_keypad.c driver. I found a problem. for example. the keypad is like this: (part of keypad) GPIO GPIO GPIO | | | a_______w_______u_____GPIO | | | |_______s_______j_____GPIO | | | Shift___Alt_____Ctrl__GPIO first time press [Shift] + [a] it's output [a] not the [A] second time press [Shift] + [a] it's output [A]. correct. then all work fine. but when I release the [Shift]. and press [a] it's will also output big [A]. but if the midifier and character not in same column GPIO. it will work fine. other modifier all like this. same GPIO will cause problem. I should look into the matrix_keypad.c to fix this, right? Best Regards -- Xiangfu Liu Email: xiangfu at qi-hardware dot com Web: http://www.qi-hardware.com From cicamargoba at gmail.com Fri Sep 18 07:57:40 2009 From: cicamargoba at gmail.com (Carlos Camargo) Date: Fri, 18 Sep 2009 06:57:40 -0500 Subject: Dingoo linux Message-ID: <19ebea720909180457y8f87d7fk2910cc1810091bf2@mail.gmail.com> Hi Ignacio I'm trying to save a dingoo linux on my custom board, but I have one problem, I can build successfully the uImage and save to NAND, the kenel boots, but I cant get a serial console, the last message is: mmc0: mmcblk0: p1 address 1234 mmcblk0: mmc0:1234 SA01G 995328KiB mmcblk0: p1 p2 p3 usb cable insert! EXT2-fs warning (device mmcblk0p2): ext2_fill_super: mounting ext3 filesystem as ext2 EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended VFS: Mounted root (ext2 filesystem). Freeing unused kernel memory: 156k freed With the ingenic image kernel I can use the serial console, but with dingoo kernel not, Dou you know why? Best Regards Carlos -- Carlos Iv?n Camargo Bare?o Profesor Asistente Departamento de Ingenier?a El?ctrica y Electr?nica Universidad Nacional de Colombia cicamargoba at unal.edu.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From kzjeef at gmail.com Fri Sep 18 14:17:01 2009 From: kzjeef at gmail.com (JieJing.Zhang) Date: Sat, 19 Sep 2009 02:17:01 +0800 Subject: [PATCH] jz battery driver cleanup In-Reply-To: References: Message-ID: <1253297821-8309-1-git-send-email-kzjeef@gmail.com> Signed-off-by: JieJing.Zhang --- .../xburst/files-2.6.31/drivers/power/jz_battery.c | 58 +++++++++++++------- 1 files changed, 39 insertions(+), 19 deletions(-) diff --git a/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c b/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c index 80b3747..514f2d2 100755 --- a/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c +++ b/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c @@ -28,10 +28,10 @@ #define dprintk(x...) while(0){} #endif -#define JZ_BAT_MAX_VOLTAGE 4200000 // uV +/* uV */ +#define JZ_BAT_MAX_VOLTAGE 4200000 #define JZ_BAT_MIN_VOLTAGE 3600000 -static DEFINE_MUTEX(bat_lock); struct workqueue_struct *monitor_wqueue; struct delayed_work bat_work; struct mutex work_lock; @@ -54,7 +54,7 @@ static int jz_get_power_prop(struct power_supply *psy, if (psy->type == POWER_SUPPLY_TYPE_MAINS) val->intval = !__gpio_get_pin(GPIO_DC_DETE_N); else - val->intval = __gpio_get_pin(GPIO_USB_DETE); + val->intval = (!!__gpio_get_pin(GPIO_USB_DETE)); break; default: return -EINVAL; @@ -92,13 +92,26 @@ static unsigned long jz_read_bat(struct power_supply *bat_ps) { unsigned long val; if (CFG_PBAT_DIV == 1) - val = (((unsigned long long)jz_read_battery() * 7500000)) >> 12; + val = (((unsigned long long)jz_read_battery() * 7500000L) >> 12) + 33000L; else - val = (((unsigned long long)jz_read_battery() * CFG_PBAT_DIV * 2500000)) >> 12; - dprintk("--raw_batter_vol=%d uV\n", val); + val = ((unsigned long long)jz_read_battery() * CFG_PBAT_DIV * 2500000L) >> 12; + dev_dbg(bat_ps->dev, "%s: raw_batter_vol = %d uV\n",__func__,val); return val; } +static int jz_bat_get_capacity(struct power_supply *bat_ps) +{ + int ret; + ret = (jz_read_bat(bat_ps) - JZ_BAT_MIN_VOLTAGE) * 100 + / (JZ_BAT_MAX_VOLTAGE - JZ_BAT_MIN_VOLTAGE); + if (ret > 100) { + dev_warn(bat_ps->dev, "%s: capacity=%d which exceeds 100," + "set to 100\n", __func__, ret); + ret = 100; + } + return ret; +} + static int jz_bat_get_property(struct power_supply *bat_ps, enum power_supply_property psp, union power_supply_propval *val) @@ -111,19 +124,20 @@ static int jz_bat_get_property(struct power_supply *bat_ps, val->intval = POWER_SUPPLY_TECHNOLOGY_LIPO; break; case POWER_SUPPLY_PROP_HEALTH: - if(jz_read_bat(bat_ps) < 3600000) { - dprintk("--battery dead\n"); + if(jz_read_bat(bat_ps) < JZ_BAT_MIN_VOLTAGE) { + dev_dbg(bat_ps->dev, "%s: battery is dead," + "voltage too low!\n", __func__); val->intval = POWER_SUPPLY_HEALTH_DEAD; } else { - dprintk("--battery good\n"); + dev_dbg(bat_ps->dev, "%s: battery is good," + "voltage normal.\n", __func__); val->intval = POWER_SUPPLY_HEALTH_GOOD; } break; case POWER_SUPPLY_PROP_CAPACITY: - val->intval = (jz_read_bat(bat_ps) - 3600000) * 100 / (4200000 - 3600000); - if (val->intval > 100) - val->intval = 100; - dprintk("--battery_capacity=%d\%\n",val->intval); + val->intval = jz_bat_get_capacity(bat_ps); + dev_dbg(bat_ps->dev, "%s: battery_capacity = %d\%\n", + __func__, val->intval); break; case POWER_SUPPLY_PROP_VOLTAGE_NOW: val->intval = jz_read_bat(bat_ps); @@ -140,7 +154,8 @@ static int jz_bat_get_property(struct power_supply *bat_ps, break; case POWER_SUPPLY_PROP_TEMP: case POWER_SUPPLY_PROP_VOL: - val->intval = 0; // reading TEMP and VOL aren't supported + /* reading TEMP and VOL aren't supported */ + val->intval = 0; break; default: return -EINVAL; @@ -174,12 +189,16 @@ static void jz_bat_update(struct power_supply *bat_ps) bat_status = POWER_SUPPLY_STATUS_NOT_CHARGING; } - dprintk("--battery status=%s\n", status_text[bat_status]); + dev_dbg(bat_ps->dev, "%s: battery status=%s\n", + __func__, status_text[bat_status]); + if ((old_status != bat_status) || (old_batt_vol - batt_vol > 50000)) { - pr_debug("%s %s -> %s\n", bat_ps->name, - status_text[old_status], - status_text[bat_status]); + dev_dbg(bat_ps->dev, "%s %s -> %s\n", + bat_ps->name, + status_text[old_status], + status_text[bat_status]); + power_supply_changed(bat_ps); } @@ -212,7 +231,8 @@ struct power_supply bat_ps = { static void jz_bat_work(struct work_struct *work) { - const int interval = HZ * 6; + /* query interval too small will increase system workload*/ + const int interval = HZ * 30; jz_bat_update(&bat_ps); queue_delayed_work(monitor_wqueue, &bat_work, interval); -- 1.6.0.4 From kzjeef at gmail.com Fri Sep 18 14:22:46 2009 From: kzjeef at gmail.com (ZhangJieJing) Date: Sat, 19 Sep 2009 02:22:46 +0800 Subject: [PATCH] jz battery driver cleanup In-Reply-To: <1253297821-8309-1-git-send-email-kzjeef@gmail.com> References: <1253297821-8309-1-git-send-email-kzjeef@gmail.com> Message-ID: Hi, xiangfu , sorry , this one is not good enough. please ignore this. --- Best regards, Zhang Jiejing On Sat, Sep 19, 2009 at 2:17 AM, JieJing.Zhang wrote: > Signed-off-by: JieJing.Zhang > --- > .../xburst/files-2.6.31/drivers/power/jz_battery.c | 58 > +++++++++++++------- > 1 files changed, 39 insertions(+), 19 deletions(-) > > diff --git a/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c > b/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c > index 80b3747..514f2d2 100755 > --- a/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c > +++ b/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c > @@ -28,10 +28,10 @@ > #define dprintk(x...) while(0){} > #endif > > -#define JZ_BAT_MAX_VOLTAGE 4200000 // uV > +/* uV */ > +#define JZ_BAT_MAX_VOLTAGE 4200000 > #define JZ_BAT_MIN_VOLTAGE 3600000 > > -static DEFINE_MUTEX(bat_lock); > struct workqueue_struct *monitor_wqueue; > struct delayed_work bat_work; > struct mutex work_lock; > @@ -54,7 +54,7 @@ static int jz_get_power_prop(struct power_supply *psy, > if (psy->type == POWER_SUPPLY_TYPE_MAINS) > val->intval = !__gpio_get_pin(GPIO_DC_DETE_N); > else > - val->intval = __gpio_get_pin(GPIO_USB_DETE); > + val->intval = (!!__gpio_get_pin(GPIO_USB_DETE)); > break; > default: > return -EINVAL; > @@ -92,13 +92,26 @@ static unsigned long jz_read_bat(struct power_supply > *bat_ps) > { > unsigned long val; > if (CFG_PBAT_DIV == 1) > - val = (((unsigned long long)jz_read_battery() * 7500000)) > >> 12; > + val = (((unsigned long long)jz_read_battery() * 7500000L) > >> 12) + 33000L; > else > - val = (((unsigned long long)jz_read_battery() * > CFG_PBAT_DIV * 2500000)) >> 12; > - dprintk("--raw_batter_vol=%d uV\n", val); > + val = ((unsigned long long)jz_read_battery() * CFG_PBAT_DIV > * 2500000L) >> 12; > + dev_dbg(bat_ps->dev, "%s: raw_batter_vol = %d uV\n",__func__,val); > return val; > } > > +static int jz_bat_get_capacity(struct power_supply *bat_ps) > +{ > + int ret; > + ret = (jz_read_bat(bat_ps) - JZ_BAT_MIN_VOLTAGE) * 100 > + / (JZ_BAT_MAX_VOLTAGE - JZ_BAT_MIN_VOLTAGE); > + if (ret > 100) { > + dev_warn(bat_ps->dev, "%s: capacity=%d which exceeds 100," > + "set to 100\n", __func__, ret); > + ret = 100; > + } > + return ret; > +} > + > static int jz_bat_get_property(struct power_supply *bat_ps, > enum power_supply_property psp, > union power_supply_propval *val) > @@ -111,19 +124,20 @@ static int jz_bat_get_property(struct power_supply > *bat_ps, > val->intval = POWER_SUPPLY_TECHNOLOGY_LIPO; > break; > case POWER_SUPPLY_PROP_HEALTH: > - if(jz_read_bat(bat_ps) < 3600000) { > - dprintk("--battery dead\n"); > + if(jz_read_bat(bat_ps) < JZ_BAT_MIN_VOLTAGE) { > + dev_dbg(bat_ps->dev, "%s: battery is dead," > + "voltage too low!\n", __func__); > val->intval = POWER_SUPPLY_HEALTH_DEAD; > } else { > - dprintk("--battery good\n"); > + dev_dbg(bat_ps->dev, "%s: battery is good," > + "voltage normal.\n", __func__); > val->intval = POWER_SUPPLY_HEALTH_GOOD; > } > break; > case POWER_SUPPLY_PROP_CAPACITY: > - val->intval = (jz_read_bat(bat_ps) - 3600000) * 100 / > (4200000 - 3600000); > - if (val->intval > 100) > - val->intval = 100; > - dprintk("--battery_capacity=%d\%\n",val->intval); > + val->intval = jz_bat_get_capacity(bat_ps); > + dev_dbg(bat_ps->dev, "%s: battery_capacity = %d\%\n", > + __func__, val->intval); > break; > case POWER_SUPPLY_PROP_VOLTAGE_NOW: > val->intval = jz_read_bat(bat_ps); > @@ -140,7 +154,8 @@ static int jz_bat_get_property(struct power_supply > *bat_ps, > break; > case POWER_SUPPLY_PROP_TEMP: > case POWER_SUPPLY_PROP_VOL: > - val->intval = 0; // reading TEMP and VOL aren't supported > + /* reading TEMP and VOL aren't supported */ > + val->intval = 0; > break; > default: > return -EINVAL; > @@ -174,12 +189,16 @@ static void jz_bat_update(struct power_supply > *bat_ps) > bat_status = POWER_SUPPLY_STATUS_NOT_CHARGING; > } > > - dprintk("--battery status=%s\n", status_text[bat_status]); > + dev_dbg(bat_ps->dev, "%s: battery status=%s\n", > + __func__, status_text[bat_status]); > + > if ((old_status != bat_status) || > (old_batt_vol - batt_vol > 50000)) { > - pr_debug("%s %s -> %s\n", bat_ps->name, > - status_text[old_status], > - status_text[bat_status]); > + dev_dbg(bat_ps->dev, "%s %s -> %s\n", > + bat_ps->name, > + status_text[old_status], > + status_text[bat_status]); > + > power_supply_changed(bat_ps); > } > > @@ -212,7 +231,8 @@ struct power_supply bat_ps = { > > static void jz_bat_work(struct work_struct *work) > { > - const int interval = HZ * 6; > + /* query interval too small will increase system workload*/ > + const int interval = HZ * 30; > > jz_bat_update(&bat_ps); > queue_delayed_work(monitor_wqueue, &bat_work, interval); > -- > 1.6.0.4 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kzjeef at gmail.com Fri Sep 18 14:22:57 2009 From: kzjeef at gmail.com (JieJing.Zhang) Date: Sat, 19 Sep 2009 02:22:57 +0800 Subject: [PATCH] jz battery driver cleanup Message-ID: <1253298177-8720-1-git-send-email-kzjeef@gmail.com> Signed-off-by: JieJing.Zhang --- .../xburst/files-2.6.31/drivers/power/jz_battery.c | 64 ++++++++++++-------- 1 files changed, 39 insertions(+), 25 deletions(-) diff --git a/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c b/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c index 80b3747..6f5848d 100755 --- a/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c +++ b/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c @@ -22,16 +22,10 @@ #include -#ifdef CONFIG_POWER_SUPPLY_DEBUG -#define dprintk(x...) printk(x) -#else -#define dprintk(x...) while(0){} -#endif - -#define JZ_BAT_MAX_VOLTAGE 4200000 // uV +/* uV */ +#define JZ_BAT_MAX_VOLTAGE 4200000 #define JZ_BAT_MIN_VOLTAGE 3600000 -static DEFINE_MUTEX(bat_lock); struct workqueue_struct *monitor_wqueue; struct delayed_work bat_work; struct mutex work_lock; @@ -54,7 +48,7 @@ static int jz_get_power_prop(struct power_supply *psy, if (psy->type == POWER_SUPPLY_TYPE_MAINS) val->intval = !__gpio_get_pin(GPIO_DC_DETE_N); else - val->intval = __gpio_get_pin(GPIO_USB_DETE); + val->intval = (!!__gpio_get_pin(GPIO_USB_DETE)); break; default: return -EINVAL; @@ -92,13 +86,26 @@ static unsigned long jz_read_bat(struct power_supply *bat_ps) { unsigned long val; if (CFG_PBAT_DIV == 1) - val = (((unsigned long long)jz_read_battery() * 7500000)) >> 12; + val = (((unsigned long long)jz_read_battery() * 7500000L) >> 12) + 33000L; else - val = (((unsigned long long)jz_read_battery() * CFG_PBAT_DIV * 2500000)) >> 12; - dprintk("--raw_batter_vol=%d uV\n", val); + val = ((unsigned long long)jz_read_battery() * CFG_PBAT_DIV * 2500000L) >> 12; + dev_dbg(bat_ps->dev, "%s: raw_batter_vol = %d uV\n",__func__,val); return val; } +static int jz_bat_get_capacity(struct power_supply *bat_ps) +{ + int ret; + ret = (jz_read_bat(bat_ps) - JZ_BAT_MIN_VOLTAGE) * 100 + / (JZ_BAT_MAX_VOLTAGE - JZ_BAT_MIN_VOLTAGE); + if (ret > 100) { + dev_warn(bat_ps->dev, "%s: capacity=%d which exceeds 100," + "set to 100\n", __func__, ret); + ret = 100; + } + return ret; +} + static int jz_bat_get_property(struct power_supply *bat_ps, enum power_supply_property psp, union power_supply_propval *val) @@ -111,19 +118,20 @@ static int jz_bat_get_property(struct power_supply *bat_ps, val->intval = POWER_SUPPLY_TECHNOLOGY_LIPO; break; case POWER_SUPPLY_PROP_HEALTH: - if(jz_read_bat(bat_ps) < 3600000) { - dprintk("--battery dead\n"); + if(jz_read_bat(bat_ps) < JZ_BAT_MIN_VOLTAGE) { + dev_dbg(bat_ps->dev, "%s: battery is dead," + "voltage too low!\n", __func__); val->intval = POWER_SUPPLY_HEALTH_DEAD; } else { - dprintk("--battery good\n"); + dev_dbg(bat_ps->dev, "%s: battery is good," + "voltage normal.\n", __func__); val->intval = POWER_SUPPLY_HEALTH_GOOD; } break; case POWER_SUPPLY_PROP_CAPACITY: - val->intval = (jz_read_bat(bat_ps) - 3600000) * 100 / (4200000 - 3600000); - if (val->intval > 100) - val->intval = 100; - dprintk("--battery_capacity=%d\%\n",val->intval); + val->intval = jz_bat_get_capacity(bat_ps); + dev_dbg(bat_ps->dev, "%s: battery_capacity = %d\%\n", + __func__, val->intval); break; case POWER_SUPPLY_PROP_VOLTAGE_NOW: val->intval = jz_read_bat(bat_ps); @@ -140,7 +148,8 @@ static int jz_bat_get_property(struct power_supply *bat_ps, break; case POWER_SUPPLY_PROP_TEMP: case POWER_SUPPLY_PROP_VOL: - val->intval = 0; // reading TEMP and VOL aren't supported + /* reading TEMP and VOL aren't supported */ + val->intval = 0; break; default: return -EINVAL; @@ -174,12 +183,16 @@ static void jz_bat_update(struct power_supply *bat_ps) bat_status = POWER_SUPPLY_STATUS_NOT_CHARGING; } - dprintk("--battery status=%s\n", status_text[bat_status]); + dev_dbg(bat_ps->dev, "%s: battery status=%s\n", + __func__, status_text[bat_status]); + if ((old_status != bat_status) || (old_batt_vol - batt_vol > 50000)) { - pr_debug("%s %s -> %s\n", bat_ps->name, - status_text[old_status], - status_text[bat_status]); + dev_dbg(bat_ps->dev, "%s %s -> %s\n", + bat_ps->name, + status_text[old_status], + status_text[bat_status]); + power_supply_changed(bat_ps); } @@ -212,7 +225,8 @@ struct power_supply bat_ps = { static void jz_bat_work(struct work_struct *work) { - const int interval = HZ * 6; + /* query interval too small will increase system workload*/ + const int interval = HZ * 30; jz_bat_update(&bat_ps); queue_delayed_work(monitor_wqueue, &bat_work, interval); -- 1.6.0.4 From lars at metafoo.de Fri Sep 18 14:47:04 2009 From: lars at metafoo.de (Lars-Peter Clausen) Date: Fri, 18 Sep 2009 20:47:04 +0200 Subject: [PATCH] jz battery driver cleanup In-Reply-To: <1253298177-8720-1-git-send-email-kzjeef@gmail.com> References: <1253298177-8720-1-git-send-email-kzjeef@gmail.com> Message-ID: <4AB3D5A8.8000904@metafoo.de> Hi JieJing.Zhang Thanks for taking a look at the jz battery driver. Some comments below. > Signed-off-by: JieJing.Zhang > --- > .../xburst/files-2.6.31/drivers/power/jz_battery.c | 64 ++++++++++++-------- > 1 files changed, 39 insertions(+), 25 deletions(-) > > diff --git a/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c b/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c > index 80b3747..6f5848d 100755 > --- a/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c > +++ b/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c > @@ -22,16 +22,10 @@ > > #include > > -#ifdef CONFIG_POWER_SUPPLY_DEBUG > -#define dprintk(x...) printk(x) > -#else > -#define dprintk(x...) while(0){} > -#endif > - > -#define JZ_BAT_MAX_VOLTAGE 4200000 // uV > +/* uV */ > +#define JZ_BAT_MAX_VOLTAGE 4200000 > #define JZ_BAT_MIN_VOLTAGE 3600000 > > -static DEFINE_MUTEX(bat_lock); > struct workqueue_struct *monitor_wqueue; > struct delayed_work bat_work; > struct mutex work_lock; > @@ -54,7 +48,7 @@ static int jz_get_power_prop(struct power_supply *psy, > if (psy->type == POWER_SUPPLY_TYPE_MAINS) > val->intval = !__gpio_get_pin(GPIO_DC_DETE_N); > else > - val->intval = __gpio_get_pin(GPIO_USB_DETE); > + val->intval = (!!__gpio_get_pin(GPIO_USB_DETE)); > break; > Please use the gpiolib interface (gpio_request/gpio_set_direction/gpio_set_value/gpio_free) to access gpios. The plan is to get rid of the jz specific gpio api. Also please make the gpio pins configurable via platform data. So we can let the same code run on different machines. Maybe also make min and max voltage configurable through platform data. > default: > return -EINVAL; > @@ -92,13 +86,26 @@ static unsigned long jz_read_bat(struct power_supply *bat_ps) > { > unsigned long val; > if (CFG_PBAT_DIV == 1) > - val = (((unsigned long long)jz_read_battery() * 7500000)) >> 12; > + val = (((unsigned long long)jz_read_battery() * 7500000L) >> 12) + 33000L; > else > - val = (((unsigned long long)jz_read_battery() * CFG_PBAT_DIV * 2500000)) >> 12; > - dprintk("--raw_batter_vol=%d uV\n", val); > + val = ((unsigned long long)jz_read_battery() * CFG_PBAT_DIV * 2500000L) >> 12; > + dev_dbg(bat_ps->dev, "%s: raw_batter_vol = %d uV\n",__func__,val); > return val; > } > > +static int jz_bat_get_capacity(struct power_supply *bat_ps) > +{ > + int ret; > + ret = (jz_read_bat(bat_ps) - JZ_BAT_MIN_VOLTAGE) * 100 > + / (JZ_BAT_MAX_VOLTAGE - JZ_BAT_MIN_VOLTAGE); > + if (ret > 100) { > + dev_warn(bat_ps->dev, "%s: capacity=%d which exceeds 100," > + "set to 100\n", __func__, ret); > + ret = 100; > + } > + return ret; > +} > + > static int jz_bat_get_property(struct power_supply *bat_ps, > enum power_supply_property psp, > union power_supply_propval *val) > @@ -111,19 +118,20 @@ static int jz_bat_get_property(struct power_supply *bat_ps, > val->intval = POWER_SUPPLY_TECHNOLOGY_LIPO; > break; > case POWER_SUPPLY_PROP_HEALTH: > - if(jz_read_bat(bat_ps) < 3600000) { > - dprintk("--battery dead\n"); > + if(jz_read_bat(bat_ps) < JZ_BAT_MIN_VOLTAGE) { > + dev_dbg(bat_ps->dev, "%s: battery is dead," > + "voltage too low!\n", __func__); > val->intval = POWER_SUPPLY_HEALTH_DEAD; > } else { > - dprintk("--battery good\n"); > + dev_dbg(bat_ps->dev, "%s: battery is good," > + "voltage normal.\n", __func__); > val->intval = POWER_SUPPLY_HEALTH_GOOD; > } > break; > case POWER_SUPPLY_PROP_CAPACITY: > - val->intval = (jz_read_bat(bat_ps) - 3600000) * 100 / (4200000 - 3600000); > - if (val->intval > 100) > - val->intval = 100; > - dprintk("--battery_capacity=%d\%\n",val->intval); > + val->intval = jz_bat_get_capacity(bat_ps); > + dev_dbg(bat_ps->dev, "%s: battery_capacity = %d\%\n", > + __func__, val->intval); > break; > case POWER_SUPPLY_PROP_VOLTAGE_NOW: > val->intval = jz_read_bat(bat_ps); > @@ -140,7 +148,8 @@ static int jz_bat_get_property(struct power_supply *bat_ps, > break; > case POWER_SUPPLY_PROP_TEMP: > case POWER_SUPPLY_PROP_VOL: > - val->intval = 0; // reading TEMP and VOL aren't supported > + /* reading TEMP and VOL aren't supported */ > + val->intval = 0; > break; > default: > If properties are not supported don't report them at all. > return -EINVAL; > @@ -174,12 +183,16 @@ static void jz_bat_update(struct power_supply *bat_ps) > bat_status = POWER_SUPPLY_STATUS_NOT_CHARGING; > } > > - dprintk("--battery status=%s\n", status_text[bat_status]); > + dev_dbg(bat_ps->dev, "%s: battery status=%s\n", > + __func__, status_text[bat_status]); > + > if ((old_status != bat_status) || > (old_batt_vol - batt_vol > 50000)) { > - pr_debug("%s %s -> %s\n", bat_ps->name, > - status_text[old_status], > - status_text[bat_status]); > + dev_dbg(bat_ps->dev, "%s %s -> %s\n", > + bat_ps->name, > + status_text[old_status], > + status_text[bat_status]); > + > power_supply_changed(bat_ps); > } > > @@ -212,7 +225,8 @@ struct power_supply bat_ps = { > > static void jz_bat_work(struct work_struct *work) > { > - const int interval = HZ * 6; > + /* query interval too small will increase system workload*/ > + const int interval = HZ * 30; > > jz_bat_update(&bat_ps); > queue_delayed_work(monitor_wqueue, &bat_work, interval); > From kzjeef at gmail.com Fri Sep 18 23:02:13 2009 From: kzjeef at gmail.com (ZhangJieJing) Date: Sat, 19 Sep 2009 11:02:13 +0800 Subject: projects.qi-hardware.com git repo read Permission. Message-ID: Hi all, For now, the projects.qi-hardware.com 's only can use ssh+git, and only one public key can add into the user's profile, I always have to work on two place, home and office. But if one computer without add public key into my profile, I even can't checkout source read only. my suggestion is: For an open project, I think we'd better open read only for anonymous, what are you think ? --- Best regards, Zhang Jiejing -------------- next part -------------- An HTML attachment was scrubbed... URL: From wolfgang at qi-hardware.com Fri Sep 18 23:42:11 2009 From: wolfgang at qi-hardware.com (Wolfgang Spraul) Date: Fri, 18 Sep 2009 23:42:11 -0400 Subject: projects.qi-hardware.com git repo read Permission. In-Reply-To: References: Message-ID: <20090919034211.GA9436@debian> Zhang Jiejing, yes definitely, anonymous read access has to work! :-) There are two ways you can access any sources code on projects: 1. Authenticated, read-write git clone git at projects.qi-hardware.com:_project-name_.git 2. Anonymous, read-only git clone git://projects.qi-hardware.com/_project-name_.git Currently this is not well documented, it should be more obvious right on the projects homepage. Please let me know if the anonymous access doesn't work, I just tested and it works here. You are also right about the limitation of only 1 public key per account. One workaround would be to register a second user. Another one would be to use the same private key (identity file) on both of your machines. Depends on whether you want the identity to represent you (a person), or your computer. I don't think InDefero will add a feature of having multiple public keys per account soon, but going upstream with this request would be another option. Wolfgang On Sat, Sep 19, 2009 at 11:02:13AM +0800, ZhangJieJing wrote: > Hi all, > > For now, the projects.qi-hardware.com 's only can use ssh+git, and only one > public key can add into the user's profile, > I always have to work on two place, home and office. > > But if one computer without add public key into my profile, I even can't > checkout source read only. > > my suggestion is: > For an open project, I think we'd better open read only for anonymous, what > are you think ? > --- > Best regards, > Zhang Jiejing > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer From kzjeef at gmail.com Sat Sep 19 01:42:22 2009 From: kzjeef at gmail.com (ZhangJieJing) Date: Sat, 19 Sep 2009 13:42:22 +0800 Subject: projects.qi-hardware.com git repo read Permission. In-Reply-To: <20090919034211.GA9436@debian> References: <20090919034211.GA9436@debian> Message-ID: Wolfgang, I think for anonymous access can add some description at source page -> How To Get The Codesection add some line like git clone git://url Like this. The team behind OpenWrt XBurst is using the *git* software to manage the source code. Command-Line Access 1. Authenticated, read-write git clone git at projects.qi-hardware.com:openwrt-xburst.git 2. Anonymous, read-only git clone git://projects.qi-hardware.com/openwrt-xburst.git You may need to provide your SSH key. The synchronization of your SSH key can take a couple of minutes. You can learn more about SSH key authentification . --- Best regards, Zhang Jiejing On Sat, Sep 19, 2009 at 11:42 AM, Wolfgang Spraul wrote: > Zhang Jiejing, > yes definitely, anonymous read access has to work! :-) > There are two ways you can access any sources code on projects: > > 1. Authenticated, read-write > git clone git at projects.qi-hardware.com:_project-name_.git > > 2. Anonymous, read-only > git clone git://projects.qi-hardware.com/_project-name_.git > > Currently this is not well documented, it should be more obvious right on > the projects homepage. > Please let me know if the anonymous access doesn't work, I just tested and > it works here. > > You are also right about the limitation of only 1 public key per account. > One workaround would be to register a second user. > Another one would be to use the same private key (identity file) on both > of your machines. Depends on whether you want the identity to represent > you (a person), or your computer. > I don't think InDefero will add a feature of having multiple public keys > per account soon, but going upstream with this request would be another > option. > > Wolfgang > > On Sat, Sep 19, 2009 at 11:02:13AM +0800, ZhangJieJing wrote: > > Hi all, > > > > For now, the projects.qi-hardware.com 's only can use ssh+git, and only > one > > public key can add into the user's profile, > > I always have to work on two place, home and office. > > > > But if one computer without add public key into my profile, I even can't > > checkout source read only. > > > > my suggestion is: > > For an open project, I think we'd better open read only for anonymous, > what > > are you think ? > > --- > > Best regards, > > Zhang Jiejing > > > _______________________________________________ > > Qi Developer Mailing List > > Mail to list (members only): developer at lists.qi-hardware.com > > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kzjeef at gmail.com Sat Sep 19 14:46:46 2009 From: kzjeef at gmail.com (JieJing.Zhang) Date: Sun, 20 Sep 2009 02:46:46 +0800 Subject: [PATCH] jz battery driver cleanup Message-ID: <1253386006-19505-1-git-send-email-kzjeef@gmail.com> This patch is cleanup more about gpio and platform data. I don't test in board. But I noticed that qi_lb60.c also have set gpio as input, and the jz_battey do same by gpiolib, Is that cause problem? Signed-off-by: JieJing.Zhang --- .../files-2.6.31/arch/mips/jz4740/platform.c | 23 +++ .../xburst/files-2.6.31/drivers/power/jz_battery.c | 152 ++++++++++++++------ .../files-2.6.31/include/linux/jz4740_batt.h | 27 ++++ .../xburst/files-2.6.31/include/linux/jz4740_fb.h | 5 + 4 files changed, 164 insertions(+), 43 deletions(-) create mode 100644 target/linux/xburst/files-2.6.31/include/linux/jz4740_batt.h diff --git a/target/linux/xburst/files-2.6.31/arch/mips/jz4740/platform.c b/target/linux/xburst/files-2.6.31/arch/mips/jz4740/platform.c index db3d045..b75ddde 100644 --- a/target/linux/xburst/files-2.6.31/arch/mips/jz4740/platform.c +++ b/target/linux/xburst/files-2.6.31/arch/mips/jz4740/platform.c @@ -19,6 +19,8 @@ #include #include #include +#include +#include #include #include @@ -408,6 +410,26 @@ static struct platform_device jz_codec_device = { .resource = codec_resources, }; +#define JZ_BAT_MAX_VOLTAGE 4200000 +#define JZ_BAT_MIN_VOLTAGE 3600000 +static struct jz_batt_info jz_batt_gpio_platform_data = { + .dc_dect_gpio = GPIO_DC_DETE_N, + .usb_dect_gpio = GPIO_USB_DETE, + .charg_stat_gpio = GPIO_CHARG_STAT_N, + + .min_voltag = JZ_BAT_MIN_VOLTAGE, + .max_voltag = JZ_BAT_MAX_VOLTAGE, + .batt_tech = POWER_SUPPLY_TECHNOLOGY_LIPO, +}; + +static struct platform_device batt_gpio_device = { + .name = "batt_gpio", + .id = -1, + .dev = { + .platform_data = &jz_batt_gpio_platform_data, + }, +}; + /* All */ static struct platform_device *jz_platform_devices[] __initdata = { &jz_usb_ohci_device, @@ -420,6 +442,7 @@ static struct platform_device *jz_platform_devices[] __initdata = { &qi_lb60_fb, &jz_i2s_device, &jz_codec_device, + &batt_gpio_device, }; static int __init jz_platform_init(void) diff --git a/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c b/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c index 80b3747..f9ef04f 100755 --- a/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c +++ b/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c @@ -6,6 +6,7 @@ * based on tosa_battery.c * * Copyright (C) 2008 Marek Vasut + * Copyright (C) 2009 Jiejing Zhang * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as @@ -19,28 +20,19 @@ #include #include #include +#include #include -#ifdef CONFIG_POWER_SUPPLY_DEBUG -#define dprintk(x...) printk(x) -#else -#define dprintk(x...) while(0){} -#endif - -#define JZ_BAT_MAX_VOLTAGE 4200000 // uV -#define JZ_BAT_MIN_VOLTAGE 3600000 - -static DEFINE_MUTEX(bat_lock); struct workqueue_struct *monitor_wqueue; struct delayed_work bat_work; struct mutex work_lock; -int bat_status = POWER_SUPPLY_STATUS_DISCHARGING; +static int bat_status = POWER_SUPPLY_STATUS_DISCHARGING; +static struct jz_batt_info *pdata = 0; extern unsigned int jz_read_battery(void); - /********************************************************************* * Power *********************************************************************/ @@ -52,9 +44,9 @@ static int jz_get_power_prop(struct power_supply *psy, switch (psp) { case POWER_SUPPLY_PROP_ONLINE: if (psy->type == POWER_SUPPLY_TYPE_MAINS) - val->intval = !__gpio_get_pin(GPIO_DC_DETE_N); + val->intval = !gpio_get_value(pdata->dc_dect_gpio); else - val->intval = __gpio_get_pin(GPIO_USB_DETE); + val->intval = !!gpio_get_value(pdata->usb_dect_gpio); break; default: return -EINVAL; @@ -92,13 +84,26 @@ static unsigned long jz_read_bat(struct power_supply *bat_ps) { unsigned long val; if (CFG_PBAT_DIV == 1) - val = (((unsigned long long)jz_read_battery() * 7500000)) >> 12; + val = (((unsigned long long)jz_read_battery() * 7500000L) >> 12) + 33000L; else - val = (((unsigned long long)jz_read_battery() * CFG_PBAT_DIV * 2500000)) >> 12; - dprintk("--raw_batter_vol=%d uV\n", val); + val = ((unsigned long long)jz_read_battery() * CFG_PBAT_DIV * 2500000L) >> 12; + dev_dbg(bat_ps->dev, "%s: raw_batter_vol = %d uV\n",__func__,val); return val; } +static int jz_bat_get_capacity(struct power_supply *bat_ps) +{ + int ret; + ret = (jz_read_bat(bat_ps) - pdata->min_voltag) * 100 + / (pdata->max_voltag - pdata->min_voltag); + if (ret > 100) { + dev_warn(bat_ps->dev, "%s: capacity=%d which exceeds 100," + "set to 100\n", __func__, ret); + ret = 100; + } + return ret; +} + static int jz_bat_get_property(struct power_supply *bat_ps, enum power_supply_property psp, union power_supply_propval *val) @@ -108,40 +113,37 @@ static int jz_bat_get_property(struct power_supply *bat_ps, val->intval = bat_status; break; case POWER_SUPPLY_PROP_TECHNOLOGY: - val->intval = POWER_SUPPLY_TECHNOLOGY_LIPO; + val->intval = pdata->batt_tech; break; case POWER_SUPPLY_PROP_HEALTH: - if(jz_read_bat(bat_ps) < 3600000) { - dprintk("--battery dead\n"); + if(jz_read_bat(bat_ps) < JZ_BAT_MIN_VOLTAGE) { + dev_dbg(bat_ps->dev, "%s: battery is dead," + "voltage too low!\n", __func__); val->intval = POWER_SUPPLY_HEALTH_DEAD; } else { - dprintk("--battery good\n"); + dev_dbg(bat_ps->dev, "%s: battery is good," + "voltage normal.\n", __func__); val->intval = POWER_SUPPLY_HEALTH_GOOD; } break; case POWER_SUPPLY_PROP_CAPACITY: - val->intval = (jz_read_bat(bat_ps) - 3600000) * 100 / (4200000 - 3600000); - if (val->intval > 100) - val->intval = 100; - dprintk("--battery_capacity=%d\%\n",val->intval); + val->intval = jz_bat_get_capacity(bat_ps); + dev_dbg(bat_ps->dev, "%s: battery_capacity = %d\%\n", + __func__, val->intval); break; case POWER_SUPPLY_PROP_VOLTAGE_NOW: val->intval = jz_read_bat(bat_ps); break; case POWER_SUPPLY_PROP_VOLTAGE_MAX: case POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN: - val->intval = JZ_BAT_MAX_VOLTAGE; + val->intval = pdata->max_voltag; break; case POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN: - val->intval = JZ_BAT_MIN_VOLTAGE; + val->intval = pdata->min_voltag; break; case POWER_SUPPLY_PROP_PRESENT: val->intval = 1; break; - case POWER_SUPPLY_PROP_TEMP: - case POWER_SUPPLY_PROP_VOL: - val->intval = 0; // reading TEMP and VOL aren't supported - break; default: return -EINVAL; } @@ -168,18 +170,21 @@ static void jz_bat_update(struct power_supply *bat_ps) unsigned long batt_vol = jz_read_bat(bat_ps); mutex_lock(&work_lock); - if(!__gpio_get_pin(GPIO_CHARG_STAT_N)) + if(!gpio_get_value(pdata->charg_stat_pgio)) bat_status = POWER_SUPPLY_STATUS_CHARGING; - else { + else bat_status = POWER_SUPPLY_STATUS_NOT_CHARGING; - } - dprintk("--battery status=%s\n", status_text[bat_status]); + dev_dbg(bat_ps->dev, "%s: battery status=%s\n", + __func__, status_text[bat_status]); + if ((old_status != bat_status) || (old_batt_vol - batt_vol > 50000)) { - pr_debug("%s %s -> %s\n", bat_ps->name, - status_text[old_status], - status_text[bat_status]); + dev_dbg(bat_ps->dev, "%s %s -> %s\n", + bat_ps->name, + status_text[old_status], + status_text[bat_status]); + power_supply_changed(bat_ps); } @@ -196,8 +201,6 @@ static enum power_supply_property jz_bat_main_props[] = { POWER_SUPPLY_PROP_VOLTAGE_MAX, POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN, POWER_SUPPLY_PROP_PRESENT, - POWER_SUPPLY_PROP_TEMP, - POWER_SUPPLY_PROP_VOL, }; struct power_supply bat_ps = { @@ -212,7 +215,8 @@ struct power_supply bat_ps = { static void jz_bat_work(struct work_struct *work) { - const int interval = HZ * 6; + /* query interval too small will increase system workload*/ + const int interval = HZ * 30; jz_bat_update(&bat_ps); queue_delayed_work(monitor_wqueue, &bat_work, interval); @@ -242,12 +246,47 @@ static int jz_bat_resume(struct platform_device *dev) static int __devinit jz_bat_probe(struct platform_device *dev) { int ret = 0; + printk("JZ battery init.\n"); mutex_init(&work_lock); - INIT_DELAYED_WORK(&bat_work, jz_bat_work); - __gpio_disable_pull(GPIO_USB_DETE); + if (!dev->dev->platform_data) { + dev_error(&dev->dev, "Please set battery info\n"); + return -EINVAL; + } + + pdata = dev->dev->platform_data; + + if (pdata->dc_dect_gpio >= 0 && gpio_is_valid(pdata->dc_dect_gpio)) { + ret = gpio_request(pdata->dc_dect_gpio, "AC/DC DECT"); + if (ret) + goto err_dc_gpio_request; + ret = gpio_direction_input(pdata->dc_dect_gpio); + if (ret) + goto err_dc_gpio_direction; + } + + if (pdata->usb_dect_gpio >= 0 && gpio_is_valid(pdata->usb_dect_gpio)) { + ret = gpio_request(pdata->usb_dect_gpio, "USB DECT"); + if (ret) + goto err_usb_gpio_request; + ret = gpio_direction_input(pdata->usb_dect_gpio); + if (ret) + goto err_usb_gpio_direction; + + jz_gpio_disable_pullup(pdata->usb_dect_gpio); + /* TODO: Use generic gpio is better */ + } + + if (pdata->charg_stat_gpio >= 0 && gpio_is_valid(pdata->charg_stat_gpio)) { + ret = gpio_request(pdata->charg_stat_gpio, "CHARG STAT"); + if (ret) + goto err_charg_gpio_request; + ret = gpio_direction_input(pdata->charg_stat_pgio); + if (ret) + goto err_charg_gpio_direction; + } power_supply_register(&dev->dev, &jz_ac); power_supply_register(&dev->dev, &jz_usb); @@ -262,10 +301,37 @@ static int __devinit jz_bat_probe(struct platform_device *dev) } return ret; + +err_charg_gpio_direction + dev_err(dev->dev, "charger state gpio set direction failed.\n"); + gpio_free(pdata->charg_stat_pgio); +err_charg_gpio_request: + dev_err(dev->dev, "charger state gpio request failed.\n"); +err_usb_gpio_direction: + dev_err(dev->dev, "usb dect gpio set direction failed.\n"); + gpio_free(pdata->usb_dect_gpio); +err_usb_gpio_request: + dev_err(dev->dev, "usb dect gpio request failed.\n"); +err_dc_gpio_direction: + dev_err(dev->dev, "ac/dc dect gpio request failed.\n"); + gpio_free(pdata->dc_dect_gpio); +err_err_dc_gpio_request: + dev_err(dev->dev, "ac/dc dect gpio request failed.\n"); + return ret; + } static int __devexit jz_bat_remove(struct platform_device *dev) { + if (pdata) { + if (pdata->dc_dect_gpio >= 0) + gpio_free(pdata->dc_dect_gpio); + if (pdata->usb_dect_gpio >= 0) + gpio_free(pdata->usb_dect_pgio); + if (pdata->charg_stat_gpio >= 0) + gpio_free(pdata->charg_stat_gpio); + } + power_supply_unregister(&bat_ps); return 0; } diff --git a/target/linux/xburst/files-2.6.31/include/linux/jz4740_batt.h b/target/linux/xburst/files-2.6.31/include/linux/jz4740_batt.h new file mode 100644 index 0000000..bef9412 --- /dev/null +++ b/target/linux/xburst/files-2.6.31/include/linux/jz4740_batt.h @@ -0,0 +1,27 @@ +/* + * Copyright (C) 2009, Jiejing Zhang + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write to the Free Software Foundation, Inc., + * 675 Mass Ave, Cambridge, MA 02139, USA. + * + */ + +#ifndef JZ4740_BATT_H +#define JZ4740_BATT_H + +struct jz_batt_info { + int dc_dect_gpio; /* GPIO port of DC charger detection */ + int usb_dect_gpio; /* GPIO port of USB charger detection */ + int charg_stat_gpio; /* GPIO port of Charger state */ + + int min_voltag; /* Mininal battery voltage in uV */ + int max_voltag; /* Maximum battery voltage in uV */ + int batt_tech; /* Battery technoledge */ +}; +#endif diff --git a/target/linux/xburst/files-2.6.31/include/linux/jz4740_fb.h b/target/linux/xburst/files-2.6.31/include/linux/jz4740_fb.h index 778e1e9..50a89ff 100644 --- a/target/linux/xburst/files-2.6.31/include/linux/jz4740_fb.h +++ b/target/linux/xburst/files-2.6.31/include/linux/jz4740_fb.h @@ -12,6 +12,9 @@ * */ +#ifndef JZ4740_FB_H +#define JZ4740_FB_H + #include enum jz4740_fb_lcd_type { @@ -45,3 +48,5 @@ struct jz4740_fb_platform_data { int bpp; enum jz4740_fb_lcd_type lcd_type; }; + +#endif -- 1.6.0.4 From lars at metafoo.de Sat Sep 19 16:19:40 2009 From: lars at metafoo.de (Lars-Peter Clausen) Date: Sat, 19 Sep 2009 22:19:40 +0200 Subject: [PATCH] jz battery driver cleanup In-Reply-To: <1253386006-19505-1-git-send-email-kzjeef@gmail.com> References: <1253386006-19505-1-git-send-email-kzjeef@gmail.com> Message-ID: <4AB53CDC.1060601@metafoo.de> Hi JieJing.Zhang looks good already :) I commited the last part of your patch (the include guards for the jz4740_fb.h) Some more commtens for the battery driver: > This patch is cleanup more about gpio and platform data. I don't > test in board. But I noticed that qi_lb60.c also have set gpio as > input, and the jz_battey do same by gpiolib, Is that cause problem? > The gpio code in board_qi_lb60.c should go away. > > > Signed-off-by: JieJing.Zhang --- > .../files-2.6.31/arch/mips/jz4740/platform.c | 23 +++ > .../xburst/files-2.6.31/drivers/power/jz_battery.c | 152 > ++++++++++++++------ .../files-2.6.31/include/linux/jz4740_batt.h > | 27 ++++ .../xburst/files-2.6.31/include/linux/jz4740_fb.h | > 5 + 4 files changed, 164 insertions(+), 43 deletions(-) create mode > 100644 target/linux/xburst/files-2.6.31/include/linux/jz4740_batt.h > > > diff --git > a/target/linux/xburst/files-2.6.31/arch/mips/jz4740/platform.c > b/target/linux/xburst/files-2.6.31/arch/mips/jz4740/platform.c > index db3d045..b75ddde 100644 --- > a/target/linux/xburst/files-2.6.31/arch/mips/jz4740/platform.c +++ > b/target/linux/xburst/files-2.6.31/arch/mips/jz4740/platform.c @@ > -19,6 +19,8 @@ #include #include > #include +#include > +#include > > #include #include @@ -408,6 +410,26 @@ > static struct platform_device jz_codec_device = { .resource = > codec_resources, }; > > +#define JZ_BAT_MAX_VOLTAGE 4200000 +#define JZ_BAT_MIN_VOLTAGE > 3600000 +static struct jz_batt_info jz_batt_gpio_platform_data = { > + .dc_dect_gpio = GPIO_DC_DETE_N, + .usb_dect_gpio = GPIO_USB_DETE, > + .charg_stat_gpio = GPIO_CHARG_STAT_N, + + .min_voltag = > JZ_BAT_MIN_VOLTAGE, + .max_voltag = JZ_BAT_MAX_VOLTAGE, + > .batt_tech = POWER_SUPPLY_TECHNOLOGY_LIPO, +}; + +static struct > platform_device batt_gpio_device = { + .name = "batt_gpio", + .id = > -1, + .dev = { + .platform_data = &jz_batt_gpio_platform_data, + > }, +}; + /* All */ static struct platform_device > *jz_platform_devices[] __initdata = { &jz_usb_ohci_device, @@ > -420,6 +442,7 @@ static struct platform_device > *jz_platform_devices[] __initdata = { &qi_lb60_fb, &jz_i2s_device, > &jz_codec_device, + &batt_gpio_device, }; > > static int __init jz_platform_init(void) diff --git > a/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c > b/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c index > 80b3747..f9ef04f 100755 --- > a/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c +++ > b/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c @@ > -6,6 +6,7 @@ * based on tosa_battery.c * * Copyright (C) 2008 Marek > Vasut + * Copyright (C) 2009 Jiejing Zhang > * * This program is free software; you can > redistribute it and/or modify * it under the terms of the GNU > General Public License version 2 as @@ -19,28 +20,19 @@ #include > #include #include > +#include > > #include > > -#ifdef CONFIG_POWER_SUPPLY_DEBUG -#define dprintk(x...) printk(x) > -#else -#define dprintk(x...) while(0){} -#endif - -#define > JZ_BAT_MAX_VOLTAGE 4200000 // uV -#define JZ_BAT_MIN_VOLTAGE > 3600000 - -static DEFINE_MUTEX(bat_lock); struct workqueue_struct > *monitor_wqueue; struct delayed_work bat_work; struct mutex > work_lock; > > -int bat_status = POWER_SUPPLY_STATUS_DISCHARGING; +static int > bat_status = POWER_SUPPLY_STATUS_DISCHARGING; +static struct > jz_batt_info *pdata = 0; > > extern unsigned int jz_read_battery(void); > > - > /********************************************************************* > * Power > *********************************************************************/ > @@ -52,9 +44,9 @@ static int jz_get_power_prop(struct power_supply > *psy, switch (psp) { case POWER_SUPPLY_PROP_ONLINE: if (psy->type > == POWER_SUPPLY_TYPE_MAINS) - val->intval = > !__gpio_get_pin(GPIO_DC_DETE_N); + val->intval = > !gpio_get_value(pdata->dc_dect_gpio); else - val->intval = > __gpio_get_pin(GPIO_USB_DETE); + val->intval = > !!gpio_get_value(pdata->usb_dect_gpio); break; default: return > -EINVAL; @@ -92,13 +84,26 @@ static unsigned long > jz_read_bat(struct power_supply *bat_ps) { unsigned long val; if > (CFG_PBAT_DIV == 1) - val = (((unsigned long > long)jz_read_battery() * 7500000)) >> 12; + val = (((unsigned long > long)jz_read_battery() * 7500000L) >> 12) + 33000L; else - val = > (((unsigned long long)jz_read_battery() * CFG_PBAT_DIV * 2500000)) > >> 12; - dprintk("--raw_batter_vol=%d uV\n", val); + val = > ((unsigned long long)jz_read_battery() * CFG_PBAT_DIV * 2500000L) > >> 12; + dev_dbg(bat_ps->dev, "%s: raw_batter_vol = %d > uV\n",__func__,val); return val; } > > +static int jz_bat_get_capacity(struct power_supply *bat_ps) +{ + > int ret; + ret = (jz_read_bat(bat_ps) - pdata->min_voltag) * 100 + > / (pdata->max_voltag - pdata->min_voltag); + if (ret > 100) { + > dev_warn(bat_ps->dev, "%s: capacity=%d which exceeds 100," + > "set to 100\n", __func__, ret); + ret = 100; + } + return ret; +} > + static int jz_bat_get_property(struct power_supply *bat_ps, enum > power_supply_property psp, union power_supply_propval *val) @@ > -108,40 +113,37 @@ static int jz_bat_get_property(struct > power_supply *bat_ps, val->intval = bat_status; break; case > POWER_SUPPLY_PROP_TECHNOLOGY: - val->intval = > POWER_SUPPLY_TECHNOLOGY_LIPO; + val->intval = pdata->batt_tech; > break; case POWER_SUPPLY_PROP_HEALTH: - if(jz_read_bat(bat_ps) < > 3600000) { - dprintk("--battery dead\n"); + > if(jz_read_bat(bat_ps) < JZ_BAT_MIN_VOLTAGE) { + > dev_dbg(bat_ps->dev, "%s: battery is dead," + "voltage too > low!\n", __func__); val->intval = POWER_SUPPLY_HEALTH_DEAD; } else > { - dprintk("--battery good\n"); + dev_dbg(bat_ps->dev, "%s: > battery is good," + "voltage normal.\n", __func__); val->intval > = POWER_SUPPLY_HEALTH_GOOD; } break; case > POWER_SUPPLY_PROP_CAPACITY: - val->intval = (jz_read_bat(bat_ps) - > 3600000) * 100 / (4200000 - 3600000); - if (val->intval > 100) - > val->intval = 100; - > dprintk("--battery_capacity=%d\%\n",val->intval); + val->intval = > jz_bat_get_capacity(bat_ps); + dev_dbg(bat_ps->dev, "%s: > battery_capacity = %d\%\n", + __func__, val->intval); break; case > POWER_SUPPLY_PROP_VOLTAGE_NOW: val->intval = jz_read_bat(bat_ps); > break; case POWER_SUPPLY_PROP_VOLTAGE_MAX: case > POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN: - val->intval = > JZ_BAT_MAX_VOLTAGE; + val->intval = pdata->max_voltag; break; case > POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN: - val->intval = > JZ_BAT_MIN_VOLTAGE; + val->intval = pdata->min_voltag; break; case > POWER_SUPPLY_PROP_PRESENT: val->intval = 1; break; - case > POWER_SUPPLY_PROP_TEMP: - case POWER_SUPPLY_PROP_VOL: - > val->intval = 0; // reading TEMP and VOL aren't supported - break; > default: return -EINVAL; } @@ -168,18 +170,21 @@ static void > jz_bat_update(struct power_supply *bat_ps) unsigned long batt_vol = > jz_read_bat(bat_ps); mutex_lock(&work_lock); > > - if(!__gpio_get_pin(GPIO_CHARG_STAT_N)) + > if(!gpio_get_value(pdata->charg_stat_pgio)) bat_status = > POWER_SUPPLY_STATUS_CHARGING; - else { + else bat_status = > POWER_SUPPLY_STATUS_NOT_CHARGING; - } > > - dprintk("--battery status=%s\n", status_text[bat_status]); + > dev_dbg(bat_ps->dev, "%s: battery status=%s\n", + __func__, > status_text[bat_status]); + if ((old_status != bat_status) || > (old_batt_vol - batt_vol > 50000)) { - pr_debug("%s %s -> %s\n", > bat_ps->name, - status_text[old_status], - > status_text[bat_status]); + dev_dbg(bat_ps->dev, "%s %s -> %s\n", > + bat_ps->name, + status_text[old_status], + > status_text[bat_status]); + power_supply_changed(bat_ps); } > > @@ -196,8 +201,6 @@ static enum power_supply_property > jz_bat_main_props[] = { POWER_SUPPLY_PROP_VOLTAGE_MAX, > POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN, POWER_SUPPLY_PROP_PRESENT, - > POWER_SUPPLY_PROP_TEMP, - POWER_SUPPLY_PROP_VOL, }; > > struct power_supply bat_ps = { @@ -212,7 +215,8 @@ struct > power_supply bat_ps = { > > static void jz_bat_work(struct work_struct *work) { - const int > interval = HZ * 6; + /* query interval too small will increase > system workload*/ + const int interval = HZ * 30; > > jz_bat_update(&bat_ps); queue_delayed_work(monitor_wqueue, > &bat_work, interval); @@ -242,12 +246,47 @@ static int > jz_bat_resume(struct platform_device *dev) static int __devinit > jz_bat_probe(struct platform_device *dev) { int ret = 0; + > printk("JZ battery init.\n"); mutex_init(&work_lock); - > INIT_DELAYED_WORK(&bat_work, jz_bat_work); > > - __gpio_disable_pull(GPIO_USB_DETE); + if > (!dev->dev->platform_data) { + dev_error(&dev->dev, "Please set > battery info\n"); + return -EINVAL; + } + + pdata = > dev->dev->platform_data; + + if (pdata->dc_dect_gpio >= 0 && > gpio_is_valid(pdata->dc_dect_gpio)) { gpio_is_valid checks if the gpio is non negative. So its enough to check gpio_is_valid > > + ret = gpio_request(pdata->dc_dect_gpio, "AC/DC DECT"); + if > (ret) + goto err_dc_gpio_request; + ret = > gpio_direction_input(pdata->dc_dect_gpio); + if (ret) + goto > err_dc_gpio_direction; + } + + if (pdata->usb_dect_gpio >= 0 && > gpio_is_valid(pdata->usb_dect_gpio)) { dito > > + ret = gpio_request(pdata->usb_dect_gpio, "USB DECT"); + if > (ret) + goto err_usb_gpio_request; + ret = > gpio_direction_input(pdata->usb_dect_gpio); + if (ret) + goto > err_usb_gpio_direction; + + > jz_gpio_disable_pullup(pdata->usb_dect_gpio); + /* TODO: Use > generic gpio is better */ + } + + if (pdata->charg_stat_gpio >= 0 > && gpio_is_valid(pdata->charg_stat_gpio)) { dito > > + ret = gpio_request(pdata->charg_stat_gpio, "CHARG STAT"); + if > (ret) + goto err_charg_gpio_request; + ret = > gpio_direction_input(pdata->charg_stat_pgio); + if (ret) + goto > err_charg_gpio_direction; + } > > power_supply_register(&dev->dev, &jz_ac); > power_supply_register(&dev->dev, &jz_usb); power_supply_register can fail. Please check its return value and unregister already registered power supplies if one fails. > > @@ -262,10 +301,37 @@ static int __devinit jz_bat_probe(struct > platform_device *dev) } > > return ret; + +err_charg_gpio_direction + dev_err(dev->dev, > "charger state gpio set direction failed.\n"); The error message should be not be printed here. If setting direction for the charge gpio you'll see all following error messages aswell. The error messages should be printed before you goto the error label. > > + gpio_free(pdata->charg_stat_pgio); +err_charg_gpio_request: + > dev_err(dev->dev, "charger state gpio request failed.\n"); > +err_usb_gpio_direction: + dev_err(dev->dev, "usb dect gpio set > direction failed.\n"); + gpio_free(pdata->usb_dect_gpio); > +err_usb_gpio_request: + dev_err(dev->dev, "usb dect gpio request > failed.\n"); +err_dc_gpio_direction: + dev_err(dev->dev, "ac/dc > dect gpio request failed.\n"); + gpio_free(pdata->dc_dect_gpio); > +err_err_dc_gpio_request: + dev_err(dev->dev, "ac/dc dect gpio > request failed.\n"); + return ret; + } > > static int __devexit jz_bat_remove(struct platform_device *dev) { + > if (pdata) { + if (pdata->dc_dect_gpio >= 0) Use gpio_is_valid > > + gpio_free(pdata->dc_dect_gpio); + if > (pdata->usb_dect_gpio >= 0) dito > > + gpio_free(pdata->usb_dect_pgio); + if > (pdata->charg_stat_gpio >= 0) dito > > + gpio_free(pdata->charg_stat_gpio); + } + > power_supply_unregister(&bat_ps); The other power supplies should be unregistered aswell > > return 0; } diff --git > a/target/linux/xburst/files-2.6.31/include/linux/jz4740_batt.h > b/target/linux/xburst/files-2.6.31/include/linux/jz4740_batt.h new > file mode 100644 index 0000000..bef9412 --- /dev/null +++ > b/target/linux/xburst/files-2.6.31/include/linux/jz4740_batt.h @@ > -0,0 +1,27 @@ +/* + * Copyright (C) 2009, Jiejing Zhang > + * + * This program is free software; you can > redistribute it and/or modify it + * under the terms of the GNU > General Public License as published by the + * Free Software > Foundation; either version 2 of the License, or (at your + * > option) any later version. + * + * You should have received a copy > of the GNU General Public License along + * with this program; if > not, write to the Free Software Foundation, Inc., + * 675 Mass > Ave, Cambridge, MA 02139, USA. + * + */ + +#ifndef JZ4740_BATT_H > +#define JZ4740_BATT_H + +struct jz_batt_info { + int dc_dect_gpio; > /* GPIO port of DC charger detection */ + int usb_dect_gpio; /* > GPIO port of USB charger detection */ + int charg_stat_gpio; /* > GPIO port of Charger state */ + + int min_voltag; /* Mininal > battery voltage in uV */ + int max_voltag; /* Maximum battery > voltage in uV */ + int batt_tech; /* Battery technoledge */ +}; > +#endif From xiangfu at qi-hardware.com Sun Sep 20 00:08:01 2009 From: xiangfu at qi-hardware.com (Xiangfu Liu) Date: Sun, 20 Sep 2009 12:08:01 +0800 Subject: kernel tree repos Message-ID: <4AB5AAA1.6070007@qi-hardware.com> Hi from talk with Carlos, we decide setup a qi-kernel[1] repos in projects.qi-hardware.com this kernel repos will sync with the openwrt-xburst's kernel. since we focus on the openwrt. we just want maintain the openwrt-xburst, then I think make this repos *read_only*. I will try to sync with openwrt-xburst kernel when the openwrt-xburst kernel update. as Jiejing Zhange did. we can send kernel patch to the mailing list. next step we will apply them to the openwrt-xburst. Hi Jiejing Zhange we delete the kzjeef-kernel repos for less confuse. since it's very old code. what do you think? [1] http://projects.qi-hardware.com/index.php/p/qi-kernel/source/help/ I use the two shell to create the kernel repos from openwrt-xburst patch. attach is the shell. -------------- next part -------------- A non-text attachment was scrubbed... Name: create-openwrt-kernel.git.sh Type: application/x-sh Size: 726 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-kernel.sh Type: application/x-sh Size: 1625 bytes Desc: not available URL: From kzjeef at gmail.com Sun Sep 20 09:03:48 2009 From: kzjeef at gmail.com (ZhangJieJing) Date: Sun, 20 Sep 2009 21:03:48 +0800 Subject: kernel tree repos In-Reply-To: <4AB5AAA1.6070007@qi-hardware.com> References: <4AB5AAA1.6070007@qi-hardware.com> Message-ID: Hi, xiangfu delete the my kernel tree, it's ok, For now, I'm just using openwrt repo for development. --- Best regards, Zhang Jiejing On Sun, Sep 20, 2009 at 12:08 PM, Xiangfu Liu wrote: > Hi > > from talk with Carlos, we decide setup a qi-kernel[1] repos in > projects.qi-hardware.com > this kernel repos will sync with the openwrt-xburst's kernel. > since we focus on the openwrt. we just want maintain the > openwrt-xburst, then I think make this repos *read_only*. > I will try to sync with openwrt-xburst kernel when > the openwrt-xburst kernel update. > > as Jiejing Zhange did. we can send kernel patch to the mailing > list. next step we will apply them to the openwrt-xburst. > > Hi Jiejing Zhange > we delete the kzjeef-kernel repos for less confuse. since > it's very old code. what do you think? > > [1] http://projects.qi-hardware.com/index.php/p/qi-kernel/source/help/ > > I use the two shell to create the kernel repos from openwrt-xburst patch. > attach is the shell. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at nanl.de Sun Sep 20 18:44:26 2009 From: lists at nanl.de (Mirko Vogt) Date: Mon, 21 Sep 2009 00:44:26 +0200 Subject: some more updates from the software part Message-ID: <1253486666.11044.886.camel@mia> Hey! As Wolfgang is doing since the beginning, from now on I also will try to summarize what's going on "behind the scenes" (the software-/OpenWrt-part) in weekly updates. So let's see what happened last days: USB-Ethernet-Gadget is working. You're now able to speak ethernet, and therefore IP, to your Ben Nanonote via USB. That's really cool, because now all the network-stuff can be used which simplifies lot's of things (e.g. SSH into the NanoNote, copying files, etc.) Lars found out the used NAND-chip is a multilevel-chip that has to be treated by the flash-tools in a special way which should fix most of our previous ECC-NAND-chip-problems. OpenZIM, an opensource implementation for handling ZIM-files which mainly provide wiki-articles (e.g. the wikipedia), it's dependencies and lynx as first webbrowser are ported to OpenWrt! This way the Ben NanoNote can be used as offline wikipedia reader. All of them need some more cleanups but will be committed soon. Unfortunately the amount of RAM (32MB) of the Ben limits applications like OpenZIM, so they'll need some more tweaking to get them running smoothly. Thanks to Lars and Xiang Fu Sound (based on ALSA) and keyboard are now supported, also work is going on to get the battery driver cleaned up / improved (thanks to JieJing Zhang). In addition there's now a driver for the internally used real time clock - also written by lars. Things are moving :) mirko -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part URL: From wolfgang at qi-hardware.com Sun Sep 20 21:13:50 2009 From: wolfgang at qi-hardware.com (Wolfgang Spraul) Date: Sun, 20 Sep 2009 21:13:50 -0400 Subject: some more updates from the software part In-Reply-To: <1253486666.11044.886.camel@mia> References: <1253486666.11044.886.camel@mia> Message-ID: <20090921011350.GA11544@debian> Wooow! All of this sounds great, congratulations! What I am trying to do right now is a commit-log mailing list for the InDefero git & svn repositories so it becomes easier to track progress as it happens and start testing. After that I probably need to look into automatic builds with images and package repository on our servers. Your news are definitely motivating here! Wolfgang On Mon, Sep 21, 2009 at 12:44:26AM +0200, Mirko Vogt wrote: > Hey! > > As Wolfgang is doing since the beginning, from now on I also will try to > summarize what's going on "behind the scenes" (the > software-/OpenWrt-part) in weekly updates. > > So let's see what happened last days: > > USB-Ethernet-Gadget is working. > You're now able to speak ethernet, and therefore IP, to your Ben > Nanonote via USB. > That's really cool, because now all the network-stuff can be used which > simplifies lot's of things (e.g. SSH into the NanoNote, copying files, > etc.) > > Lars found out the used NAND-chip is a multilevel-chip that has to be > treated by the flash-tools in a special way which should fix most of our > previous ECC-NAND-chip-problems. > > OpenZIM, an opensource implementation for handling ZIM-files which > mainly provide wiki-articles (e.g. the wikipedia), it's dependencies and > lynx as first webbrowser are ported to OpenWrt! This way the Ben > NanoNote can be used as offline wikipedia reader. > All of them need some more cleanups but will be committed soon. > Unfortunately the amount of RAM (32MB) of the Ben limits applications > like OpenZIM, so they'll need some more tweaking to get them running > smoothly. > > Thanks to Lars and Xiang Fu Sound (based on ALSA) and keyboard are now > supported, also work is going on to get the battery driver cleaned up / > improved (thanks to JieJing Zhang). > > In addition there's now a driver for the internally used real time clock > - also written by lars. > > > Things are moving :) > > mirko > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer From xiangfu at qi-hardware.com Mon Sep 21 00:40:02 2009 From: xiangfu at qi-hardware.com (Xiangfu Liu) Date: Mon, 21 Sep 2009 12:40:02 +0800 Subject: [PATCH] jz battery driver cleanup In-Reply-To: <1253386006-19505-1-git-send-email-kzjeef@gmail.com> References: <1253386006-19505-1-git-send-email-kzjeef@gmail.com> Message-ID: <4AB703A2.60401@qi-hardware.com> Hi Jiejing Applied, thanks. JieJing.Zhang wrote: > This patch is cleanup more about gpio and platform data. > I don't test in board. But I noticed that qi_lb60.c also have set gpio as input, and the jz_battey do same by gpiolib, Is that cause problem? > > Signed-off-by: JieJing.Zhang > --- > .../files-2.6.31/arch/mips/jz4740/platform.c | 23 +++ > .../xburst/files-2.6.31/drivers/power/jz_battery.c | 152 ++++++++++++++------ > .../files-2.6.31/include/linux/jz4740_batt.h | 27 ++++ > .../xburst/files-2.6.31/include/linux/jz4740_fb.h | 5 + > 4 files changed, 164 insertions(+), 43 deletions(-) > create mode 100644 target/linux/xburst/files-2.6.31/include/linux/jz4740_batt.h > > diff --git a/target/linux/xburst/files-2.6.31/arch/mips/jz4740/platform.c b/target/linux/xburst/files-2.6.31/arch/mips/jz4740/platform.c > index db3d045..b75ddde 100644 > --- a/target/linux/xburst/files-2.6.31/arch/mips/jz4740/platform.c > +++ b/target/linux/xburst/files-2.6.31/arch/mips/jz4740/platform.c > @@ -19,6 +19,8 @@ > #include > #include > #include > +#include > +#include > > #include > #include > @@ -408,6 +410,26 @@ static struct platform_device jz_codec_device = { > .resource = codec_resources, > }; > > +#define JZ_BAT_MAX_VOLTAGE 4200000 > +#define JZ_BAT_MIN_VOLTAGE 3600000 > +static struct jz_batt_info jz_batt_gpio_platform_data = { > + .dc_dect_gpio = GPIO_DC_DETE_N, > + .usb_dect_gpio = GPIO_USB_DETE, > + .charg_stat_gpio = GPIO_CHARG_STAT_N, > + > + .min_voltag = JZ_BAT_MIN_VOLTAGE, > + .max_voltag = JZ_BAT_MAX_VOLTAGE, > + .batt_tech = POWER_SUPPLY_TECHNOLOGY_LIPO, > +}; > + > +static struct platform_device batt_gpio_device = { > + .name = "batt_gpio", > + .id = -1, > + .dev = { > + .platform_data = &jz_batt_gpio_platform_data, > + }, > +}; > + > /* All */ > static struct platform_device *jz_platform_devices[] __initdata = { > &jz_usb_ohci_device, > @@ -420,6 +442,7 @@ static struct platform_device *jz_platform_devices[] __initdata = { > &qi_lb60_fb, > &jz_i2s_device, > &jz_codec_device, > + &batt_gpio_device, > }; > > static int __init jz_platform_init(void) > diff --git a/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c b/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c > index 80b3747..f9ef04f 100755 > --- a/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c > +++ b/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c > @@ -6,6 +6,7 @@ > * based on tosa_battery.c > * > * Copyright (C) 2008 Marek Vasut > + * Copyright (C) 2009 Jiejing Zhang > * > * This program is free software; you can redistribute it and/or modify > * it under the terms of the GNU General Public License version 2 as > @@ -19,28 +20,19 @@ > #include > #include > #include > +#include > > #include > > -#ifdef CONFIG_POWER_SUPPLY_DEBUG > -#define dprintk(x...) printk(x) > -#else > -#define dprintk(x...) while(0){} > -#endif > - > -#define JZ_BAT_MAX_VOLTAGE 4200000 // uV > -#define JZ_BAT_MIN_VOLTAGE 3600000 > - > -static DEFINE_MUTEX(bat_lock); > struct workqueue_struct *monitor_wqueue; > struct delayed_work bat_work; > struct mutex work_lock; > > -int bat_status = POWER_SUPPLY_STATUS_DISCHARGING; > +static int bat_status = POWER_SUPPLY_STATUS_DISCHARGING; > +static struct jz_batt_info *pdata = 0; > > extern unsigned int jz_read_battery(void); > > - > /********************************************************************* > * Power > *********************************************************************/ > @@ -52,9 +44,9 @@ static int jz_get_power_prop(struct power_supply *psy, > switch (psp) { > case POWER_SUPPLY_PROP_ONLINE: > if (psy->type == POWER_SUPPLY_TYPE_MAINS) > - val->intval = !__gpio_get_pin(GPIO_DC_DETE_N); > + val->intval = !gpio_get_value(pdata->dc_dect_gpio); > else > - val->intval = __gpio_get_pin(GPIO_USB_DETE); > + val->intval = !!gpio_get_value(pdata->usb_dect_gpio); > break; > default: > return -EINVAL; > @@ -92,13 +84,26 @@ static unsigned long jz_read_bat(struct power_supply *bat_ps) > { > unsigned long val; > if (CFG_PBAT_DIV == 1) > - val = (((unsigned long long)jz_read_battery() * 7500000)) >> 12; > + val = (((unsigned long long)jz_read_battery() * 7500000L) >> 12) + 33000L; > else > - val = (((unsigned long long)jz_read_battery() * CFG_PBAT_DIV * 2500000)) >> 12; > - dprintk("--raw_batter_vol=%d uV\n", val); > + val = ((unsigned long long)jz_read_battery() * CFG_PBAT_DIV * 2500000L) >> 12; > + dev_dbg(bat_ps->dev, "%s: raw_batter_vol = %d uV\n",__func__,val); > return val; > } > > +static int jz_bat_get_capacity(struct power_supply *bat_ps) > +{ > + int ret; > + ret = (jz_read_bat(bat_ps) - pdata->min_voltag) * 100 > + / (pdata->max_voltag - pdata->min_voltag); > + if (ret > 100) { > + dev_warn(bat_ps->dev, "%s: capacity=%d which exceeds 100," > + "set to 100\n", __func__, ret); > + ret = 100; > + } > + return ret; > +} > + > static int jz_bat_get_property(struct power_supply *bat_ps, > enum power_supply_property psp, > union power_supply_propval *val) > @@ -108,40 +113,37 @@ static int jz_bat_get_property(struct power_supply *bat_ps, > val->intval = bat_status; > break; > case POWER_SUPPLY_PROP_TECHNOLOGY: > - val->intval = POWER_SUPPLY_TECHNOLOGY_LIPO; > + val->intval = pdata->batt_tech; > break; > case POWER_SUPPLY_PROP_HEALTH: > - if(jz_read_bat(bat_ps) < 3600000) { > - dprintk("--battery dead\n"); > + if(jz_read_bat(bat_ps) < JZ_BAT_MIN_VOLTAGE) { > + dev_dbg(bat_ps->dev, "%s: battery is dead," > + "voltage too low!\n", __func__); > val->intval = POWER_SUPPLY_HEALTH_DEAD; > } else { > - dprintk("--battery good\n"); > + dev_dbg(bat_ps->dev, "%s: battery is good," > + "voltage normal.\n", __func__); > val->intval = POWER_SUPPLY_HEALTH_GOOD; > } > break; > case POWER_SUPPLY_PROP_CAPACITY: > - val->intval = (jz_read_bat(bat_ps) - 3600000) * 100 / (4200000 - 3600000); > - if (val->intval > 100) > - val->intval = 100; > - dprintk("--battery_capacity=%d\%\n",val->intval); > + val->intval = jz_bat_get_capacity(bat_ps); > + dev_dbg(bat_ps->dev, "%s: battery_capacity = %d\%\n", > + __func__, val->intval); > break; > case POWER_SUPPLY_PROP_VOLTAGE_NOW: > val->intval = jz_read_bat(bat_ps); > break; > case POWER_SUPPLY_PROP_VOLTAGE_MAX: > case POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN: > - val->intval = JZ_BAT_MAX_VOLTAGE; > + val->intval = pdata->max_voltag; > break; > case POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN: > - val->intval = JZ_BAT_MIN_VOLTAGE; > + val->intval = pdata->min_voltag; > break; > case POWER_SUPPLY_PROP_PRESENT: > val->intval = 1; > break; > - case POWER_SUPPLY_PROP_TEMP: > - case POWER_SUPPLY_PROP_VOL: > - val->intval = 0; // reading TEMP and VOL aren't supported > - break; > default: > return -EINVAL; > } > @@ -168,18 +170,21 @@ static void jz_bat_update(struct power_supply *bat_ps) > unsigned long batt_vol = jz_read_bat(bat_ps); > mutex_lock(&work_lock); > > - if(!__gpio_get_pin(GPIO_CHARG_STAT_N)) > + if(!gpio_get_value(pdata->charg_stat_pgio)) > bat_status = POWER_SUPPLY_STATUS_CHARGING; > - else { > + else > bat_status = POWER_SUPPLY_STATUS_NOT_CHARGING; > - } > > - dprintk("--battery status=%s\n", status_text[bat_status]); > + dev_dbg(bat_ps->dev, "%s: battery status=%s\n", > + __func__, status_text[bat_status]); > + > if ((old_status != bat_status) || > (old_batt_vol - batt_vol > 50000)) { > - pr_debug("%s %s -> %s\n", bat_ps->name, > - status_text[old_status], > - status_text[bat_status]); > + dev_dbg(bat_ps->dev, "%s %s -> %s\n", > + bat_ps->name, > + status_text[old_status], > + status_text[bat_status]); > + > power_supply_changed(bat_ps); > } > > @@ -196,8 +201,6 @@ static enum power_supply_property jz_bat_main_props[] = { > POWER_SUPPLY_PROP_VOLTAGE_MAX, > POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN, > POWER_SUPPLY_PROP_PRESENT, > - POWER_SUPPLY_PROP_TEMP, > - POWER_SUPPLY_PROP_VOL, > }; > > struct power_supply bat_ps = { > @@ -212,7 +215,8 @@ struct power_supply bat_ps = { > > static void jz_bat_work(struct work_struct *work) > { > - const int interval = HZ * 6; > + /* query interval too small will increase system workload*/ > + const int interval = HZ * 30; > > jz_bat_update(&bat_ps); > queue_delayed_work(monitor_wqueue, &bat_work, interval); > @@ -242,12 +246,47 @@ static int jz_bat_resume(struct platform_device *dev) > static int __devinit jz_bat_probe(struct platform_device *dev) > { > int ret = 0; > + > printk("JZ battery init.\n"); > mutex_init(&work_lock); > - > INIT_DELAYED_WORK(&bat_work, jz_bat_work); > > - __gpio_disable_pull(GPIO_USB_DETE); > + if (!dev->dev->platform_data) { > + dev_error(&dev->dev, "Please set battery info\n"); > + return -EINVAL; > + } > + > + pdata = dev->dev->platform_data; > + > + if (pdata->dc_dect_gpio >= 0 && gpio_is_valid(pdata->dc_dect_gpio)) { > + ret = gpio_request(pdata->dc_dect_gpio, "AC/DC DECT"); > + if (ret) > + goto err_dc_gpio_request; > + ret = gpio_direction_input(pdata->dc_dect_gpio); > + if (ret) > + goto err_dc_gpio_direction; > + } > + > + if (pdata->usb_dect_gpio >= 0 && gpio_is_valid(pdata->usb_dect_gpio)) { > + ret = gpio_request(pdata->usb_dect_gpio, "USB DECT"); > + if (ret) > + goto err_usb_gpio_request; > + ret = gpio_direction_input(pdata->usb_dect_gpio); > + if (ret) > + goto err_usb_gpio_direction; > + > + jz_gpio_disable_pullup(pdata->usb_dect_gpio); > + /* TODO: Use generic gpio is better */ > + } > + > + if (pdata->charg_stat_gpio >= 0 && gpio_is_valid(pdata->charg_stat_gpio)) { > + ret = gpio_request(pdata->charg_stat_gpio, "CHARG STAT"); > + if (ret) > + goto err_charg_gpio_request; > + ret = gpio_direction_input(pdata->charg_stat_pgio); > + if (ret) > + goto err_charg_gpio_direction; > + } > > power_supply_register(&dev->dev, &jz_ac); > power_supply_register(&dev->dev, &jz_usb); > @@ -262,10 +301,37 @@ static int __devinit jz_bat_probe(struct platform_device *dev) > } > > return ret; > + > +err_charg_gpio_direction > + dev_err(dev->dev, "charger state gpio set direction failed.\n"); > + gpio_free(pdata->charg_stat_pgio); > +err_charg_gpio_request: > + dev_err(dev->dev, "charger state gpio request failed.\n"); > +err_usb_gpio_direction: > + dev_err(dev->dev, "usb dect gpio set direction failed.\n"); > + gpio_free(pdata->usb_dect_gpio); > +err_usb_gpio_request: > + dev_err(dev->dev, "usb dect gpio request failed.\n"); > +err_dc_gpio_direction: > + dev_err(dev->dev, "ac/dc dect gpio request failed.\n"); > + gpio_free(pdata->dc_dect_gpio); > +err_err_dc_gpio_request: > + dev_err(dev->dev, "ac/dc dect gpio request failed.\n"); > + return ret; > + > } > > static int __devexit jz_bat_remove(struct platform_device *dev) > { > + if (pdata) { > + if (pdata->dc_dect_gpio >= 0) > + gpio_free(pdata->dc_dect_gpio); > + if (pdata->usb_dect_gpio >= 0) > + gpio_free(pdata->usb_dect_pgio); > + if (pdata->charg_stat_gpio >= 0) > + gpio_free(pdata->charg_stat_gpio); > + } > + > power_supply_unregister(&bat_ps); > return 0; > } > diff --git a/target/linux/xburst/files-2.6.31/include/linux/jz4740_batt.h b/target/linux/xburst/files-2.6.31/include/linux/jz4740_batt.h > new file mode 100644 > index 0000000..bef9412 > --- /dev/null > +++ b/target/linux/xburst/files-2.6.31/include/linux/jz4740_batt.h > @@ -0,0 +1,27 @@ > +/* > + * Copyright (C) 2009, Jiejing Zhang > + * > + * This program is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License as published by the > + * Free Software Foundation; either version 2 of the License, or (at your > + * option) any later version. > + * > + * You should have received a copy of the GNU General Public License along > + * with this program; if not, write to the Free Software Foundation, Inc., > + * 675 Mass Ave, Cambridge, MA 02139, USA. > + * > + */ > + > +#ifndef JZ4740_BATT_H > +#define JZ4740_BATT_H > + > +struct jz_batt_info { > + int dc_dect_gpio; /* GPIO port of DC charger detection */ > + int usb_dect_gpio; /* GPIO port of USB charger detection */ > + int charg_stat_gpio; /* GPIO port of Charger state */ > + > + int min_voltag; /* Mininal battery voltage in uV */ > + int max_voltag; /* Maximum battery voltage in uV */ > + int batt_tech; /* Battery technoledge */ > +}; > +#endif > diff --git a/target/linux/xburst/files-2.6.31/include/linux/jz4740_fb.h b/target/linux/xburst/files-2.6.31/include/linux/jz4740_fb.h > index 778e1e9..50a89ff 100644 > --- a/target/linux/xburst/files-2.6.31/include/linux/jz4740_fb.h > +++ b/target/linux/xburst/files-2.6.31/include/linux/jz4740_fb.h > @@ -12,6 +12,9 @@ > * > */ > > +#ifndef JZ4740_FB_H > +#define JZ4740_FB_H > + > #include > > enum jz4740_fb_lcd_type { > @@ -45,3 +48,5 @@ struct jz4740_fb_platform_data { > int bpp; > enum jz4740_fb_lcd_type lcd_type; > }; > + > +#endif From xiangfu at qi-hardware.com Mon Sep 21 00:45:52 2009 From: xiangfu at qi-hardware.com (Xiangfu Liu) Date: Mon, 21 Sep 2009 12:45:52 +0800 Subject: [PATCH] jz battery driver cleanup In-Reply-To: <4AB53CDC.1060601@metafoo.de> References: <1253386006-19505-1-git-send-email-kzjeef@gmail.com> <4AB53CDC.1060601@metafoo.de> Message-ID: <4AB70500.4030409@qi-hardware.com> Lars-Peter Clausen wrote: > Hi JieJing.Zhang > > looks good already :) > I commited the last part of your patch (the include guards for the > jz4740_fb.h) > > Some more commtens for the battery driver: > >> This patch is cleanup more about gpio and platform data. I don't >> test in board. But I noticed that qi_lb60.c also have set gpio as >> input, and the jz_battey do same by gpiolib, Is that cause problem? >> > The gpio code in board_qi_lb60.c should go away. > Hi Lars will work on the board_qi_lb60.c code. commit later. From kzjeef at gmail.com Mon Sep 21 01:52:20 2009 From: kzjeef at gmail.com (ZhangJieJing) Date: Mon, 21 Sep 2009 13:52:20 +0800 Subject: [PATCH] jz battery driver cleanup In-Reply-To: <4AB703A2.60401@qi-hardware.com> References: <1253386006-19505-1-git-send-email-kzjeef@gmail.com> <4AB703A2.60401@qi-hardware.com> Message-ID: Hi, xiangfu: the last patch is not good enough. I've improved it already. please revert that patch... I'll send the new patch later. Thanks. --- Best regards, Zhang Jiejing On Mon, Sep 21, 2009 at 12:40 PM, Xiangfu Liu wrote: > Hi Jiejing > > Applied, thanks. > > JieJing.Zhang wrote: > > This patch is cleanup more about gpio and platform data. > > I don't test in board. But I noticed that qi_lb60.c also have set gpio as > input, and the jz_battey do same by gpiolib, Is that cause problem? > > > > Signed-off-by: JieJing.Zhang > > --- > > .../files-2.6.31/arch/mips/jz4740/platform.c | 23 +++ > > .../xburst/files-2.6.31/drivers/power/jz_battery.c | 152 > ++++++++++++++------ > > .../files-2.6.31/include/linux/jz4740_batt.h | 27 ++++ > > .../xburst/files-2.6.31/include/linux/jz4740_fb.h | 5 + > > 4 files changed, 164 insertions(+), 43 deletions(-) > > create mode 100644 > target/linux/xburst/files-2.6.31/include/linux/jz4740_batt.h > > > > diff --git a/target/linux/xburst/files-2.6.31/arch/mips/jz4740/platform.c > b/target/linux/xburst/files-2.6.31/arch/mips/jz4740/platform.c > > index db3d045..b75ddde 100644 > > --- a/target/linux/xburst/files-2.6.31/arch/mips/jz4740/platform.c > > +++ b/target/linux/xburst/files-2.6.31/arch/mips/jz4740/platform.c > > @@ -19,6 +19,8 @@ > > #include > > #include > > #include > > +#include > > +#include > > > > #include > > #include > > @@ -408,6 +410,26 @@ static struct platform_device jz_codec_device = { > > .resource = codec_resources, > > }; > > > > +#define JZ_BAT_MAX_VOLTAGE 4200000 > > +#define JZ_BAT_MIN_VOLTAGE 3600000 > > +static struct jz_batt_info jz_batt_gpio_platform_data = { > > + .dc_dect_gpio = GPIO_DC_DETE_N, > > + .usb_dect_gpio = GPIO_USB_DETE, > > + .charg_stat_gpio = GPIO_CHARG_STAT_N, > > + > > + .min_voltag = JZ_BAT_MIN_VOLTAGE, > > + .max_voltag = JZ_BAT_MAX_VOLTAGE, > > + .batt_tech = POWER_SUPPLY_TECHNOLOGY_LIPO, > > +}; > > + > > +static struct platform_device batt_gpio_device = { > > + .name = "batt_gpio", > > + .id = -1, > > + .dev = { > > + .platform_data = &jz_batt_gpio_platform_data, > > + }, > > +}; > > + > > /* All */ > > static struct platform_device *jz_platform_devices[] __initdata = { > > &jz_usb_ohci_device, > > @@ -420,6 +442,7 @@ static struct platform_device *jz_platform_devices[] > __initdata = { > > &qi_lb60_fb, > > &jz_i2s_device, > > &jz_codec_device, > > + &batt_gpio_device, > > }; > > > > static int __init jz_platform_init(void) > > diff --git a/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c > b/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c > > index 80b3747..f9ef04f 100755 > > --- a/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c > > +++ b/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c > > @@ -6,6 +6,7 @@ > > * based on tosa_battery.c > > * > > * Copyright (C) 2008 Marek Vasut > > + * Copyright (C) 2009 Jiejing Zhang > > * > > * This program is free software; you can redistribute it and/or modify > > * it under the terms of the GNU General Public License version 2 as > > @@ -19,28 +20,19 @@ > > #include > > #include > > #include > > +#include > > > > #include > > > > -#ifdef CONFIG_POWER_SUPPLY_DEBUG > > -#define dprintk(x...) printk(x) > > -#else > > -#define dprintk(x...) while(0){} > > -#endif > > - > > -#define JZ_BAT_MAX_VOLTAGE 4200000 // uV > > -#define JZ_BAT_MIN_VOLTAGE 3600000 > > - > > -static DEFINE_MUTEX(bat_lock); > > struct workqueue_struct *monitor_wqueue; > > struct delayed_work bat_work; > > struct mutex work_lock; > > > > -int bat_status = POWER_SUPPLY_STATUS_DISCHARGING; > > +static int bat_status = POWER_SUPPLY_STATUS_DISCHARGING; > > +static struct jz_batt_info *pdata = 0; > > > > extern unsigned int jz_read_battery(void); > > > > - > > /********************************************************************* > > * Power > > *********************************************************************/ > > @@ -52,9 +44,9 @@ static int jz_get_power_prop(struct power_supply *psy, > > switch (psp) { > > case POWER_SUPPLY_PROP_ONLINE: > > if (psy->type == POWER_SUPPLY_TYPE_MAINS) > > - val->intval = !__gpio_get_pin(GPIO_DC_DETE_N); > > + val->intval = !gpio_get_value(pdata->dc_dect_gpio); > > else > > - val->intval = __gpio_get_pin(GPIO_USB_DETE); > > + val->intval = > !!gpio_get_value(pdata->usb_dect_gpio); > > break; > > default: > > return -EINVAL; > > @@ -92,13 +84,26 @@ static unsigned long jz_read_bat(struct power_supply > *bat_ps) > > { > > unsigned long val; > > if (CFG_PBAT_DIV == 1) > > - val = (((unsigned long long)jz_read_battery() * 7500000)) > >> 12; > > + val = (((unsigned long long)jz_read_battery() * 7500000L) > >> 12) + 33000L; > > else > > - val = (((unsigned long long)jz_read_battery() * > CFG_PBAT_DIV * 2500000)) >> 12; > > - dprintk("--raw_batter_vol=%d uV\n", val); > > + val = ((unsigned long long)jz_read_battery() * CFG_PBAT_DIV > * 2500000L) >> 12; > > + dev_dbg(bat_ps->dev, "%s: raw_batter_vol = %d uV\n",__func__,val); > > return val; > > } > > > > +static int jz_bat_get_capacity(struct power_supply *bat_ps) > > +{ > > + int ret; > > + ret = (jz_read_bat(bat_ps) - pdata->min_voltag) * 100 > > + / (pdata->max_voltag - pdata->min_voltag); > > + if (ret > 100) { > > + dev_warn(bat_ps->dev, "%s: capacity=%d which exceeds 100," > > + "set to 100\n", __func__, ret); > > + ret = 100; > > + } > > + return ret; > > +} > > + > > static int jz_bat_get_property(struct power_supply *bat_ps, > > enum power_supply_property psp, > > union power_supply_propval *val) > > @@ -108,40 +113,37 @@ static int jz_bat_get_property(struct power_supply > *bat_ps, > > val->intval = bat_status; > > break; > > case POWER_SUPPLY_PROP_TECHNOLOGY: > > - val->intval = POWER_SUPPLY_TECHNOLOGY_LIPO; > > + val->intval = pdata->batt_tech; > > break; > > case POWER_SUPPLY_PROP_HEALTH: > > - if(jz_read_bat(bat_ps) < 3600000) { > > - dprintk("--battery dead\n"); > > + if(jz_read_bat(bat_ps) < JZ_BAT_MIN_VOLTAGE) { > > + dev_dbg(bat_ps->dev, "%s: battery is dead," > > + "voltage too low!\n", __func__); > > val->intval = POWER_SUPPLY_HEALTH_DEAD; > > } else { > > - dprintk("--battery good\n"); > > + dev_dbg(bat_ps->dev, "%s: battery is good," > > + "voltage normal.\n", __func__); > > val->intval = POWER_SUPPLY_HEALTH_GOOD; > > } > > break; > > case POWER_SUPPLY_PROP_CAPACITY: > > - val->intval = (jz_read_bat(bat_ps) - 3600000) * 100 / > (4200000 - 3600000); > > - if (val->intval > 100) > > - val->intval = 100; > > - dprintk("--battery_capacity=%d\%\n",val->intval); > > + val->intval = jz_bat_get_capacity(bat_ps); > > + dev_dbg(bat_ps->dev, "%s: battery_capacity = %d\%\n", > > + __func__, val->intval); > > break; > > case POWER_SUPPLY_PROP_VOLTAGE_NOW: > > val->intval = jz_read_bat(bat_ps); > > break; > > case POWER_SUPPLY_PROP_VOLTAGE_MAX: > > case POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN: > > - val->intval = JZ_BAT_MAX_VOLTAGE; > > + val->intval = pdata->max_voltag; > > break; > > case POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN: > > - val->intval = JZ_BAT_MIN_VOLTAGE; > > + val->intval = pdata->min_voltag; > > break; > > case POWER_SUPPLY_PROP_PRESENT: > > val->intval = 1; > > break; > > - case POWER_SUPPLY_PROP_TEMP: > > - case POWER_SUPPLY_PROP_VOL: > > - val->intval = 0; // reading TEMP and VOL aren't supported > > - break; > > default: > > return -EINVAL; > > } > > @@ -168,18 +170,21 @@ static void jz_bat_update(struct power_supply > *bat_ps) > > unsigned long batt_vol = jz_read_bat(bat_ps); > > mutex_lock(&work_lock); > > > > - if(!__gpio_get_pin(GPIO_CHARG_STAT_N)) > > + if(!gpio_get_value(pdata->charg_stat_pgio)) > > bat_status = POWER_SUPPLY_STATUS_CHARGING; > > - else { > > + else > > bat_status = POWER_SUPPLY_STATUS_NOT_CHARGING; > > - } > > > > - dprintk("--battery status=%s\n", status_text[bat_status]); > > + dev_dbg(bat_ps->dev, "%s: battery status=%s\n", > > + __func__, status_text[bat_status]); > > + > > if ((old_status != bat_status) || > > (old_batt_vol - batt_vol > 50000)) { > > - pr_debug("%s %s -> %s\n", bat_ps->name, > > - status_text[old_status], > > - status_text[bat_status]); > > + dev_dbg(bat_ps->dev, "%s %s -> %s\n", > > + bat_ps->name, > > + status_text[old_status], > > + status_text[bat_status]); > > + > > power_supply_changed(bat_ps); > > } > > > > @@ -196,8 +201,6 @@ static enum power_supply_property jz_bat_main_props[] > = { > > POWER_SUPPLY_PROP_VOLTAGE_MAX, > > POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN, > > POWER_SUPPLY_PROP_PRESENT, > > - POWER_SUPPLY_PROP_TEMP, > > - POWER_SUPPLY_PROP_VOL, > > }; > > > > struct power_supply bat_ps = { > > @@ -212,7 +215,8 @@ struct power_supply bat_ps = { > > > > static void jz_bat_work(struct work_struct *work) > > { > > - const int interval = HZ * 6; > > + /* query interval too small will increase system workload*/ > > + const int interval = HZ * 30; > > > > jz_bat_update(&bat_ps); > > queue_delayed_work(monitor_wqueue, &bat_work, interval); > > @@ -242,12 +246,47 @@ static int jz_bat_resume(struct platform_device > *dev) > > static int __devinit jz_bat_probe(struct platform_device *dev) > > { > > int ret = 0; > > + > > printk("JZ battery init.\n"); > > mutex_init(&work_lock); > > - > > INIT_DELAYED_WORK(&bat_work, jz_bat_work); > > > > - __gpio_disable_pull(GPIO_USB_DETE); > > + if (!dev->dev->platform_data) { > > + dev_error(&dev->dev, "Please set battery info\n"); > > + return -EINVAL; > > + } > > + > > + pdata = dev->dev->platform_data; > > + > > + if (pdata->dc_dect_gpio >= 0 && gpio_is_valid(pdata->dc_dect_gpio)) > { > > + ret = gpio_request(pdata->dc_dect_gpio, "AC/DC DECT"); > > + if (ret) > > + goto err_dc_gpio_request; > > + ret = gpio_direction_input(pdata->dc_dect_gpio); > > + if (ret) > > + goto err_dc_gpio_direction; > > + } > > + > > + if (pdata->usb_dect_gpio >= 0 && > gpio_is_valid(pdata->usb_dect_gpio)) { > > + ret = gpio_request(pdata->usb_dect_gpio, "USB DECT"); > > + if (ret) > > + goto err_usb_gpio_request; > > + ret = gpio_direction_input(pdata->usb_dect_gpio); > > + if (ret) > > + goto err_usb_gpio_direction; > > + > > + jz_gpio_disable_pullup(pdata->usb_dect_gpio); > > + /* TODO: Use generic gpio is better */ > > + } > > + > > + if (pdata->charg_stat_gpio >= 0 && > gpio_is_valid(pdata->charg_stat_gpio)) { > > + ret = gpio_request(pdata->charg_stat_gpio, "CHARG STAT"); > > + if (ret) > > + goto err_charg_gpio_request; > > + ret = gpio_direction_input(pdata->charg_stat_pgio); > > + if (ret) > > + goto err_charg_gpio_direction; > > + } > > > > power_supply_register(&dev->dev, &jz_ac); > > power_supply_register(&dev->dev, &jz_usb); > > @@ -262,10 +301,37 @@ static int __devinit jz_bat_probe(struct > platform_device *dev) > > } > > > > return ret; > > + > > +err_charg_gpio_direction > > + dev_err(dev->dev, "charger state gpio set direction failed.\n"); > > + gpio_free(pdata->charg_stat_pgio); > > +err_charg_gpio_request: > > + dev_err(dev->dev, "charger state gpio request failed.\n"); > > +err_usb_gpio_direction: > > + dev_err(dev->dev, "usb dect gpio set direction failed.\n"); > > + gpio_free(pdata->usb_dect_gpio); > > +err_usb_gpio_request: > > + dev_err(dev->dev, "usb dect gpio request failed.\n"); > > +err_dc_gpio_direction: > > + dev_err(dev->dev, "ac/dc dect gpio request failed.\n"); > > + gpio_free(pdata->dc_dect_gpio); > > +err_err_dc_gpio_request: > > + dev_err(dev->dev, "ac/dc dect gpio request failed.\n"); > > + return ret; > > + > > } > > > > static int __devexit jz_bat_remove(struct platform_device *dev) > > { > > + if (pdata) { > > + if (pdata->dc_dect_gpio >= 0) > > + gpio_free(pdata->dc_dect_gpio); > > + if (pdata->usb_dect_gpio >= 0) > > + gpio_free(pdata->usb_dect_pgio); > > + if (pdata->charg_stat_gpio >= 0) > > + gpio_free(pdata->charg_stat_gpio); > > + } > > + > > power_supply_unregister(&bat_ps); > > return 0; > > } > > diff --git a/target/linux/xburst/files-2.6.31/include/linux/jz4740_batt.h > b/target/linux/xburst/files-2.6.31/include/linux/jz4740_batt.h > > new file mode 100644 > > index 0000000..bef9412 > > --- /dev/null > > +++ b/target/linux/xburst/files-2.6.31/include/linux/jz4740_batt.h > > @@ -0,0 +1,27 @@ > > +/* > > + * Copyright (C) 2009, Jiejing Zhang > > + * > > + * This program is free software; you can redistribute it and/or > modify it > > + * under the terms of the GNU General Public License as > published by the > > + * Free Software Foundation; either version 2 of the License, or > (at your > > + * option) any later version. > > + * > > + * You should have received a copy of the GNU General Public License > along > > + * with this program; if not, write to the Free Software Foundation, > Inc., > > + * 675 Mass Ave, Cambridge, MA 02139, USA. > > + * > > + */ > > + > > +#ifndef JZ4740_BATT_H > > +#define JZ4740_BATT_H > > + > > +struct jz_batt_info { > > + int dc_dect_gpio; /* GPIO port of DC charger detection */ > > + int usb_dect_gpio; /* GPIO port of USB charger detection */ > > + int charg_stat_gpio; /* GPIO port of Charger state */ > > + > > + int min_voltag; /* Mininal battery voltage in uV */ > > + int max_voltag; /* Maximum battery voltage in uV */ > > + int batt_tech; /* Battery technoledge */ > > +}; > > +#endif > > diff --git a/target/linux/xburst/files-2.6.31/include/linux/jz4740_fb.h > b/target/linux/xburst/files-2.6.31/include/linux/jz4740_fb.h > > index 778e1e9..50a89ff 100644 > > --- a/target/linux/xburst/files-2.6.31/include/linux/jz4740_fb.h > > +++ b/target/linux/xburst/files-2.6.31/include/linux/jz4740_fb.h > > @@ -12,6 +12,9 @@ > > * > > */ > > > > +#ifndef JZ4740_FB_H > > +#define JZ4740_FB_H > > + > > #include > > > > enum jz4740_fb_lcd_type { > > @@ -45,3 +48,5 @@ struct jz4740_fb_platform_data { > > int bpp; > > enum jz4740_fb_lcd_type lcd_type; > > }; > > + > > +#endif > > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kzjeef at gmail.com Mon Sep 21 03:03:46 2009 From: kzjeef at gmail.com (ZhangJieJing) Date: Mon, 21 Sep 2009 15:03:46 +0800 Subject: [PATCH] jz battery driver cleanup In-Reply-To: References: <1253386006-19505-1-git-send-email-kzjeef@gmail.com> <4AB703A2.60401@qi-hardware.com> Message-ID: This patch is cleanup more about gpio and platform data. Signed-off-by: Jiejing.Zhang --- .../files-2.6.31/arch/mips/jz4740/platform.c | 23 +++ .../xburst/files-2.6.31/drivers/power/jz_battery.c | 185 +++++++++++++++----- 2 files changed, 163 insertions(+), 45 deletions(-) diff --git a/target/linux/xburst/files-2.6.31/arch/mips/jz4740/platform.c b/target/linux/xburst/files-2.6.31/arch/mips/jz4740/platform.c index db3d045..b75ddde 100644 --- a/target/linux/xburst/files-2.6.31/arch/mips/jz4740/platform.c +++ b/target/linux/xburst/files-2.6.31/arch/mips/jz4740/platform.c @@ -19,6 +19,8 @@ #include #include #include +#include +#include #include #include @@ -408,6 +410,26 @@ static struct platform_device jz_codec_device = { .resource = codec_resources, }; +#define JZ_BAT_MAX_VOLTAGE 4200000 +#define JZ_BAT_MIN_VOLTAGE 3600000 +static struct jz_batt_info jz_batt_gpio_platform_data = { + .dc_dect_gpio = GPIO_DC_DETE_N, + .usb_dect_gpio = GPIO_USB_DETE, + .charg_stat_gpio = GPIO_CHARG_STAT_N, + + .min_voltag = JZ_BAT_MIN_VOLTAGE, + .max_voltag = JZ_BAT_MAX_VOLTAGE, + .batt_tech = POWER_SUPPLY_TECHNOLOGY_LIPO, +}; + +static struct platform_device batt_gpio_device = { + .name = "batt_gpio", + .id = -1, + .dev = { + .platform_data = &jz_batt_gpio_platform_data, + }, +}; + /* All */ static struct platform_device *jz_platform_devices[] __initdata = { &jz_usb_ohci_device, @@ -420,6 +442,7 @@ static struct platform_device *jz_platform_devices[] __initdata = { &qi_lb60_fb, &jz_i2s_device, &jz_codec_device, + &batt_gpio_device, }; static int __init jz_platform_init(void) diff --git a/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c b/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c index 80b3747..2d74d75 100755 --- a/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c +++ b/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c @@ -6,6 +6,7 @@ * based on tosa_battery.c * * Copyright (C) 2008 Marek Vasut + * Copyright (C) 2009 Jiejing Zhang * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as @@ -19,28 +20,19 @@ #include #include #include +#include #include -#ifdef CONFIG_POWER_SUPPLY_DEBUG -#define dprintk(x...) printk(x) -#else -#define dprintk(x...) while(0){} -#endif - -#define JZ_BAT_MAX_VOLTAGE 4200000 // uV -#define JZ_BAT_MIN_VOLTAGE 3600000 - -static DEFINE_MUTEX(bat_lock); struct workqueue_struct *monitor_wqueue; struct delayed_work bat_work; struct mutex work_lock; -int bat_status = POWER_SUPPLY_STATUS_DISCHARGING; +static int bat_status = POWER_SUPPLY_STATUS_DISCHARGING; +static struct jz_batt_info *pdata = 0; extern unsigned int jz_read_battery(void); - /********************************************************************* * Power *********************************************************************/ @@ -52,9 +44,9 @@ static int jz_get_power_prop(struct power_supply *psy, switch (psp) { case POWER_SUPPLY_PROP_ONLINE: if (psy->type == POWER_SUPPLY_TYPE_MAINS) - val->intval = !__gpio_get_pin(GPIO_DC_DETE_N); + val->intval = !gpio_get_value(pdata->dc_dect_gpio); else - val->intval = __gpio_get_pin(GPIO_USB_DETE); + val->intval = !!gpio_get_value(pdata->usb_dect_gpio); break; default: return -EINVAL; @@ -92,13 +84,26 @@ static unsigned long jz_read_bat(struct power_supply *bat_ps) { unsigned long val; if (CFG_PBAT_DIV == 1) - val = (((unsigned long long)jz_read_battery() * 7500000)) >> 12; + val = (((unsigned long long)jz_read_battery() * 7500000L) >> 12) + 33000L; else - val = (((unsigned long long)jz_read_battery() * CFG_PBAT_DIV * 2500000)) >> 12; - dprintk("--raw_batter_vol=%d uV\n", val); + val = ((unsigned long long)jz_read_battery() * CFG_PBAT_DIV * 2500000L) >> 12; + dev_dbg(bat_ps->dev, "%s: raw_batter_vol = %d uV\n",__func__,val); return val; } +static int jz_bat_get_capacity(struct power_supply *bat_ps) +{ + int ret; + ret = (jz_read_bat(bat_ps) - pdata->min_voltag) * 100 + / (pdata->max_voltag - pdata->min_voltag); + if (ret > 100) { + dev_warn(bat_ps->dev, "%s: capacity=%d which exceeds 100," + "set to 100\n", __func__, ret); + ret = 100; + } + return ret; +} + static int jz_bat_get_property(struct power_supply *bat_ps, enum power_supply_property psp, union power_supply_propval *val) @@ -108,40 +113,37 @@ static int jz_bat_get_property(struct power_supply *bat_ps, val->intval = bat_status; break; case POWER_SUPPLY_PROP_TECHNOLOGY: - val->intval = POWER_SUPPLY_TECHNOLOGY_LIPO; + val->intval = pdata->batt_tech; break; case POWER_SUPPLY_PROP_HEALTH: - if(jz_read_bat(bat_ps) < 3600000) { - dprintk("--battery dead\n"); + if(jz_read_bat(bat_ps) < JZ_BAT_MIN_VOLTAGE) { + dev_dbg(bat_ps->dev, "%s: battery is dead," + "voltage too low!\n", __func__); val->intval = POWER_SUPPLY_HEALTH_DEAD; } else { - dprintk("--battery good\n"); + dev_dbg(bat_ps->dev, "%s: battery is good," + "voltage normal.\n", __func__); val->intval = POWER_SUPPLY_HEALTH_GOOD; } break; case POWER_SUPPLY_PROP_CAPACITY: - val->intval = (jz_read_bat(bat_ps) - 3600000) * 100 / (4200000 - 3600000); - if (val->intval > 100) - val->intval = 100; - dprintk("--battery_capacity=%d\%\n",val->intval); + val->intval = jz_bat_get_capacity(bat_ps); + dev_dbg(bat_ps->dev, "%s: battery_capacity = %d\%\n", + __func__, val->intval); break; case POWER_SUPPLY_PROP_VOLTAGE_NOW: val->intval = jz_read_bat(bat_ps); break; case POWER_SUPPLY_PROP_VOLTAGE_MAX: case POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN: - val->intval = JZ_BAT_MAX_VOLTAGE; + val->intval = pdata->max_voltag; break; case POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN: - val->intval = JZ_BAT_MIN_VOLTAGE; + val->intval = pdata->min_voltag; break; case POWER_SUPPLY_PROP_PRESENT: val->intval = 1; break; - case POWER_SUPPLY_PROP_TEMP: - case POWER_SUPPLY_PROP_VOL: - val->intval = 0; // reading TEMP and VOL aren't supported - break; default: return -EINVAL; } @@ -168,18 +170,21 @@ static void jz_bat_update(struct power_supply *bat_ps) unsigned long batt_vol = jz_read_bat(bat_ps); mutex_lock(&work_lock); - if(!__gpio_get_pin(GPIO_CHARG_STAT_N)) + if(!gpio_get_value(pdata->charg_stat_pgio)) bat_status = POWER_SUPPLY_STATUS_CHARGING; - else { + else bat_status = POWER_SUPPLY_STATUS_NOT_CHARGING; - } - dprintk("--battery status=%s\n", status_text[bat_status]); + dev_dbg(bat_ps->dev, "%s: battery status=%s\n", + __func__, status_text[bat_status]); + if ((old_status != bat_status) || (old_batt_vol - batt_vol > 50000)) { - pr_debug("%s %s -> %s\n", bat_ps->name, - status_text[old_status], - status_text[bat_status]); + dev_dbg(bat_ps->dev, "%s %s -> %s\n", + bat_ps->name, + status_text[old_status], + status_text[bat_status]); + power_supply_changed(bat_ps); } @@ -196,8 +201,6 @@ static enum power_supply_property jz_bat_main_props[] = { POWER_SUPPLY_PROP_VOLTAGE_MAX, POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN, POWER_SUPPLY_PROP_PRESENT, - POWER_SUPPLY_PROP_TEMP, - POWER_SUPPLY_PROP_VOL, }; struct power_supply bat_ps = { @@ -212,7 +215,8 @@ struct power_supply bat_ps = { static void jz_bat_work(struct work_struct *work) { - const int interval = HZ * 6; + /* query interval too small will increase system workload*/ + const int interval = HZ * 30; jz_bat_update(&bat_ps); queue_delayed_work(monitor_wqueue, &bat_work, interval); @@ -242,17 +246,81 @@ static int jz_bat_resume(struct platform_device *dev) static int __devinit jz_bat_probe(struct platform_device *dev) { int ret = 0; + printk("JZ battery init.\n"); mutex_init(&work_lock); - INIT_DELAYED_WORK(&bat_work, jz_bat_work); - __gpio_disable_pull(GPIO_USB_DETE); + if (!dev->dev->platform_data) { + dev_error(&dev->dev, "Please set battery info\n"); + return -EINVAL; + } + + pdata = dev->dev->platform_data; - power_supply_register(&dev->dev, &jz_ac); - power_supply_register(&dev->dev, &jz_usb); + if (gpio_is_valid(pdata->dc_dect_gpio)) { + ret = gpio_request(pdata->dc_dect_gpio, "AC/DC DECT"); + if (ret) { + dev_err(dev->dev, "ac/dc dect gpio request failed.\n"); + + goto err_dc_gpio_request; + } + ret = gpio_direction_input(pdata->dc_dect_gpio); + if (ret) { + dev_err(dev->dev, "ac/dc dect gpio direction failed.\n"); + + goto err_dc_gpio_direction; + } + } + + if (gpio_is_valid(pdata->usb_dect_gpio)) { + ret = gpio_request(pdata->usb_dect_gpio, "USB DECT"); + if (ret) { + dev_err(dev->dev, "usb dect gpio request failed.\n"); + + goto err_usb_gpio_request; + } + ret = gpio_direction_input(pdata->usb_dect_gpio); + if (ret) { + dev_err(dev->dev, "usb dect gpio set direction failed.\n"); + goto err_usb_gpio_direction; + } + + jz_gpio_disable_pullup(pdata->usb_dect_gpio); + /* TODO: Use generic gpio is better */ + } + + if (gpio_is_valid(pdata->charg_stat_gpio)) { + ret = gpio_request(pdata->charg_stat_gpio, "CHARG STAT"); + if (ret) { + dev_err(dev->dev, "charger state gpio request failed.\n"); + goto err_charg_gpio_request; + } + ret = gpio_direction_input(pdata->charg_stat_pgio); + if (ret) { + dev_err(dev->dev, "charger state gpio set direction failed.\n"); + goto err_charg_gpio_direction; + } + } + + ret = power_supply_register(&dev->dev, &jz_ac); + if (ret) { + dev_err(dev->dev, "power supply ac/dc register failed.\n"); + goto err_power_register_ac; + } + + ret = power_supply_register(&dev->dev, &jz_usb); + if (ret) { + dev_err(dev->dev, "power supply usb register failed.\n"); + goto err_power_register_usb; + } ret = power_supply_register(&dev->dev, &bat_ps); + if (ret) { + dev_err(dev->dev, "power supply battery register failed.\n"); + goto err_power_register_bat; + } + if (!ret) { monitor_wqueue = create_singlethread_workqueue("jz_battery"); if (!monitor_wqueue) { @@ -262,11 +330,38 @@ static int __devinit jz_bat_probe(struct platform_device *dev) } return ret; + +err_power_register_bat: + power_supply_unregister(&jz_usb); +err_power_register_usb: + power_supply_unregister(&jz_ac); +err_power_register_ac: +err_charg_gpio_direction: + gpio_free(pdata->charg_stat_pgio); +err_charg_gpio_request: +err_usb_gpio_direction: + gpio_free(pdata->usb_dect_gpio); +err_usb_gpio_request: +err_dc_gpio_direction: + gpio_free(pdata->dc_dect_gpio); +err_err_dc_gpio_request: + return ret; } static int __devexit jz_bat_remove(struct platform_device *dev) { + if (pdata) { + if (gpio_is_valid(pdata->dc_dct_gpio)) + gpio_free(pdata->dc_dect_gpio); + if (gpio_is_valid(pdata->usb_dect_gpio)) + gpio_free(pdata->usb_dect_pgio); + if (gpio_is_valid(pdata->charg_stat_gpio)) + gpio_free(pdata->charg_stat_gpio); + } + power_supply_unregister(&bat_ps); + power_supply_unregister(&jz_ac); + power_supply_unregister(&jz_usb); return 0; } -- 1.6.0.4 On Mon, Sep 21, 2009 at 1:52 PM, ZhangJieJing wrote: > > Hi, xiangfu: > > the last patch is not good enough. > I've improved it already. > > please revert that patch... > I'll send the new patch later. > Thanks. > --- > Best regards, > Zhang Jiejing > > > On Mon, Sep 21, 2009 at 12:40 PM, Xiangfu Liu wrote: >> >> Hi Jiejing >> >> Applied, thanks. >> >> JieJing.Zhang wrote: >> > This patch is cleanup more about gpio and platform data. >> > I don't test in board. But I noticed that qi_lb60.c also have set gpio as input, and the jz_battey do same by gpiolib, Is that cause problem? >> > >> > Signed-off-by: JieJing.Zhang >> > --- >> > ?.../files-2.6.31/arch/mips/jz4740/platform.c ? ? ? | ? 23 +++ >> > ?.../xburst/files-2.6.31/drivers/power/jz_battery.c | ?152 ++++++++++++++------ >> > ?.../files-2.6.31/include/linux/jz4740_batt.h ? ? ? | ? 27 ++++ >> > ?.../xburst/files-2.6.31/include/linux/jz4740_fb.h ?| ? ?5 + >> > ?4 files changed, 164 insertions(+), 43 deletions(-) >> > ?create mode 100644 target/linux/xburst/files-2.6.31/include/linux/jz4740_batt.h >> > >> > diff --git a/target/linux/xburst/files-2.6.31/arch/mips/jz4740/platform.c b/target/linux/xburst/files-2.6.31/arch/mips/jz4740/platform.c >> > index db3d045..b75ddde 100644 >> > --- a/target/linux/xburst/files-2.6.31/arch/mips/jz4740/platform.c >> > +++ b/target/linux/xburst/files-2.6.31/arch/mips/jz4740/platform.c >> > @@ -19,6 +19,8 @@ >> > ?#include >> > ?#include >> > ?#include >> > +#include >> > +#include >> > >> > ?#include >> > ?#include >> > @@ -408,6 +410,26 @@ static struct platform_device jz_codec_device = { >> > ? ? ? .resource ? ? ? = codec_resources, >> > ?}; >> > >> > +#define JZ_BAT_MAX_VOLTAGE 4200000 >> > +#define JZ_BAT_MIN_VOLTAGE 3600000 >> > +static struct jz_batt_info jz_batt_gpio_platform_data = { >> > + ? ? .dc_dect_gpio ? = GPIO_DC_DETE_N, >> > + ? ? .usb_dect_gpio ?= GPIO_USB_DETE, >> > + ? ? .charg_stat_gpio ?= GPIO_CHARG_STAT_N, >> > + >> > + ? ? .min_voltag ? ? = JZ_BAT_MIN_VOLTAGE, >> > + ? ? .max_voltag ? ? = JZ_BAT_MAX_VOLTAGE, >> > + ? ? .batt_tech ? ? ?= POWER_SUPPLY_TECHNOLOGY_LIPO, >> > +}; >> > + >> > +static struct platform_device batt_gpio_device = { >> > + ? ? .name = "batt_gpio", >> > + ? ? .id = -1, >> > + ? ? .dev = { >> > + ? ? ? ? ? ? .platform_data = &jz_batt_gpio_platform_data, >> > + ? ? }, >> > +}; >> > + >> > ?/* All */ >> > ?static struct platform_device *jz_platform_devices[] __initdata = { >> > ? ? ? &jz_usb_ohci_device, >> > @@ -420,6 +442,7 @@ static struct platform_device *jz_platform_devices[] __initdata = { >> > ? ? ? &qi_lb60_fb, >> > ? ? ? &jz_i2s_device, >> > ? ? ? &jz_codec_device, >> > + ? ? &batt_gpio_device, >> > ?}; >> > >> > ?static int __init jz_platform_init(void) >> > diff --git a/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c b/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c >> > index 80b3747..f9ef04f 100755 >> > --- a/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c >> > +++ b/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c >> > @@ -6,6 +6,7 @@ >> > ? * based on tosa_battery.c >> > ? * >> > ? * Copyright (C) 2008 Marek Vasut >> > + * Copyright (C) 2009 Jiejing Zhang >> > ? * >> > ? * This program is free software; you can redistribute it and/or modify >> > ? * it under the terms of the GNU General Public License version 2 as >> > @@ -19,28 +20,19 @@ >> > ?#include >> > ?#include >> > ?#include >> > +#include >> > >> > ?#include >> > >> > -#ifdef CONFIG_POWER_SUPPLY_DEBUG >> > -#define dprintk(x...) printk(x) >> > -#else >> > -#define dprintk(x...) while(0){} >> > -#endif >> > - >> > -#define JZ_BAT_MAX_VOLTAGE 4200000 // uV >> > -#define JZ_BAT_MIN_VOLTAGE 3600000 >> > - >> > -static DEFINE_MUTEX(bat_lock); >> > ?struct workqueue_struct *monitor_wqueue; >> > ?struct delayed_work bat_work; >> > ?struct mutex work_lock; >> > >> > -int bat_status = POWER_SUPPLY_STATUS_DISCHARGING; >> > +static int bat_status = POWER_SUPPLY_STATUS_DISCHARGING; >> > +static struct jz_batt_info *pdata = 0; >> > >> > ?extern unsigned int jz_read_battery(void); >> > >> > - >> > ?/********************************************************************* >> > ? * ? ? ? ? ? Power >> > ? *********************************************************************/ >> > @@ -52,9 +44,9 @@ static int jz_get_power_prop(struct power_supply *psy, >> > ? ? ? switch (psp) { >> > ? ? ? case POWER_SUPPLY_PROP_ONLINE: >> > ? ? ? ? ? ? ? if (psy->type == POWER_SUPPLY_TYPE_MAINS) >> > - ? ? ? ? ? ? ? ? ? ? val->intval = !__gpio_get_pin(GPIO_DC_DETE_N); >> > + ? ? ? ? ? ? ? ? ? ? val->intval = !gpio_get_value(pdata->dc_dect_gpio); >> > ? ? ? ? ? ? ? else >> > - ? ? ? ? ? ? ? ? ? ? val->intval = __gpio_get_pin(GPIO_USB_DETE); >> > + ? ? ? ? ? ? ? ? ? ? val->intval = !!gpio_get_value(pdata->usb_dect_gpio); >> > ? ? ? ? ? ? ? break; >> > ? ? ? default: >> > ? ? ? ? ? ? ? return -EINVAL; >> > @@ -92,13 +84,26 @@ static unsigned long jz_read_bat(struct power_supply *bat_ps) >> > ?{ >> > ? ? ? unsigned long val; >> > ? ? ? if (CFG_PBAT_DIV == 1) >> > - ? ? ? ? ? ? val = (((unsigned long long)jz_read_battery() * 7500000)) >> 12; >> > + ? ? ? ? ? ? val = (((unsigned long long)jz_read_battery() * 7500000L) >> 12) + 33000L; >> > ? ? ? else >> > - ? ? ? ? ? ? val = (((unsigned long long)jz_read_battery() * CFG_PBAT_DIV * 2500000)) >> 12; >> > - ? ? dprintk("--raw_batter_vol=%d uV\n", val); >> > + ? ? ? ? ? ? val = ((unsigned long long)jz_read_battery() * CFG_PBAT_DIV * 2500000L) >> 12; >> > + ? ? dev_dbg(bat_ps->dev, "%s: raw_batter_vol = %d uV\n",__func__,val); >> > ? ? ? return val; >> > ?} >> > >> > +static int jz_bat_get_capacity(struct power_supply *bat_ps) >> > +{ >> > + ? ? int ret; >> > + ? ? ret = (jz_read_bat(bat_ps) - pdata->min_voltag) * 100 >> > + ? ? ? ? ? ? / (pdata->max_voltag - pdata->min_voltag); >> > + ? ? if (ret > 100) { >> > + ? ? ? ? ? ? dev_warn(bat_ps->dev, "%s: capacity=%d which exceeds 100," >> > + ? ? ? ? ? ? ? ? ? ? ?"set to 100\n", __func__, ret); >> > + ? ? ? ? ? ? ret = 100; >> > + ? ? } >> > + ? ? return ret; >> > +} >> > + >> > ?static int jz_bat_get_property(struct power_supply *bat_ps, >> > ? ? ? ? ? ? ? ? ? ? ? ? ? enum power_supply_property psp, >> > ? ? ? ? ? ? ? ? ? ? ? ? ? union power_supply_propval *val) >> > @@ -108,40 +113,37 @@ static int jz_bat_get_property(struct power_supply *bat_ps, >> > ? ? ? ? ? ? ? val->intval = bat_status; >> > ? ? ? ? ? ? ? break; >> > ? ? ? case POWER_SUPPLY_PROP_TECHNOLOGY: >> > - ? ? ? ? ? ? val->intval = POWER_SUPPLY_TECHNOLOGY_LIPO; >> > + ? ? ? ? ? ? val->intval = pdata->batt_tech; >> > ? ? ? ? ? ? ? break; >> > ? ? ? case POWER_SUPPLY_PROP_HEALTH: >> > - ? ? ? ? ? ? if(jz_read_bat(bat_ps) < 3600000) { >> > - ? ? ? ? ? ? ? ? ? ? dprintk("--battery dead\n"); >> > + ? ? ? ? ? ? if(jz_read_bat(bat_ps) < JZ_BAT_MIN_VOLTAGE) { >> > + ? ? ? ? ? ? ? ? ? ? dev_dbg(bat_ps->dev, "%s: battery is dead," >> > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? "voltage too low!\n", __func__); >> > ? ? ? ? ? ? ? ? ? ? ? val->intval = POWER_SUPPLY_HEALTH_DEAD; >> > ? ? ? ? ? ? ? } else { >> > - ? ? ? ? ? ? ? ? ? ? dprintk("--battery good\n"); >> > + ? ? ? ? ? ? ? ? ? ? dev_dbg(bat_ps->dev, "%s: battery is good," >> > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? "voltage normal.\n", __func__); >> > ? ? ? ? ? ? ? ? ? ? ? val->intval = POWER_SUPPLY_HEALTH_GOOD; >> > ? ? ? ? ? ? ? } >> > ? ? ? ? ? ? ? break; >> > ? ? ? case POWER_SUPPLY_PROP_CAPACITY: >> > - ? ? ? ? ? ? val->intval = (jz_read_bat(bat_ps) - 3600000) * 100 / (4200000 - 3600000); >> > - ? ? ? ? ? ? if (val->intval > 100) >> > - ? ? ? ? ? ? ? ? ? ? val->intval = 100; >> > - ? ? ? ? ? ? dprintk("--battery_capacity=%d\%\n",val->intval); >> > + ? ? ? ? ? ? val->intval = jz_bat_get_capacity(bat_ps); >> > + ? ? ? ? ? ? dev_dbg(bat_ps->dev, "%s: battery_capacity = %d\%\n", >> > + ? ? ? ? ? ? ? ? ? ? __func__, val->intval); >> > ? ? ? ? ? ? ? break; >> > ? ? ? case POWER_SUPPLY_PROP_VOLTAGE_NOW: >> > ? ? ? ? ? ? ? val->intval = jz_read_bat(bat_ps); >> > ? ? ? ? ? ? ? break; >> > ? ? ? case POWER_SUPPLY_PROP_VOLTAGE_MAX: >> > ? ? ? case POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN: >> > - ? ? ? ? ? ? val->intval = JZ_BAT_MAX_VOLTAGE; >> > + ? ? ? ? ? ? val->intval = pdata->max_voltag; >> > ? ? ? ? ? ? ? break; >> > ? ? ? case POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN: >> > - ? ? ? ? ? ? val->intval = JZ_BAT_MIN_VOLTAGE; >> > + ? ? ? ? ? ? val->intval = pdata->min_voltag; >> > ? ? ? ? ? ? ? break; >> > ? ? ? case POWER_SUPPLY_PROP_PRESENT: >> > ? ? ? ? ? ? ? val->intval = 1; >> > ? ? ? ? ? ? ? break; >> > - ? ? case POWER_SUPPLY_PROP_TEMP: >> > - ? ? case POWER_SUPPLY_PROP_VOL: >> > - ? ? ? ? ? ? val->intval = 0; // reading TEMP and VOL aren't supported >> > - ? ? ? ? ? ? break; >> > ? ? ? default: >> > ? ? ? ? ? ? ? return -EINVAL; >> > ? ? ? } >> > @@ -168,18 +170,21 @@ static void jz_bat_update(struct power_supply *bat_ps) >> > ? ? ? unsigned long batt_vol = jz_read_bat(bat_ps); >> > ? ? ? mutex_lock(&work_lock); >> > >> > - ? ? if(!__gpio_get_pin(GPIO_CHARG_STAT_N)) >> > + ? ? if(!gpio_get_value(pdata->charg_stat_pgio)) >> > ? ? ? ? ? ? ? bat_status = POWER_SUPPLY_STATUS_CHARGING; >> > - ? ? else { >> > + ? ? else >> > ? ? ? ? ? ? ? bat_status = POWER_SUPPLY_STATUS_NOT_CHARGING; >> > - ? ? } >> > >> > - ? ? dprintk("--battery status=%s\n", status_text[bat_status]); >> > + ? ? dev_dbg(bat_ps->dev, "%s: battery status=%s\n", >> > + ? ? ? ? ? ? __func__, status_text[bat_status]); >> > + >> > ? ? ? if ((old_status != bat_status) || >> > ? ? ? ? ? (old_batt_vol - batt_vol > 50000)) { >> > - ? ? ? ? ? ? pr_debug("%s %s -> %s\n", bat_ps->name, >> > - ? ? ? ? ? ? ? ? ? ? ? ? ? ? status_text[old_status], >> > - ? ? ? ? ? ? ? ? ? ? ? ? ? ? status_text[bat_status]); >> > + ? ? ? ? ? ? dev_dbg(bat_ps->dev, "%s %s -> %s\n", >> > + ? ? ? ? ? ? ? ? ? ? ?bat_ps->name, >> > + ? ? ? ? ? ? ? ? ? ? ?status_text[old_status], >> > + ? ? ? ? ? ? ? ? ? ? ?status_text[bat_status]); >> > + >> > ? ? ? ? ? ? ? power_supply_changed(bat_ps); >> > ? ? ? } >> > >> > @@ -196,8 +201,6 @@ static enum power_supply_property jz_bat_main_props[] = { >> > ? ? ? POWER_SUPPLY_PROP_VOLTAGE_MAX, >> > ? ? ? POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN, >> > ? ? ? POWER_SUPPLY_PROP_PRESENT, >> > - ? ? POWER_SUPPLY_PROP_TEMP, >> > - ? ? POWER_SUPPLY_PROP_VOL, >> > ?}; >> > >> > ?struct power_supply bat_ps = { >> > @@ -212,7 +215,8 @@ struct power_supply bat_ps = { >> > >> > ?static void jz_bat_work(struct work_struct *work) >> > ?{ >> > - ? ? const int interval = HZ * 6; >> > + ? ? /* query interval too small will increase system workload*/ >> > + ? ? const int interval = HZ * 30; >> > >> > ? ? ? jz_bat_update(&bat_ps); >> > ? ? ? queue_delayed_work(monitor_wqueue, &bat_work, interval); >> > @@ -242,12 +246,47 @@ static int jz_bat_resume(struct platform_device *dev) >> > ?static int __devinit jz_bat_probe(struct platform_device *dev) >> > ?{ >> > ? ? ? int ret = 0; >> > + >> > ? ? ? printk("JZ battery init.\n"); >> > ? ? ? mutex_init(&work_lock); >> > - >> > ? ? ? INIT_DELAYED_WORK(&bat_work, jz_bat_work); >> > >> > - ? ? __gpio_disable_pull(GPIO_USB_DETE); >> > + ? ? if (!dev->dev->platform_data) { >> > + ? ? ? ? ? ? dev_error(&dev->dev, "Please set battery info\n"); >> > + ? ? ? ? ? ? return -EINVAL; >> > + ? ? } >> > + >> > + ? ? pdata = dev->dev->platform_data; >> > + >> > + ? ? if (pdata->dc_dect_gpio >= 0 && gpio_is_valid(pdata->dc_dect_gpio)) { >> > + ? ? ? ? ? ? ret = gpio_request(pdata->dc_dect_gpio, "AC/DC DECT"); >> > + ? ? ? ? ? ? if (ret) >> > + ? ? ? ? ? ? ? ? ? ? goto err_dc_gpio_request; >> > + ? ? ? ? ? ? ret = gpio_direction_input(pdata->dc_dect_gpio); >> > + ? ? ? ? ? ? if (ret) >> > + ? ? ? ? ? ? ? ? ? ? goto err_dc_gpio_direction; >> > + ? ? } >> > + >> > + ? ? if (pdata->usb_dect_gpio >= 0 && gpio_is_valid(pdata->usb_dect_gpio)) { >> > + ? ? ? ? ? ? ret = gpio_request(pdata->usb_dect_gpio, "USB DECT"); >> > + ? ? ? ? ? ? if (ret) >> > + ? ? ? ? ? ? ? ? ? ? goto err_usb_gpio_request; >> > + ? ? ? ? ? ? ret = gpio_direction_input(pdata->usb_dect_gpio); >> > + ? ? ? ? ? ? if (ret) >> > + ? ? ? ? ? ? ? ? ? ? goto err_usb_gpio_direction; >> > + >> > + ? ? ? ? ? ? jz_gpio_disable_pullup(pdata->usb_dect_gpio); >> > + ? ? ? ? ? ? /* TODO: Use generic gpio is better */ >> > + ? ? } >> > + >> > + ? ? if (pdata->charg_stat_gpio >= 0 && gpio_is_valid(pdata->charg_stat_gpio)) { >> > + ? ? ? ? ? ? ret = gpio_request(pdata->charg_stat_gpio, "CHARG STAT"); >> > + ? ? ? ? ? ? if (ret) >> > + ? ? ? ? ? ? ? ? ? ? goto err_charg_gpio_request; >> > + ? ? ? ? ? ? ret = gpio_direction_input(pdata->charg_stat_pgio); >> > + ? ? ? ? ? ? if (ret) >> > + ? ? ? ? ? ? ? ? ? ? goto err_charg_gpio_direction; >> > + ? ? } >> > >> > ? ? ? power_supply_register(&dev->dev, &jz_ac); >> > ? ? ? power_supply_register(&dev->dev, &jz_usb); >> > @@ -262,10 +301,37 @@ static int __devinit jz_bat_probe(struct platform_device *dev) >> > ? ? ? } >> > >> > ? ? ? return ret; >> > + >> > +err_charg_gpio_direction >> > + ? ? dev_err(dev->dev, "charger state gpio set direction failed.\n"); >> > + ? ? gpio_free(pdata->charg_stat_pgio); >> > +err_charg_gpio_request: >> > + ? ? dev_err(dev->dev, "charger state gpio request failed.\n"); >> > +err_usb_gpio_direction: >> > + ? ? dev_err(dev->dev, "usb dect gpio set direction failed.\n"); >> > + ? ? gpio_free(pdata->usb_dect_gpio); >> > +err_usb_gpio_request: >> > + ? ? dev_err(dev->dev, "usb dect gpio request failed.\n"); >> > +err_dc_gpio_direction: >> > + ? ? dev_err(dev->dev, "ac/dc dect gpio request failed.\n"); >> > + ? ? gpio_free(pdata->dc_dect_gpio); >> > +err_err_dc_gpio_request: >> > + ? ? dev_err(dev->dev, "ac/dc dect gpio request failed.\n"); >> > + ? ? return ret; >> > + >> > ?} >> > >> > ?static int __devexit jz_bat_remove(struct platform_device *dev) >> > ?{ >> > + ? ? if (pdata) { >> > + ? ? ? ? if (pdata->dc_dect_gpio >= 0) >> > + ? ? ? ? ? ? ? ? gpio_free(pdata->dc_dect_gpio); >> > + ? ? ? ? if (pdata->usb_dect_gpio >= 0) >> > + ? ? ? ? ? ? ? ? gpio_free(pdata->usb_dect_pgio); >> > + ? ? ? ? if (pdata->charg_stat_gpio >= 0) >> > + ? ? ? ? ? ? ? ? gpio_free(pdata->charg_stat_gpio); >> > + ? ? } >> > + >> > ? ? ? power_supply_unregister(&bat_ps); >> > ? ? ? return 0; >> > ?} >> > diff --git a/target/linux/xburst/files-2.6.31/include/linux/jz4740_batt.h b/target/linux/xburst/files-2.6.31/include/linux/jz4740_batt.h >> > new file mode 100644 >> > index 0000000..bef9412 >> > --- /dev/null >> > +++ b/target/linux/xburst/files-2.6.31/include/linux/jz4740_batt.h >> > @@ -0,0 +1,27 @@ >> > +/* >> > + * ?Copyright (C) 2009, Jiejing Zhang >> > + * >> > + * ?This program is free software; you can redistribute ? ? ? it and/or modify it >> > + * ?under ?the terms of ? ? ? the GNU General ?Public License as published by the >> > + * ?Free Software Foundation; ?either version 2 of the ? ? ? License, or (at your >> > + * ?option) any later version. >> > + * >> > + * ?You should have received a copy of the ?GNU General Public License along >> > + * ?with this program; if not, write ?to the Free Software Foundation, Inc., >> > + * ?675 Mass Ave, Cambridge, MA 02139, USA. >> > + * >> > + */ >> > + >> > +#ifndef JZ4740_BATT_H >> > +#define JZ4740_BATT_H >> > + >> > +struct jz_batt_info { >> > + ? ? int dc_dect_gpio; ? ? ? /* GPIO port of DC charger detection */ >> > + ? ? int usb_dect_gpio; ? ? ?/* GPIO port of USB charger detection */ >> > + ? ? int charg_stat_gpio; ? ?/* GPIO port of Charger state */ >> > + >> > + ? ? int min_voltag; ? ? ? ? /* Mininal battery voltage in uV */ >> > + ? ? int max_voltag; ? ? ? ? /* Maximum battery voltage in uV */ >> > + ? ? int batt_tech; ? ? ? ? ?/* Battery technoledge */ >> > +}; >> > +#endif >> > diff --git a/target/linux/xburst/files-2.6.31/include/linux/jz4740_fb.h b/target/linux/xburst/files-2.6.31/include/linux/jz4740_fb.h >> > index 778e1e9..50a89ff 100644 >> > --- a/target/linux/xburst/files-2.6.31/include/linux/jz4740_fb.h >> > +++ b/target/linux/xburst/files-2.6.31/include/linux/jz4740_fb.h >> > @@ -12,6 +12,9 @@ >> > ? * >> > ? */ >> > >> > +#ifndef JZ4740_FB_H >> > +#define JZ4740_FB_H >> > + >> > ?#include >> > >> > ?enum jz4740_fb_lcd_type { >> > @@ -45,3 +48,5 @@ struct jz4740_fb_platform_data { >> > ? ? ? int bpp; >> > ? ? ?enum jz4740_fb_lcd_type lcd_type; >> > ?}; >> > + >> > +#endif >> >> >> _______________________________________________ >> Qi Developer Mailing List >> Mail to list (members only): developer at lists.qi-hardware.com >> Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > From xiangfu at qi-hardware.com Mon Sep 21 13:13:13 2009 From: xiangfu at qi-hardware.com (Xiangfu Liu) Date: Tue, 22 Sep 2009 01:13:13 +0800 Subject: nand jffs2 notice message Message-ID: <4AB7B429.1090704@qi-hardware.com> Hi sometimes I got those message[1] form serial console, anyone got those message? [1]-- correct: 0x7aca -> 0x6aca error_count: 1 20000019 correct: 0x7aca -> 0x6aca error_count: 1 20000019 correct: 0x7aca -> 0x6aca JFFS2 notice: (388) check_node_data: wrong data CRC in data node at 0x1704edf4:. error_count: 1 20000019 correct: 0x4f14 -> 0x4f10 JFFS2 notice: (388) check_node_data: wrong data CRC in data node at 0x17036cb4:. error_count: 1 20000019 correct: 0x4f14 -> 0x4f10 From xiangfu at qi-hardware.com Mon Sep 21 14:05:38 2009 From: xiangfu at qi-hardware.com (Xiangfu Liu) Date: Tue, 22 Sep 2009 02:05:38 +0800 Subject: [PATCH] jz battery driver cleanup In-Reply-To: References: <1253386006-19505-1-git-send-email-kzjeef@gmail.com> <4AB703A2.60401@qi-hardware.com> Message-ID: <4AB7C072.5090406@qi-hardware.com> Hi Applied, thanks. I made some change: -- -#define JZ_BAT_MAX_VOLTAGE 4200000 -#define JZ_BAT_MIN_VOLTAGE 3600000 static struct jz_batt_info jz_batt_gpio_platform_data = { .dc_dect_gpio = GPIO_DC_DETE_N, .usb_dect_gpio = GPIO_USB_DETE, .charg_stat_gpio = GPIO_CHARG_STAT_N, - .min_voltag = JZ_BAT_MIN_VOLTAGE, - .max_voltag = JZ_BAT_MAX_VOLTAGE, + .min_voltag = 3600000, + .max_voltag = 4200000, .batt_tech = POWER_SUPPLY_TECHNOLOGY_LIPO, }; ZhangJieJing wrote: > This patch is cleanup more about gpio and platform data. > > Signed-off-by: Jiejing.Zhang > --- > .../files-2.6.31/arch/mips/jz4740/platform.c | 23 +++ > .../xburst/files-2.6.31/drivers/power/jz_battery.c | 185 +++++++++++++++----- > 2 files changed, 163 insertions(+), 45 deletions(-) From lars at metafoo.de Mon Sep 21 14:12:03 2009 From: lars at metafoo.de (Lars-Peter Clausen) Date: Mon, 21 Sep 2009 20:12:03 +0200 Subject: [PATCH] jz battery driver cleanup In-Reply-To: <4AB7C072.5090406@qi-hardware.com> References: <1253386006-19505-1-git-send-email-kzjeef@gmail.com> <4AB703A2.60401@qi-hardware.com> <4AB7C072.5090406@qi-hardware.com> Message-ID: <4AB7C1F3.7000806@metafoo.de> > Hi > > Applied, thanks. Next time please check that it does at least compile... - Lars > Hi > > Applied, thanks. Next time please check that it does at least compile... - Lars From lars at metafoo.de Mon Sep 21 18:14:29 2009 From: lars at metafoo.de (Lars-Peter Clausen) Date: Tue, 22 Sep 2009 00:14:29 +0200 Subject: [PATCH] jz battery driver cleanup In-Reply-To: References: <1253386006-19505-1-git-send-email-kzjeef@gmail.com> <4AB703A2.60401@qi-hardware.com> Message-ID: <4AB7FAC5.2090301@metafoo.de> Hi I've fixed the compile error of the driver and did some other smaller cleanups. But there are still some issues with the driver. It would be nice if you could send a follow up patch which addresses these. - Lars > This patch is cleanup more about gpio and platform data. > > Signed-off-by: Jiejing.Zhang > --- > > diff --git a/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c > b/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c > index 80b3747..2d74d75 100755 > --- a/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c > +++ b/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c > @@ -6,6 +6,7 @@ > * based on tosa_battery.c > * > * Copyright (C) 2008 Marek Vasut > + * Copyright (C) 2009 Jiejing Zhang > * > * This program is free software; you can redistribute it and/or modify > * it under the terms of the GNU General Public License version 2 as > @@ -19,28 +20,19 @@ > #include > #include > #include > +#include > > #include > > -#ifdef CONFIG_POWER_SUPPLY_DEBUG > -#define dprintk(x...) printk(x) > -#else > -#define dprintk(x...) while(0){} > -#endif > - > -#define JZ_BAT_MAX_VOLTAGE 4200000 // uV > -#define JZ_BAT_MIN_VOLTAGE 3600000 > - > -static DEFINE_MUTEX(bat_lock); > struct workqueue_struct *monitor_wqueue; > struct delayed_work bat_work; > struct mutex work_lock; > > -int bat_status = POWER_SUPPLY_STATUS_DISCHARGING; > +static int bat_status = POWER_SUPPLY_STATUS_DISCHARGING; > +static struct jz_batt_info *pdata = 0; All these global variables should be put into a driver data struct. > > extern unsigned int jz_read_battery(void); > > - > /********************************************************************* > * Power > *********************************************************************/ > @@ -52,9 +44,9 @@ static int jz_get_power_prop(struct power_supply *psy, > switch (psp) { > case POWER_SUPPLY_PROP_ONLINE: > if (psy->type == POWER_SUPPLY_TYPE_MAINS) > - val->intval = !__gpio_get_pin(GPIO_DC_DETE_N); > + val->intval = !gpio_get_value(pdata->dc_dect_gpio); You use the gpio even though it might not have been valid. If the gpio is not valid the power supply should not be registered. > else > - val->intval = __gpio_get_pin(GPIO_USB_DETE); > + val->intval = !!gpio_get_value(pdata->usb_dect_gpio); dito > break; > default: > return -EINVAL; > @@ -92,13 +84,26 @@ static unsigned long jz_read_bat(struct > power_supply *bat_ps) > { > unsigned long val; > if (CFG_PBAT_DIV == 1) > - val = (((unsigned long long)jz_read_battery() * 7500000)) >> 12; > + val = (((unsigned long long)jz_read_battery() * 7500000L) >> 12) + 33000L; > else > - val = (((unsigned long long)jz_read_battery() * CFG_PBAT_DIV * > 2500000)) >> 12; > - dprintk("--raw_batter_vol=%d uV\n", val); > + val = ((unsigned long long)jz_read_battery() * CFG_PBAT_DIV * > 2500000L) >> 12; > + dev_dbg(bat_ps->dev, "%s: raw_batter_vol = %d uV\n",__func__,val); > return val; > } > > +static int jz_bat_get_capacity(struct power_supply *bat_ps) > +{ > + int ret; > + ret = (jz_read_bat(bat_ps) - pdata->min_voltag) * 100 > + / (pdata->max_voltag - pdata->min_voltag); > + if (ret > 100) { > + dev_warn(bat_ps->dev, "%s: capacity=%d which exceeds 100," > + "set to 100\n", __func__, ret); > + ret = 100; > + } > + return ret; > +} > + > static int jz_bat_get_property(struct power_supply *bat_ps, > enum power_supply_property psp, > union power_supply_propval *val) > @@ -108,40 +113,37 @@ static int jz_bat_get_property(struct > power_supply *bat_ps, > val->intval = bat_status; > break; > case POWER_SUPPLY_PROP_TECHNOLOGY: > - val->intval = POWER_SUPPLY_TECHNOLOGY_LIPO; > + val->intval = pdata->batt_tech; > break; > case POWER_SUPPLY_PROP_HEALTH: > - if(jz_read_bat(bat_ps) < 3600000) { > - dprintk("--battery dead\n"); > + if(jz_read_bat(bat_ps) < JZ_BAT_MIN_VOLTAGE) { > + dev_dbg(bat_ps->dev, "%s: battery is dead," > + "voltage too low!\n", __func__); > val->intval = POWER_SUPPLY_HEALTH_DEAD; > } else { > - dprintk("--battery good\n"); > + dev_dbg(bat_ps->dev, "%s: battery is good," > + "voltage normal.\n", __func__); > val->intval = POWER_SUPPLY_HEALTH_GOOD; > } > break; > case POWER_SUPPLY_PROP_CAPACITY: > - val->intval = (jz_read_bat(bat_ps) - 3600000) * 100 / (4200000 - 3600000); > - if (val->intval > 100) > - val->intval = 100; > - dprintk("--battery_capacity=%d\%\n",val->intval); > + val->intval = jz_bat_get_capacity(bat_ps); > + dev_dbg(bat_ps->dev, "%s: battery_capacity = %d\%\n", > + __func__, val->intval); > break; > case POWER_SUPPLY_PROP_VOLTAGE_NOW: > val->intval = jz_read_bat(bat_ps); > break; > case POWER_SUPPLY_PROP_VOLTAGE_MAX: > case POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN: > - val->intval = JZ_BAT_MAX_VOLTAGE; > + val->intval = pdata->max_voltag; > break; > case POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN: > - val->intval = JZ_BAT_MIN_VOLTAGE; > + val->intval = pdata->min_voltag; > break; > case POWER_SUPPLY_PROP_PRESENT: > val->intval = 1; > break; > - case POWER_SUPPLY_PROP_TEMP: > - case POWER_SUPPLY_PROP_VOL: > - val->intval = 0; // reading TEMP and VOL aren't supported > - break; > default: > return -EINVAL; > } > @@ -168,18 +170,21 @@ static void jz_bat_update(struct power_supply *bat_ps) > unsigned long batt_vol = jz_read_bat(bat_ps); > mutex_lock(&work_lock); > > - if(!__gpio_get_pin(GPIO_CHARG_STAT_N)) > + if(!gpio_get_value(pdata->charg_stat_pgio)) > bat_status = POWER_SUPPLY_STATUS_CHARGING; > - else { > + else > bat_status = POWER_SUPPLY_STATUS_NOT_CHARGING; > - } Again, don't use the gpio if it's not valid. > > - dprintk("--battery status=%s\n", status_text[bat_status]); > + dev_dbg(bat_ps->dev, "%s: battery status=%s\n", > + __func__, status_text[bat_status]); > + > if ((old_status != bat_status) || > (old_batt_vol - batt_vol > 50000)) { > - pr_debug("%s %s -> %s\n", bat_ps->name, > - status_text[old_status], > - status_text[bat_status]); > + dev_dbg(bat_ps->dev, "%s %s -> %s\n", > + bat_ps->name, > + status_text[old_status], > + status_text[bat_status]); > + > power_supply_changed(bat_ps); > } > > @@ -196,8 +201,6 @@ static enum power_supply_property jz_bat_main_props[] = { > POWER_SUPPLY_PROP_VOLTAGE_MAX, > POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN, > POWER_SUPPLY_PROP_PRESENT, > - POWER_SUPPLY_PROP_TEMP, > - POWER_SUPPLY_PROP_VOL, > }; > > struct power_supply bat_ps = { > @@ -212,7 +215,8 @@ struct power_supply bat_ps = { > > static void jz_bat_work(struct work_struct *work) > { > - const int interval = HZ * 6; > + /* query interval too small will increase system workload*/ > + const int interval = HZ * 30; > > jz_bat_update(&bat_ps); > queue_delayed_work(monitor_wqueue, &bat_work, interval); > @@ -242,17 +246,81 @@ static int jz_bat_resume(struct platform_device *dev) > static int __devinit jz_bat_probe(struct platform_device *dev) > { > int ret = 0; > + > printk("JZ battery init.\n"); > mutex_init(&work_lock); > - > INIT_DELAYED_WORK(&bat_work, jz_bat_work); > > - __gpio_disable_pull(GPIO_USB_DETE); > + if (!dev->dev->platform_data) { > + dev_error(&dev->dev, "Please set battery info\n"); > + return -EINVAL; > + } > + > + pdata = dev->dev->platform_data; > > - power_supply_register(&dev->dev, &jz_ac); > - power_supply_register(&dev->dev, &jz_usb); > + if (gpio_is_valid(pdata->dc_dect_gpio)) { > + ret = gpio_request(pdata->dc_dect_gpio, "AC/DC DECT"); > + if (ret) { > + dev_err(dev->dev, "ac/dc dect gpio request failed.\n"); > + > + goto err_dc_gpio_request; > + } > + ret = gpio_direction_input(pdata->dc_dect_gpio); > + if (ret) { > + dev_err(dev->dev, "ac/dc dect gpio direction failed.\n"); > + > + goto err_dc_gpio_direction; > + } > + } > + > + if (gpio_is_valid(pdata->usb_dect_gpio)) { > + ret = gpio_request(pdata->usb_dect_gpio, "USB DECT"); > + if (ret) { > + dev_err(dev->dev, "usb dect gpio request failed.\n"); > + > + goto err_usb_gpio_request; > + } > + ret = gpio_direction_input(pdata->usb_dect_gpio); > + if (ret) { > + dev_err(dev->dev, "usb dect gpio set direction failed.\n"); > + goto err_usb_gpio_direction; > + } > + > + jz_gpio_disable_pullup(pdata->usb_dect_gpio); > + /* TODO: Use generic gpio is better */ > + } > + > + if (gpio_is_valid(pdata->charg_stat_gpio)) { > + ret = gpio_request(pdata->charg_stat_gpio, "CHARG STAT"); > + if (ret) { > + dev_err(dev->dev, "charger state gpio request failed.\n"); > + goto err_charg_gpio_request; > + } > + ret = gpio_direction_input(pdata->charg_stat_pgio); > + if (ret) { > + dev_err(dev->dev, "charger state gpio set direction failed.\n"); > + goto err_charg_gpio_direction; > + } > + } > + > + ret = power_supply_register(&dev->dev, &jz_ac); > + if (ret) { > + dev_err(dev->dev, "power supply ac/dc register failed.\n"); > + goto err_power_register_ac; > + } > + > + ret = power_supply_register(&dev->dev, &jz_usb); > + if (ret) { > + dev_err(dev->dev, "power supply usb register failed.\n"); > + goto err_power_register_usb; > + } > > ret = power_supply_register(&dev->dev, &bat_ps); > + if (ret) { > + dev_err(dev->dev, "power supply battery register failed.\n"); > + goto err_power_register_bat; > + } > + > if (!ret) { > monitor_wqueue = create_singlethread_workqueue("jz_battery"); > if (!monitor_wqueue) { > @@ -262,11 +330,38 @@ static int __devinit jz_bat_probe(struct > platform_device *dev) > } > > return ret; > + > +err_power_register_bat: > + power_supply_unregister(&jz_usb); > +err_power_register_usb: > + power_supply_unregister(&jz_ac); > +err_power_register_ac: > +err_charg_gpio_direction: > + gpio_free(pdata->charg_stat_pgio); > +err_charg_gpio_request: > +err_usb_gpio_direction: > + gpio_free(pdata->usb_dect_gpio); > +err_usb_gpio_request: > +err_dc_gpio_direction: > + gpio_free(pdata->dc_dect_gpio); > +err_err_dc_gpio_request: > + return ret; > } > > static int __devexit jz_bat_remove(struct platform_device *dev) > { > + if (pdata) { > + if (gpio_is_valid(pdata->dc_dct_gpio)) > + gpio_free(pdata->dc_dect_gpio); > + if (gpio_is_valid(pdata->usb_dect_gpio)) > + gpio_free(pdata->usb_dect_pgio); > + if (gpio_is_valid(pdata->charg_stat_gpio)) > + gpio_free(pdata->charg_stat_gpio); > + } > + > power_supply_unregister(&bat_ps); > + power_supply_unregister(&jz_ac); > + power_supply_unregister(&jz_usb); > return 0; > } > > From cicamargoba at gmail.com Mon Sep 21 20:04:30 2009 From: cicamargoba at gmail.com (Carlos Camargo) Date: Mon, 21 Sep 2009 19:04:30 -0500 Subject: Kernel drivers Message-ID: <19ebea720909211704w66fb0d13jc86c37a21d7b1ecc@mail.gmail.com> Hi I'm trying to build an image kernel with sound and keyboard support. I'm using openwrt, and qi-kernel, The compilation process run successfully and I can upload the kernel images to NAND flash using usbboot. , but I have some problems: (I'm using root on mmc) 1. When I run a command the console hangs and don't works again. 2. I've already compiled alsa-libs, alsa-utils and mplayer (from ingenic ftp) using openwrt toolchain. When I'm trying to use aplay, or mplayer the console hangs 3. I can't start a usb network connection with Nano, The ping from/to Nano works, but ssh not. 4. dmesg shows a lot of MMC commands. so we can't see the driver message, I think that the best choice would be disble the mmc debug messages. 5. some times the console hangs on: Press CTRL_C for failsafe, and we need reboot some times for get a console. The keyboard driver works fine. Best Regards -- Carlos Iv?n Camargo Bare?o Profesor Asistente Departamento de Ingenier?a El?ctrica y Electr?nica Universidad Nacional de Colombia cicamargoba at unal.edu.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From kzjeef at gmail.com Mon Sep 21 23:38:37 2009 From: kzjeef at gmail.com (ZhangJieJing) Date: Tue, 22 Sep 2009 11:38:37 +0800 Subject: nand jffs2 notice message In-Reply-To: <4AB7B429.1090704@qi-hardware.com> References: <4AB7B429.1090704@qi-hardware.com> Message-ID: Hi, I goto too. > correct: 0x7aca -> 0x6aca this message is NAND ECC correction, and success corrected by NAND ECC. I think this is fine, Lars maybe know more about this. > JFFS2 notice: (388) check_node_data: wrong data CRC in data node at 0x1704edf4:. I don't know much about this JFFS2 notice. --- Best regards, Zhang Jiejing On Tue, Sep 22, 2009 at 1:13 AM, Xiangfu Liu wrote: > Hi > > sometimes I got those message[1] form serial console, > anyone got those message? > > > [1]-- > correct: 0x7aca -> 0x6aca > error_count: 1 20000019 > correct: 0x7aca -> 0x6aca > error_count: 1 20000019 > correct: 0x7aca -> 0x6aca > JFFS2 notice: (388) check_node_data: wrong data CRC in data node at 0x1704edf4:. > error_count: 1 20000019 > correct: 0x4f14 -> 0x4f10 > JFFS2 notice: (388) check_node_data: wrong data CRC in data node at 0x17036cb4:. > error_count: 1 20000019 > correct: 0x4f14 -> 0x4f10 > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiangfu at qi-hardware.com Mon Sep 21 23:53:23 2009 From: xiangfu at qi-hardware.com (Xiangfu Liu) Date: Tue, 22 Sep 2009 11:53:23 +0800 Subject: [PATCH] jz battery driver cleanup In-Reply-To: <4AB7C1F3.7000806@metafoo.de> References: <1253386006-19505-1-git-send-email-kzjeef@gmail.com> <4AB703A2.60401@qi-hardware.com> <4AB7C072.5090406@qi-hardware.com> <4AB7C1F3.7000806@metafoo.de> Message-ID: <4AB84A33.8070402@qi-hardware.com> Hi Lars-Peter Clausen wrote: >> Hi >> >> Applied, thanks. > Next time please check that it does at least compile... > > - Lars >> Hi >> >> Applied, thanks. > Next time please check that it does at least compile... > will more carefully :-) > - Lars > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer From kzjeef at gmail.com Tue Sep 22 00:01:11 2009 From: kzjeef at gmail.com (ZhangJieJing) Date: Tue, 22 Sep 2009 12:01:11 +0800 Subject: [PATCH] jz battery driver cleanup In-Reply-To: <4AB84A33.8070402@qi-hardware.com> References: <1253386006-19505-1-git-send-email-kzjeef@gmail.com> <4AB703A2.60401@qi-hardware.com> <4AB7C072.5090406@qi-hardware.com> <4AB7C1F3.7000806@metafoo.de> <4AB84A33.8070402@qi-hardware.com> Message-ID: Hi, On Tue, Sep 22, 2009 at 11:53 AM, Xiangfu Liu wrote: > Hi > Lars-Peter Clausen wrote: > >> Hi > >> > >> Applied, thanks. > > Next time please check that it does at least compile... > > > > - Lars > >> Hi > >> > >> Applied, thanks. > > Next time please check that it does at least compile... > > > > will more carefully :-) > Me too. :) > > > - Lars > > > > _______________________________________________ > > Qi Developer Mailing List > > Mail to list (members only): developer at lists.qi-hardware.com > > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kzjeef at gmail.com Tue Sep 22 00:04:56 2009 From: kzjeef at gmail.com (ZhangJieJing) Date: Tue, 22 Sep 2009 12:04:56 +0800 Subject: [PATCH] jz battery driver cleanup In-Reply-To: <4AB7FAC5.2090301@metafoo.de> References: <1253386006-19505-1-git-send-email-kzjeef@gmail.com> <4AB703A2.60401@qi-hardware.com> <4AB7FAC5.2090301@metafoo.de> Message-ID: Hi lars, thanks you for your advice, On Tue, Sep 22, 2009 at 6:14 AM, Lars-Peter Clausen wrote: > Hi > > I've fixed the compile error of the driver and did some other smaller > cleanups. > But there are still some issues with the driver. It would be nice if you > could send a follow up patch which addresses these. > > - Lars > > > This patch is cleanup more about gpio and platform data. > > > > Signed-off-by: Jiejing.Zhang > > --- > > > > diff --git a/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c > > b/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c > > index 80b3747..2d74d75 100755 > > --- a/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c > > +++ b/target/linux/xburst/files-2.6.31/drivers/power/jz_battery.c > > @@ -6,6 +6,7 @@ > > * based on tosa_battery.c > > * > > * Copyright (C) 2008 Marek Vasut > > + * Copyright (C) 2009 Jiejing Zhang > > * > > * This program is free software; you can redistribute it and/or modify > > * it under the terms of the GNU General Public License version 2 as > > @@ -19,28 +20,19 @@ > > #include > > #include > > #include > > +#include > > > > #include > > > > -#ifdef CONFIG_POWER_SUPPLY_DEBUG > > -#define dprintk(x...) printk(x) > > -#else > > -#define dprintk(x...) while(0){} > > -#endif > > - > > -#define JZ_BAT_MAX_VOLTAGE 4200000 // uV > > -#define JZ_BAT_MIN_VOLTAGE 3600000 > > - > > -static DEFINE_MUTEX(bat_lock); > > struct workqueue_struct *monitor_wqueue; > > struct delayed_work bat_work; > > struct mutex work_lock; > > > > -int bat_status = POWER_SUPPLY_STATUS_DISCHARGING; > > +static int bat_status = POWER_SUPPLY_STATUS_DISCHARGING; > > +static struct jz_batt_info *pdata = 0; > All these global variables should be put into a driver data struct. > I put them in and jz_battery_info structure, and with a global static struct ? Is this OK? the patch will send later, since for now, adc driver missing some header files, I cann't compile it. > > > > extern unsigned int jz_read_battery(void); > > > > - > > /********************************************************************* > > * Power > > *********************************************************************/ > > @@ -52,9 +44,9 @@ static int jz_get_power_prop(struct power_supply *psy, > > switch (psp) { > > case POWER_SUPPLY_PROP_ONLINE: > > if (psy->type == POWER_SUPPLY_TYPE_MAINS) > > - val->intval = !__gpio_get_pin(GPIO_DC_DETE_N); > > + val->intval = !gpio_get_value(pdata->dc_dect_gpio); > You use the gpio even though it might not have been valid. If the gpio > is not valid the power supply should not be registered. > you are right, I add the check before using these gpio in new patch. -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiangfu at qi-hardware.com Tue Sep 22 04:36:37 2009 From: xiangfu at qi-hardware.com (Xiangfu Liu) Date: Tue, 22 Sep 2009 16:36:37 +0800 Subject: Kernel drivers In-Reply-To: <19ebea720909211704w66fb0d13jc86c37a21d7b1ecc@mail.gmail.com> References: <19ebea720909211704w66fb0d13jc86c37a21d7b1ecc@mail.gmail.com> Message-ID: <4AB88C95.30608@qi-hardware.com> Hi try use the nand rootfs sudo usbboot -c "nprog 2048 /PATCH/TO/OPENWRT-XBURST/ROOTFS-512 0 0 -n" I will try the rootfs on mmc later. Carlos Camargo wrote: > Hi > > I'm trying to build an image kernel with sound and keyboard support. I'm > using openwrt, and qi-kernel, The compilation process run successfully > and I can upload the kernel images to NAND flash using usbboot. , but I > have some problems: (I'm using root on mmc) > > 1. When I run a command the console hangs and don't works again. > 2. I've already compiled alsa-libs, alsa-utils and mplayer (from ingenic > ftp) using openwrt toolchain. When I'm trying to use aplay, or mplayer > the console hangs > 3. I can't start a usb network connection with Nano, The ping from/to > Nano works, but ssh not. > 4. dmesg shows a lot of MMC commands. so we can't see the driver > message, I think that the best choice would be disble the mmc debug > messages. > 5. some times the console hangs on: Press CTRL_C for failsafe, and we > need reboot some times for get a console. > > The keyboard driver works fine. > > Best Regards > > > > -- > Carlos Iv?n Camargo Bare?o > Profesor Asistente > Departamento de Ingenier?a El?ctrica y Electr?nica > Universidad Nacional de Colombia > cicamargoba at unal.edu.co From xiangfu at qi-hardware.com Tue Sep 22 04:51:04 2009 From: xiangfu at qi-hardware.com (Xiangfu Liu) Date: Tue, 22 Sep 2009 16:51:04 +0800 Subject: Kernel drivers In-Reply-To: <19ebea720909211704w66fb0d13jc86c37a21d7b1ecc@mail.gmail.com> References: <19ebea720909211704w66fb0d13jc86c37a21d7b1ecc@mail.gmail.com> Message-ID: <4AB88FF8.5050501@qi-hardware.com> Hi Carlos I just try the mmc rootfs. same error here. only one time work fine. maybe something wrong with the mmc driver. you can use NAND rootfs first. Carlos Camargo wrote: > Hi > > I'm trying to build an image kernel with sound and keyboard support. I'm > using openwrt, and qi-kernel, The compilation process run successfully > and I can upload the kernel images to NAND flash using usbboot. , but I > have some problems: (I'm using root on mmc) > > 1. When I run a command the console hangs and don't works again. > 2. I've already compiled alsa-libs, alsa-utils and mplayer (from ingenic > ftp) using openwrt toolchain. When I'm trying to use aplay, or mplayer > the console hangs > 3. I can't start a usb network connection with Nano, The ping from/to > Nano works, but ssh not. > 4. dmesg shows a lot of MMC commands. so we can't see the driver > message, I think that the best choice would be disble the mmc debug > messages. > 5. some times the console hangs on: Press CTRL_C for failsafe, and we > need reboot some times for get a console. > > The keyboard driver works fine. > > Best Regards > > > > -- > Carlos Iv?n Camargo Bare?o > Profesor Asistente > Departamento de Ingenier?a El?ctrica y Electr?nica > Universidad Nacional de Colombia > cicamargoba at unal.edu.co From list at gcasse.net Tue Sep 22 06:36:56 2009 From: list at gcasse.net (Gilles Casse) Date: Tue, 22 Sep 2009 12:36:56 +0200 Subject: nand jffs2 notice message Message-ID: <12990.1253615816@gcasse.net> > > JFFS2 notice: (388) check_node_data: wrong data CRC in data node at > 0x1704edf4:. It can be due to a power off while this jffs2 node was beeing written. http://www.linux-mtd.infradead.org/faq/jffs2.html#L_messages At next boot, the warning appears and jffs2 is potentially able to restore the previous node. In case of doubt, the jffs2dump tool helps to check the jffs2 partition. Best regards, Gilles From kzjeef at gmail.com Tue Sep 22 06:37:57 2009 From: kzjeef at gmail.com (ZhangJieJing) Date: Tue, 22 Sep 2009 18:37:57 +0800 Subject: [PATCH] jz_battery: improve driver code. Message-ID: 1. put all gobal var to a driver info struct. 2. check gpio before use it. Signed-off-by: Jiejing.Zhang --- .../files-2.6.31/drivers/power/jz4740-battery.c | 139 ++++++++++++-------- 1 files changed, 81 insertions(+), 58 deletions(-) diff --git a/target/linux/xburst/files-2.6.31/drivers/power/jz4740-battery.c b/target/linux/xburst/files-2.6.31/drivers/power/jz4740-battery.c index de1f4e2..fccfc2e 100644 --- a/target/linux/xburst/files-2.6.31/drivers/power/jz4740-battery.c +++ b/target/linux/xburst/files-2.6.31/drivers/power/jz4740-battery.c @@ -23,16 +23,18 @@ #include #include -/*struct jz_battery {*/ - static int bat_status = POWER_SUPPLY_STATUS_DISCHARGING; - static struct jz_batt_info *pdata = 0; - +struct jz_battery_info { + int bat_status; + struct jz_batt_info *pdata; struct mutex work_lock; - struct workqueue_struct *monitor_wqueue; struct delayed_work bat_work; -/*};*/ +}; +static struct jz_battery_info jz_main_bat = { + .bat_status = POWER_SUPPLY_STATUS_DISCHARGING, + .pdata = 0, +}; /********************************************************************* * Power @@ -42,8 +44,13 @@ static int jz_get_power_prop(struct power_supply *psy, enum power_supply_property psp, union power_supply_propval *val) { - int gpio = (psy->type == POWER_SUPPLY_TYPE_MAINS) ? pdata->dc_dect_gpio : - pdata->usb_dect_gpio; + if (!jz_main_bat.pdata) + return -EINVAL; + int gpio = (psy->type == POWER_SUPPLY_TYPE_MAINS) ? jz_main_bat.pdata->dc_dect_gpio : jz_main_bat.pdata->usb_dect_gpio; + + if (!gpio_is_valid(gpio)) + return -EINVAL; + switch (psp) { case POWER_SUPPLY_PROP_ONLINE: val->intval = !gpio_get_value(gpio); @@ -83,7 +90,10 @@ static struct power_supply jz_usb = { static long jz_read_bat(struct power_supply *bat_ps) { enum jz_adc_battery_scale scale; - if (pdata->max_voltag > 2500000) + if (!jz_main_bat.pdata) + return -EINVAL; + + if (jz_main_bat.pdata->max_voltag > 2500000) scale = JZ_ADC_BATTERY_SCALE_7V5; else scale = JZ_ADC_BATTERY_SCALE_2V5; @@ -95,13 +105,16 @@ static int jz_bat_get_capacity(struct power_supply *bat_ps) { int ret; + if (!jz_main_bat.pdata) + return -EINVAL; + ret = jz_read_bat(bat_ps); if (ret < 0) return ret; - ret = (ret - pdata->min_voltag) * 100 - / (pdata->max_voltag - pdata->min_voltag); + ret = (ret - jz_main_bat.pdata->min_voltag) * 100 + / (jz_main_bat.pdata->max_voltag - jz_main_bat.pdata->min_voltag); if (ret > 100) ret = 100; @@ -115,15 +128,18 @@ static int jz_bat_get_property(struct power_supply *bat_ps, enum power_supply_property psp, union power_supply_propval *val) { + if (!jz_main_bat.pdata) + return -EINVAL; + switch (psp) { case POWER_SUPPLY_PROP_STATUS: - val->intval = bat_status; + val->intval = jz_main_bat.bat_status; break; case POWER_SUPPLY_PROP_TECHNOLOGY: - val->intval = pdata->batt_tech; + val->intval = jz_main_bat.pdata->batt_tech; break; case POWER_SUPPLY_PROP_HEALTH: - if(jz_read_bat(bat_ps) < pdata->min_voltag) { + if(jz_read_bat(bat_ps) < jz_main_bat.pdata->min_voltag) { dev_dbg(bat_ps->dev, "%s: battery is dead," "voltage too low!\n", __func__); val->intval = POWER_SUPPLY_HEALTH_DEAD; @@ -145,10 +161,10 @@ static int jz_bat_get_property(struct power_supply *bat_ps, break; case POWER_SUPPLY_PROP_VOLTAGE_MAX: case POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN: - val->intval = pdata->max_voltag; + val->intval = jz_main_bat.pdata->max_voltag; break; case POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN: - val->intval = pdata->min_voltag; + val->intval = jz_main_bat.pdata->min_voltag; break; case POWER_SUPPLY_PROP_PRESENT: val->intval = 1; @@ -161,8 +177,8 @@ static int jz_bat_get_property(struct power_supply *bat_ps, static void jz_bat_external_power_changed(struct power_supply *bat_ps) { - cancel_delayed_work(&bat_work); - queue_delayed_work(monitor_wqueue, &bat_work, HZ / 8); + cancel_delayed_work(&jz_main_bat.bat_work); + queue_delayed_work(jz_main_bat.monitor_wqueue, &jz_main_bat.bat_work, HZ / 8); } static char *status_text[] = { @@ -174,31 +190,38 @@ static char *status_text[] = { static void jz_bat_update(struct power_supply *bat_ps) { - int old_status = bat_status; + int old_status = jz_main_bat.bat_status; static unsigned long old_batt_vol = 0; unsigned long batt_vol = jz_read_bat(bat_ps); - mutex_lock(&work_lock); + mutex_lock(&jz_main_bat.work_lock); + + if (!jz_main_bat.pdata) + goto err; + + if (!gpio_is_valid(jz_main_bat.pdata->charg_stat_gpio)) + goto err; - if(!gpio_get_value(pdata->charg_stat_gpio)) - bat_status = POWER_SUPPLY_STATUS_CHARGING; + if(!gpio_get_value(jz_main_bat.pdata->charg_stat_gpio)) + jz_main_bat.bat_status = POWER_SUPPLY_STATUS_CHARGING; else - bat_status = POWER_SUPPLY_STATUS_NOT_CHARGING; + jz_main_bat.bat_status = POWER_SUPPLY_STATUS_NOT_CHARGING; dev_dbg(bat_ps->dev, "%s: battery status=%s\n", - __func__, status_text[bat_status]); + __func__, status_text[jz_main_bat.bat_status]); - if ((old_status != bat_status) || + if ((old_status != jz_main_bat.bat_status) || (old_batt_vol - batt_vol > 50000)) { dev_dbg(bat_ps->dev, "%s %s -> %s\n", bat_ps->name, status_text[old_status], - status_text[bat_status]); + status_text[jz_main_bat.bat_status]); power_supply_changed(bat_ps); } old_batt_vol = batt_vol; - mutex_unlock(&work_lock); +err: + mutex_unlock(&jz_main_bat.work_lock); } static enum power_supply_property jz_bat_main_props[] = { @@ -228,22 +251,22 @@ static void jz_bat_work(struct work_struct *work) const int interval = HZ * 30; jz_bat_update(&bat_ps); - queue_delayed_work(monitor_wqueue, &bat_work, interval); + queue_delayed_work(jz_main_bat.monitor_wqueue, &jz_main_bat.bat_work, interval); } #ifdef CONFIG_PM static int jz_bat_suspend(struct platform_device *dev, pm_message_t state) { - bat_status = POWER_SUPPLY_STATUS_UNKNOWN; + jz_main_bat.bat_status = POWER_SUPPLY_STATUS_UNKNOWN; return 0; } static int jz_bat_resume(struct platform_device *dev) { - bat_status = POWER_SUPPLY_STATUS_UNKNOWN; - cancel_delayed_work(&bat_work); - queue_delayed_work(monitor_wqueue, &bat_work, HZ/10); + jz_main_bat.bat_status = POWER_SUPPLY_STATUS_UNKNOWN; + cancel_delayed_work(&jz_main_bat.bat_work); + queue_delayed_work(jz_main_bat.monitor_wqueue, &jz_main_bat.bat_work, HZ/10); return 0; } @@ -257,24 +280,24 @@ static int __devinit jz_bat_probe(struct platform_device *pdev) int ret = 0; printk("JZ battery init.\n"); - mutex_init(&work_lock); - INIT_DELAYED_WORK(&bat_work, jz_bat_work); + mutex_init(&jz_main_bat.work_lock); + INIT_DELAYED_WORK(&jz_main_bat.bat_work, jz_bat_work); if (!pdev->dev.platform_data) { dev_err(&pdev->dev, "Please set battery info\n"); return -EINVAL; } - pdata = pdev->dev.platform_data; + jz_main_bat.pdata = pdev->dev.platform_data; - if (gpio_is_valid(pdata->dc_dect_gpio)) { - ret = gpio_request(pdata->dc_dect_gpio, "AC/DC DECT"); + if (gpio_is_valid(jz_main_bat.pdata->dc_dect_gpio)) { + ret = gpio_request(jz_main_bat.pdata->dc_dect_gpio, "AC/DC DECT"); if (ret) { dev_err(&pdev->dev, "ac/dc dect gpio request failed.\n"); goto err_dc_gpio_request; } - ret = gpio_direction_input(pdata->dc_dect_gpio); + ret = gpio_direction_input(jz_main_bat.pdata->dc_dect_gpio); if (ret) { dev_err(&pdev->dev, "ac/dc dect gpio direction failed.\n"); @@ -282,30 +305,30 @@ static int __devinit jz_bat_probe(struct platform_device *pdev) } } - if (gpio_is_valid(pdata->usb_dect_gpio)) { - ret = gpio_request(pdata->usb_dect_gpio, "USB DECT"); + if (gpio_is_valid(jz_main_bat.pdata->usb_dect_gpio)) { + ret = gpio_request(jz_main_bat.pdata->usb_dect_gpio, "USB DECT"); if (ret) { dev_err(&pdev->dev, "usb dect gpio request failed.\n"); goto err_usb_gpio_request; } - ret = gpio_direction_input(pdata->usb_dect_gpio); + ret = gpio_direction_input(jz_main_bat.pdata->usb_dect_gpio); if (ret) { dev_err(&pdev->dev, "usb dect gpio set direction failed.\n"); goto err_usb_gpio_direction; } - jz_gpio_disable_pullup(pdata->usb_dect_gpio); + jz_gpio_disable_pullup(jz_main_bat.pdata->usb_dect_gpio); /* TODO: Use generic gpio is better */ } - if (gpio_is_valid(pdata->charg_stat_gpio)) { - ret = gpio_request(pdata->charg_stat_gpio, "CHARG STAT"); + if (gpio_is_valid(jz_main_bat.pdata->charg_stat_gpio)) { + ret = gpio_request(jz_main_bat.pdata->charg_stat_gpio, "CHARG STAT"); if (ret) { dev_err(&pdev->dev, "charger state gpio request failed.\n"); goto err_charg_gpio_request; } - ret = gpio_direction_input(pdata->charg_stat_gpio); + ret = gpio_direction_input(jz_main_bat.pdata->charg_stat_gpio); if (ret) { dev_err(&pdev->dev, "charger state gpio set direction failed.\n"); goto err_charg_gpio_direction; @@ -331,11 +354,11 @@ static int __devinit jz_bat_probe(struct platform_device *pdev) } if (!ret) { - monitor_wqueue = create_singlethread_workqueue("jz_battery"); - if (!monitor_wqueue) { + jz_main_bat.monitor_wqueue = create_singlethread_workqueue("jz_battery"); + if (!jz_main_bat.monitor_wqueue) { return -ESRCH; } - queue_delayed_work(monitor_wqueue, &bat_work, HZ * 1); + queue_delayed_work(jz_main_bat.monitor_wqueue, &jz_main_bat.bat_work, HZ * 1); } return ret; @@ -346,26 +369,26 @@ err_power_register_usb: power_supply_unregister(&jz_ac); err_power_register_ac: err_charg_gpio_direction: - gpio_free(pdata->charg_stat_gpio); + gpio_free(jz_main_bat.pdata->charg_stat_gpio); err_charg_gpio_request: err_usb_gpio_direction: - gpio_free(pdata->usb_dect_gpio); + gpio_free(jz_main_bat.pdata->usb_dect_gpio); err_usb_gpio_request: err_dc_gpio_direction: - gpio_free(pdata->dc_dect_gpio); + gpio_free(jz_main_bat.pdata->dc_dect_gpio); err_dc_gpio_request: return ret; } static int __devexit jz_bat_remove(struct platform_device *dev) { - if (pdata) { - if (gpio_is_valid(pdata->dc_dect_gpio)) - gpio_free(pdata->dc_dect_gpio); - if (gpio_is_valid(pdata->usb_dect_gpio)) - gpio_free(pdata->usb_dect_gpio); - if (gpio_is_valid(pdata->charg_stat_gpio)) - gpio_free(pdata->charg_stat_gpio); + if (jz_main_bat.pdata) { + if (gpio_is_valid(jz_main_bat.pdata->dc_dect_gpio)) + gpio_free(jz_main_bat.pdata->dc_dect_gpio); + if (gpio_is_valid(jz_main_bat.pdata->usb_dect_gpio)) + gpio_free(jz_main_bat.pdata->usb_dect_gpio); + if (gpio_is_valid(jz_main_bat.pdata->charg_stat_gpio)) + gpio_free(jz_main_bat.pdata->charg_stat_gpio); } power_supply_unregister(&bat_ps); -- 1.6.0.4 From lists at nanl.de Tue Sep 22 06:50:09 2009 From: lists at nanl.de (Mirko Vogt) Date: Tue, 22 Sep 2009 12:50:09 +0200 Subject: Kernel drivers In-Reply-To: <19ebea720909211704w66fb0d13jc86c37a21d7b1ecc@mail.gmail.com> References: <19ebea720909211704w66fb0d13jc86c37a21d7b1ecc@mail.gmail.com> Message-ID: <1253616609.5407.5.camel@mia> On Mon, 2009-09-21 at 19:04 -0500, Carlos Camargo wrote: > Hi Hey, > > I'm trying to build an image kernel with sound and keyboard support. > I'm using openwrt, and qi-kernel, The compilation process run > successfully and I can upload the kernel images to NAND flash using > usbboot. , but I have some problems: (I'm using root on mmc) > > 1. When I run a command the console hangs and don't works again. Hmm - when exactly? Can you reproduce this kind of behaviour with specials tasks? > 3. I can't start a usb network connection with Nano, The ping from/to > Nano works, but ssh not. OpenWrt uses telnet as long as no password is set for root. Until then, telnet is disabled and ssh enabled. Maybe that's the problem here? > 4. dmesg shows a lot of MMC commands. so we can't see the driver > message, I think that the best choice would be disble the mmc debug > messages. Yeah, we weren't able to figure out what exactly is causing these mmc-rootfs-problems. Sometimes it works, sometimes it does not. For a reliable boot please consider flashing and booting your rootfs from nand for now. Using the mmc afterwards is safe. > 5. some times the console hangs on: Press CTRL_C for failsafe, and we > need reboot some times for get a console. Really weird - these kind of hangons I never experienced yet. Same as 1). > > Best Regards Dito > > > > -- > Carlos Iv?n Camargo Bare?o > Profesor Asistente > Departamento de Ingenier?a El?ctrica y Electr?nica > Universidad Nacional de Colombia > cicamargoba at unal.edu.co > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer -- This email address is used for mailinglist purposes only. Non-mailinglist emails will be dropped automatically. If you want to get in contact with me personally, please mail to: mirko.vogt nanl de From cicamargoba at gmail.com Tue Sep 22 07:39:02 2009 From: cicamargoba at gmail.com (Carlos Camargo) Date: Tue, 22 Sep 2009 06:39:02 -0500 Subject: Kernel drivers In-Reply-To: <1253616609.5407.5.camel@mia> References: <19ebea720909211704w66fb0d13jc86c37a21d7b1ecc@mail.gmail.com> <1253616609.5407.5.camel@mia> Message-ID: <19ebea720909220439m71f914f6vf764d8f91e2e9ed6@mail.gmail.com> Hi On Tue, Sep 22, 2009 at 5:50 AM, Mirko Vogt wrote: > On Mon, 2009-09-21 at 19:04 -0500, Carlos Camargo wrote: > > Hi > Hey, > > > > I'm trying to build an image kernel with sound and keyboard support. > > I'm using openwrt, and qi-kernel, The compilation process run > > successfully and I can upload the kernel images to NAND flash using > > usbboot. , but I have some problems: (I'm using root on mmc) > > > > 1. When I run a command the console hangs and don't works again. > Hmm - when exactly? Can you reproduce this kind of behaviour with > specials tasks? > I have similar errors when I make a simple "ls /root" or when I try to list some directory tree, or when I execute a command like "mplayer /usr/alsa/share/alsa" > > 3. I can't start a usb network connection with Nano, The ping from/to > > Nano works, but ssh not. > OpenWrt uses telnet as long as no password is set for root. Until then, > telnet is disabled and ssh enabled. Maybe that's the problem here? > I set a passwd for root with "passwd root" but when I try to connect to nano, Nano don't recognize the password and ask for the password again. > > 4. dmesg shows a lot of MMC commands. so we can't see the driver > > message, I think that the best choice would be disble the mmc debug > > messages. > Yeah, we weren't able to figure out what exactly is causing these > mmc-rootfs-problems. Sometimes it works, sometimes it does not. > For a reliable boot please consider flashing and booting your rootfs > from nand for now. Using the mmc afterwards is safe. > ok, > > 5. some times the console hangs on: Press CTRL_C for failsafe, and we > > need reboot some times for get a console. > Really weird - these kind of hangons I never experienced yet. Same as > 1). > > > > Best Regards > Dito > > > > > > > > -- > > Carlos Iv?n Camargo Bare?o > > Profesor Asistente > > Departamento de Ingenier?a El?ctrica y Electr?nica > > Universidad Nacional de Colombia > > cicamargoba at unal.edu.co > > _______________________________________________ > > Qi Developer Mailing List > > Mail to list (members only): developer at lists.qi-hardware.com > > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > > -- > This email address is used for mailinglist purposes only. > Non-mailinglist emails will be dropped automatically. > If you want to get in contact with me personally, please mail to: > mirko.vogt nanl de > > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer -- Carlos Iv?n Camargo Bare?o Profesor Asistente Departamento de Ingenier?a El?ctrica y Electr?nica Universidad Nacional de Colombia cicamargoba at unal.edu.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From wolfgang at qi-hardware.com Tue Sep 22 08:11:04 2009 From: wolfgang at qi-hardware.com (Wolfgang Spraul) Date: Tue, 22 Sep 2009 08:11:04 -0400 Subject: [Company] Weekly Operations Update 38/2009 Message-ID: <20090922121104.GA2849@debian> Hi, about last week: ---1 software status Mirko Vogt wrote up a nice summary about software progress in the last week or two, see http://lists.qi-hardware.com/pipermail/developer/2009-September/000590.html Basically pieces are coming together, kernel first of all. Our goal is to make the NanoNote the most polished end-user experience shipped with 100% free software. We'll get there... ---2 server upgrade Many things happened on the server side. We finished the move to our own dedicated Dual Athlon box at the excellent hosting company hetzner.de in Germany. As part of the move we launched a number of new 'tracking' email lists, see http://lists.qi-hardware.com This is for people who prefer tracking things by mail as opposed to RSS/Atom feeds, and they can now do so in either text or html version. ---3 planet We launched our copyleft hardware planet, and will assemble an interesting collection of real hacking blogs, anti-vendor ports, open hardware projects, people that really care about openness and push the limits of what is possible with free technology. Check it out at http://planet.qi-hardware.com, you can read the page, or subscribe to an RSS/Atom feed, or the tracking email list... I am a bit uncertain about the netiquette of asking for permission before syndicating blogs. For the ones that are up now, in some cases we did ask for permission upfront (everybody agreed), in some cases we just added the feed (of course we respect copyrights, so if the authors don't like to be syndicated we would take it down immediately). Most of the blogs we link to are licensed under Creative Commons licenses anyway, so they automatically permit redistribution, public archiving, etc. Anyway, if you know other interesting serious hacking or open/copyleft hardware blogs, please let us know and we will add it to the planet. ---4 spam I guess it's a good sign, our site starts to become more known and more linked to, so we got the first spam on our wiki. As a result we disabled anonymous edits, you need to create an account now before making edits. If there is any problem with that please speak up, fighting spam is a necessary evil of being as open as we are. So much for this week, steady progress everywhere, also on the mechanical and certification side, but I wait until there are final results before reporting them here... Wolfgang From xiangfu at qi-hardware.com Wed Sep 23 03:10:45 2009 From: xiangfu at qi-hardware.com (Xiangfu Liu) Date: Wed, 23 Sep 2009 15:10:45 +0800 Subject: nand jffs2 notice message In-Reply-To: <12990.1253615816@gcasse.net> References: <12990.1253615816@gcasse.net> Message-ID: <4AB9C9F5.3010300@qi-hardware.com> Hi ZhangJieJing Gilles Casse. thanks for the info. ZhangJieJing wrote: > Hi, > > I goto too. > >> correct: 0x7aca -> 0x6aca > this message is NAND ECC correction, and success corrected by NAND ECC. > I think this is fine, Lars maybe know more about this. Gilles Casse wrote: >>> JFFS2 notice: (388) check_node_data: wrong data CRC in data node at >> 0x1704edf4:. > > It can be due to a power off while this jffs2 node was beeing written. > http://www.linux-mtd.infradead.org/faq/jffs2.html#L_messages > At next boot, the warning appears and jffs2 is potentially able to restore the previous node. > In case of doubt, the jffs2dump tool helps to check the jffs2 partition. > > Best regards, > Gilles > > > > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer From xiangfu.z at gmail.com Wed Sep 23 03:13:06 2009 From: xiangfu.z at gmail.com (Xiangfu Liu) Date: Wed, 23 Sep 2009 15:13:06 +0800 Subject: Ben_Nanonote keyboard driver bug In-Reply-To: <200909222337.26608.dmitry.torokhov@gmail.com> References: <4AB33A1A.7090508@gmail.com> <200909222337.26608.dmitry.torokhov@gmail.com> Message-ID: <4AB9CA82.5000302@gmail.com> Dmitry Torokhov wrote: > On Friday 18 September 2009 12:43:22 am Xiangfu Liu wrote: >> Hi >> >> with Dmitry's help, our keyboard is work. >> >> we use the matrix_keypad.c driver. I found a problem. >> for example. the keypad is like this: (part of keypad) >> GPIO GPIO GPIO >> >> a_______w_______u_____GPIO >> >> |_______s_______j_____GPIO >> >> Shift___Alt_____Ctrl__GPIO >> >> first time press [Shift] + [a] it's output [a] not the [A] >> second time press [Shift] + [a] it's output [A]. correct. >> then all work fine. but when I release the [Shift]. and press [a] >> it's will also output big [A]. but if the midifier and character not >> in same column GPIO. it will work fine. >> >> other modifier all like this. same GPIO will cause problem. >> >> I should look into the matrix_keypad.c to fix this, right? >> > > It would be interesting to see what events are being reported by either evbug > module or evtest utility. > Hi Dmitry. I will try to look into the evbug or evtest. will send email when I have progress. -- Xiangfu Liu Email: xiangfu at qi-hardware dot com Web: http://www.qi-hardware.com From wolfgang at qi-hardware.com Wed Sep 23 03:27:41 2009 From: wolfgang at qi-hardware.com (Wolfgang Spraul) Date: Wed, 23 Sep 2009 03:27:41 -0400 Subject: Ingenic opening up more - daily Linux development tree Message-ID: <20090923072741.GA2659@debian> Hi, good news for all Ingenic hackers: Ingenic agreed to install a little rsync box behind their firewall that will rsync their ongoing Linux and u-boot development svn repositories to our public server. What that means is that any updates they do on the 2.6.24.3 or 2.6.27 Linux tree, as well as u-boot (old 1.1.6 version) and usbboot, will become public the next day :-) You can find the 4 new projects at http://projects.qi-hardware.com ingenic-tools-usb-boot ingenic-linux-01boot-u-boot-1-1-6 ingenic-linux-02os-linux-2-6-24-3 ingenic-linux-02os-linux-2-6-27 Anonymous checkout for example like this: svn co http://projects.qi-hardware.com/svn/ingenic-linux-02os-linux-2-6-27/trunk linux-2.6.27 This is live as of right now, including revision history, and will be updated at 2 AM every night (China timezone). There are a number of things that we could imagine for the future, such as Ingenic and the upstream Linux scene (us) working directly together on a public git server. But we need to get there in small digestible steps. Also for me it's important that Ingenic does not reduce their amount of Linux support. I think the best we can do right now is if the various Ingenic hacking efforts at Qi Hardware, openinkport.org, dingux.com, etc. could merge their work into one tree. Many of us are cleaning up Ingenic's drivers, rewriting them for more recent kernel interfaces. But it's quite fragmented. If we could unite this into one place, based on the most recent upstream kernel at the time, we could then ask Ingenic to up-level to that version and make it their new base. That would give us a chance to substantially cleanup quite a bit of the architecture, and then have Ingenic continue on top of it. Suggestions and feedback welcome - today I'm happy that we made another small step towards more openness... Wolfgang From hns at computer.org Wed Sep 23 04:46:25 2009 From: hns at computer.org (Dr. H. Nikolaus Schaller) Date: Wed, 23 Sep 2009 10:46:25 +0200 Subject: Fwd: Ingenic opening up more - daily Linux development tree References: <20090923072741.GA2659@debian> Message-ID: <0CF74EF7-9F3E-4C23-9307-C9A7B3335F22@computer.org> Hi Wolfgang, this looks interesting to participate there since you have very similar targets (but better connections to Ingenic) as the 'mipsbook' project for Letux 400 and similar devices (which even use u-boot 1.1.6). Nikolaus Anfang der weitergeleiteten E-Mail: > Von: Wolfgang Spraul > Datum: 23. September 2009 09:27:41 MESZ > An: developer at turandot.qi-hardware.com > Betreff: Ingenic opening up more - daily Linux development tree > Antwort an: "Hard- and Software Development, Kernel, Distribution, > Roadmap" > > Hi, > good news for all Ingenic hackers: Ingenic agreed to install a little > rsync box behind their firewall that will rsync their ongoing Linux > and u-boot development svn repositories to our public server. > What that means is that any updates they do on the 2.6.24.3 or 2.6.27 > Linux tree, as well as u-boot (old 1.1.6 version) and usbboot, will > become public the next day :-) Great! > > You can find the 4 new projects at http://projects.qi-hardware.com > > ingenic-tools-usb-boot > ingenic-linux-01boot-u-boot-1-1-6 > ingenic-linux-02os-linux-2-6-24-3 > ingenic-linux-02os-linux-2-6-27 > > Anonymous checkout for example like this: > > svn co http://projects.qi-hardware.com/svn/ingenic-linux-02os-linux-2-6-27/trunk > linux-2.6.27 > > This is live as of right now, including revision history, and will > be updated at 2 AM every night (China timezone). > > There are a number of things that we could imagine for the future, > such as Ingenic and the upstream Linux scene (us) working directly > together on a public git server. Good target. > But we need to get there in small digestible steps. Also for me it's > important that Ingenic does not reduce their amount of Linux support. > > I think the best we can do right now is if the various Ingenic hacking > efforts at Qi Hardware, openinkport.org, dingux.com, etc. could merge > their work into one tree. Yes. > Many of us are cleaning up Ingenic's drivers, rewriting them for more > recent kernel interfaces. But it's quite fragmented. Yes. Very fragmented. > If we could unite this into one place, based on the most recent > upstream > kernel at the time, we could then ask Ingenic to up-level to that > version and make it their new base. That would give us a chance to Why not on linuxtogo.org? This is more independent from any company (even qi-hardware.com). > substantially cleanup quite a bit of the architecture, and then have > Ingenic continue on top of it. > > Suggestions and feedback welcome - today I'm happy that we made > another > small step towards more openness... > Wolfgang > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer From wolfgang at qi-hardware.com Wed Sep 23 06:27:40 2009 From: wolfgang at qi-hardware.com (Wolfgang Spraul) Date: Wed, 23 Sep 2009 06:27:40 -0400 Subject: some more updates from the software part In-Reply-To: <1253486666.11044.886.camel@mia> References: <1253486666.11044.886.camel@mia> Message-ID: <20090923102740.GA2924@debian> Hi, just thought I point you to this other git repository with quite a bit of Ingenic hacking going on: http://git.openinkpot.org/linux-2.6.git/ The OpenInkpot guys are working on a 4740 based Hanvon N516 e-book, and are doing some cleaning up and rewriting of Ingenic drivers as well. I have heard about work in the I2C driver, USB client, LCM and NAND. I just thought I pass the URL along in case it's not known yet... Wolfgang On Mon, Sep 21, 2009 at 12:44:26AM +0200, Mirko Vogt wrote: > Hey! > > As Wolfgang is doing since the beginning, from now on I also will try to > summarize what's going on "behind the scenes" (the > software-/OpenWrt-part) in weekly updates. > > So let's see what happened last days: > > USB-Ethernet-Gadget is working. > You're now able to speak ethernet, and therefore IP, to your Ben > Nanonote via USB. > That's really cool, because now all the network-stuff can be used which > simplifies lot's of things (e.g. SSH into the NanoNote, copying files, > etc.) > > Lars found out the used NAND-chip is a multilevel-chip that has to be > treated by the flash-tools in a special way which should fix most of our > previous ECC-NAND-chip-problems. > > OpenZIM, an opensource implementation for handling ZIM-files which > mainly provide wiki-articles (e.g. the wikipedia), it's dependencies and > lynx as first webbrowser are ported to OpenWrt! This way the Ben > NanoNote can be used as offline wikipedia reader. > All of them need some more cleanups but will be committed soon. > Unfortunately the amount of RAM (32MB) of the Ben limits applications > like OpenZIM, so they'll need some more tweaking to get them running > smoothly. > > Thanks to Lars and Xiang Fu Sound (based on ALSA) and keyboard are now > supported, also work is going on to get the battery driver cleaned up / > improved (thanks to JieJing Zhang). > > In addition there's now a driver for the internally used real time clock > - also written by lars. > > > Things are moving :) > > mirko > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer From lars at metafoo.de Wed Sep 23 09:11:09 2009 From: lars at metafoo.de (Lars-Peter Clausen) Date: Wed, 23 Sep 2009 15:11:09 +0200 Subject: [PATCH] jz_battery: improve driver code. In-Reply-To: References: Message-ID: <4ABA1E6D.6070506@metafoo.de> Hi > 1. put all gobal var to a driver info struct. You solution is not exaclty what I had in mind. You are still using a global variable. I was talking about using {platform,dev}_{get,set}_drvdata to avoid it. Please take a look at how other drivers handle this. > 2. check gpio before use it. You still register the usb and ac power supply even if the gpio is not vaild Some more comments inlined: > > Signed-off-by: Jiejing.Zhang > --- > .../files-2.6.31/drivers/power/jz4740-battery.c | 139 ++++++++++++-------- > 1 files changed, 81 insertions(+), 58 deletions(-) > > diff --git a/target/linux/xburst/files-2.6.31/drivers/power/jz4740-battery.c > b/target/linux/xburst/files-2.6.31/drivers/power/jz4740-battery.c > index de1f4e2..fccfc2e 100644 > --- a/target/linux/xburst/files-2.6.31/drivers/power/jz4740-battery.c > +++ b/target/linux/xburst/files-2.6.31/drivers/power/jz4740-battery.c > @@ -23,16 +23,18 @@ > #include > #include > > -/*struct jz_battery {*/ > - static int bat_status = POWER_SUPPLY_STATUS_DISCHARGING; > - static struct jz_batt_info *pdata = 0; > - > +struct jz_battery_info { > + int bat_status; > + struct jz_batt_info *pdata; > struct mutex work_lock; > - > struct workqueue_struct *monitor_wqueue; > struct delayed_work bat_work; > -/*};*/ > +}; > > +static struct jz_battery_info jz_main_bat = { > + .bat_status = POWER_SUPPLY_STATUS_DISCHARGING, > + .pdata = 0, > +}; > > /********************************************************************* > * Power > @@ -42,8 +44,13 @@ static int jz_get_power_prop(struct power_supply *psy, > enum power_supply_property psp, > union power_supply_propval *val) > { > - int gpio = (psy->type == POWER_SUPPLY_TYPE_MAINS) ? pdata->dc_dect_gpio : > - pdata->usb_dect_gpio; > + if (!jz_main_bat.pdata) > + return -EINVAL; It's enough if you check pdata in jz_bat_probe. If the check there fails this function will never be called. > + int gpio = (psy->type == POWER_SUPPLY_TYPE_MAINS) ? > jz_main_bat.pdata->dc_dect_gpio : jz_main_bat.pdata->usb_dect_gpio; > + > + if (!gpio_is_valid(gpio)) > + return -EINVAL; > + > switch (psp) { > case POWER_SUPPLY_PROP_ONLINE: > val->intval = !gpio_get_value(gpio); > @@ -83,7 +90,10 @@ static struct power_supply jz_usb = { > static long jz_read_bat(struct power_supply *bat_ps) > { > enum jz_adc_battery_scale scale; > - if (pdata->max_voltag > 2500000) > + if (!jz_main_bat.pdata) > + return -EINVAL; > + > + if (jz_main_bat.pdata->max_voltag > 2500000) > scale = JZ_ADC_BATTERY_SCALE_7V5; > else > scale = JZ_ADC_BATTERY_SCALE_2V5; > @@ -95,13 +105,16 @@ static int jz_bat_get_capacity(struct power_supply *bat_ps) > { > int ret; > > + if (!jz_main_bat.pdata) > + return -EINVAL; dito > + > ret = jz_read_bat(bat_ps); > > if (ret < 0) > return ret; > > - ret = (ret - pdata->min_voltag) * 100 > - / (pdata->max_voltag - pdata->min_voltag); > + ret = (ret - jz_main_bat.pdata->min_voltag) * 100 > + / (jz_main_bat.pdata->max_voltag - jz_main_bat.pdata->min_voltag); > > if (ret > 100) > ret = 100; > @@ -115,15 +128,18 @@ static int jz_bat_get_property(struct > power_supply *bat_ps, > enum power_supply_property psp, > union power_supply_propval *val) > { > + if (!jz_main_bat.pdata) > + return -EINVAL; dito > + > switch (psp) { > case POWER_SUPPLY_PROP_STATUS: > - val->intval = bat_status; > + val->intval = jz_main_bat.bat_status; > break; > case POWER_SUPPLY_PROP_TECHNOLOGY: > - val->intval = pdata->batt_tech; > + val->intval = jz_main_bat.pdata->batt_tech; > break; > case POWER_SUPPLY_PROP_HEALTH: > - if(jz_read_bat(bat_ps) < pdata->min_voltag) { > + if(jz_read_bat(bat_ps) < jz_main_bat.pdata->min_voltag) { > dev_dbg(bat_ps->dev, "%s: battery is dead," > "voltage too low!\n", __func__); > val->intval = POWER_SUPPLY_HEALTH_DEAD; > @@ -145,10 +161,10 @@ static int jz_bat_get_property(struct > power_supply *bat_ps, > break; > case POWER_SUPPLY_PROP_VOLTAGE_MAX: > case POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN: > - val->intval = pdata->max_voltag; > + val->intval = jz_main_bat.pdata->max_voltag; > break; > case POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN: > - val->intval = pdata->min_voltag; > + val->intval = jz_main_bat.pdata->min_voltag; > break; > case POWER_SUPPLY_PROP_PRESENT: > val->intval = 1; > @@ -161,8 +177,8 @@ static int jz_bat_get_property(struct power_supply *bat_ps, > > static void jz_bat_external_power_changed(struct power_supply *bat_ps) > { > - cancel_delayed_work(&bat_work); > - queue_delayed_work(monitor_wqueue, &bat_work, HZ / 8); > + cancel_delayed_work(&jz_main_bat.bat_work); > + queue_delayed_work(jz_main_bat.monitor_wqueue, &jz_main_bat.bat_work, HZ / 8); > } > > static char *status_text[] = { > @@ -174,31 +190,38 @@ static char *status_text[] = { > > static void jz_bat_update(struct power_supply *bat_ps) > { > - int old_status = bat_status; > + int old_status = jz_main_bat.bat_status; > static unsigned long old_batt_vol = 0; > unsigned long batt_vol = jz_read_bat(bat_ps); > - mutex_lock(&work_lock); > + mutex_lock(&jz_main_bat.work_lock); > + > + if (!jz_main_bat.pdata) > + goto err; dito > + > + if (!gpio_is_valid(jz_main_bat.pdata->charg_stat_gpio)) > + goto err; You should still handle voltage changes > > - if(!gpio_get_value(pdata->charg_stat_gpio)) > - bat_status = POWER_SUPPLY_STATUS_CHARGING; > + if(!gpio_get_value(jz_main_bat.pdata->charg_stat_gpio)) > + jz_main_bat.bat_status = POWER_SUPPLY_STATUS_CHARGING; > else > - bat_status = POWER_SUPPLY_STATUS_NOT_CHARGING; > + jz_main_bat.bat_status = POWER_SUPPLY_STATUS_NOT_CHARGING; > > dev_dbg(bat_ps->dev, "%s: battery status=%s\n", > - __func__, status_text[bat_status]); > + __func__, status_text[jz_main_bat.bat_status]); > > - if ((old_status != bat_status) || > + if ((old_status != jz_main_bat.bat_status) || > (old_batt_vol - batt_vol > 50000)) { > dev_dbg(bat_ps->dev, "%s %s -> %s\n", > bat_ps->name, > status_text[old_status], > - status_text[bat_status]); > + status_text[jz_main_bat.bat_status]); > > power_supply_changed(bat_ps); > } > > old_batt_vol = batt_vol; > - mutex_unlock(&work_lock); > +err: > + mutex_unlock(&jz_main_bat.work_lock); > } > > static enum power_supply_property jz_bat_main_props[] = { > @@ -228,22 +251,22 @@ static void jz_bat_work(struct work_struct *work) > const int interval = HZ * 30; > > jz_bat_update(&bat_ps); > - queue_delayed_work(monitor_wqueue, &bat_work, interval); > + queue_delayed_work(jz_main_bat.monitor_wqueue, > &jz_main_bat.bat_work, interval); > } > > #ifdef CONFIG_PM > static int jz_bat_suspend(struct platform_device *dev, pm_message_t state) > { > - bat_status = POWER_SUPPLY_STATUS_UNKNOWN; > + jz_main_bat.bat_status = POWER_SUPPLY_STATUS_UNKNOWN; > > return 0; > } > > static int jz_bat_resume(struct platform_device *dev) > { > - bat_status = POWER_SUPPLY_STATUS_UNKNOWN; > - cancel_delayed_work(&bat_work); > - queue_delayed_work(monitor_wqueue, &bat_work, HZ/10); > + jz_main_bat.bat_status = POWER_SUPPLY_STATUS_UNKNOWN; > + cancel_delayed_work(&jz_main_bat.bat_work); > + queue_delayed_work(jz_main_bat.monitor_wqueue, &jz_main_bat.bat_work, HZ/10); > > return 0; > } > @@ -257,24 +280,24 @@ static int __devinit jz_bat_probe(struct > platform_device *pdev) > int ret = 0; > > printk("JZ battery init.\n"); > - mutex_init(&work_lock); > - INIT_DELAYED_WORK(&bat_work, jz_bat_work); > + mutex_init(&jz_main_bat.work_lock); > + INIT_DELAYED_WORK(&jz_main_bat.bat_work, jz_bat_work); > > if (!pdev->dev.platform_data) { > dev_err(&pdev->dev, "Please set battery info\n"); > return -EINVAL; > } > > - pdata = pdev->dev.platform_data; > + jz_main_bat.pdata = pdev->dev.platform_data; > > - if (gpio_is_valid(pdata->dc_dect_gpio)) { > - ret = gpio_request(pdata->dc_dect_gpio, "AC/DC DECT"); > + if (gpio_is_valid(jz_main_bat.pdata->dc_dect_gpio)) { > + ret = gpio_request(jz_main_bat.pdata->dc_dect_gpio, "AC/DC DECT"); > if (ret) { > dev_err(&pdev->dev, "ac/dc dect gpio request failed.\n"); > > goto err_dc_gpio_request; > } > - ret = gpio_direction_input(pdata->dc_dect_gpio); > + ret = gpio_direction_input(jz_main_bat.pdata->dc_dect_gpio); > if (ret) { > dev_err(&pdev->dev, "ac/dc dect gpio direction failed.\n"); > > @@ -282,30 +305,30 @@ static int __devinit jz_bat_probe(struct > platform_device *pdev) > } > } > > - if (gpio_is_valid(pdata->usb_dect_gpio)) { > - ret = gpio_request(pdata->usb_dect_gpio, "USB DECT"); > + if (gpio_is_valid(jz_main_bat.pdata->usb_dect_gpio)) { > + ret = gpio_request(jz_main_bat.pdata->usb_dect_gpio, "USB DECT"); > if (ret) { > dev_err(&pdev->dev, "usb dect gpio request failed.\n"); > > goto err_usb_gpio_request; > } > - ret = gpio_direction_input(pdata->usb_dect_gpio); > + ret = gpio_direction_input(jz_main_bat.pdata->usb_dect_gpio); > if (ret) { > dev_err(&pdev->dev, "usb dect gpio set direction failed.\n"); > goto err_usb_gpio_direction; > } > > - jz_gpio_disable_pullup(pdata->usb_dect_gpio); > + jz_gpio_disable_pullup(jz_main_bat.pdata->usb_dect_gpio); > /* TODO: Use generic gpio is better */ > } > > - if (gpio_is_valid(pdata->charg_stat_gpio)) { > - ret = gpio_request(pdata->charg_stat_gpio, "CHARG STAT"); > + if (gpio_is_valid(jz_main_bat.pdata->charg_stat_gpio)) { > + ret = gpio_request(jz_main_bat.pdata->charg_stat_gpio, "CHARG STAT"); > if (ret) { > dev_err(&pdev->dev, "charger state gpio request failed.\n"); > goto err_charg_gpio_request; > } > - ret = gpio_direction_input(pdata->charg_stat_gpio); > + ret = gpio_direction_input(jz_main_bat.pdata->charg_stat_gpio); > if (ret) { > dev_err(&pdev->dev, "charger state gpio set direction failed.\n"); > goto err_charg_gpio_direction; > @@ -331,11 +354,11 @@ static int __devinit jz_bat_probe(struct > platform_device *pdev) > } > > if (!ret) { > - monitor_wqueue = create_singlethread_workqueue("jz_battery"); > - if (!monitor_wqueue) { > + jz_main_bat.monitor_wqueue = create_singlethread_workqueue("jz_battery"); > + if (!jz_main_bat.monitor_wqueue) { > return -ESRCH; > } > - queue_delayed_work(monitor_wqueue, &bat_work, HZ * 1); > + queue_delayed_work(jz_main_bat.monitor_wqueue, > &jz_main_bat.bat_work, HZ * 1); > } > > return ret; > @@ -346,26 +369,26 @@ err_power_register_usb: > power_supply_unregister(&jz_ac); > err_power_register_ac: > err_charg_gpio_direction: > - gpio_free(pdata->charg_stat_gpio); > + gpio_free(jz_main_bat.pdata->charg_stat_gpio); > err_charg_gpio_request: > err_usb_gpio_direction: > - gpio_free(pdata->usb_dect_gpio); > + gpio_free(jz_main_bat.pdata->usb_dect_gpio); > err_usb_gpio_request: > err_dc_gpio_direction: > - gpio_free(pdata->dc_dect_gpio); > + gpio_free(jz_main_bat.pdata->dc_dect_gpio); > err_dc_gpio_request: > return ret; > } > > static int __devexit jz_bat_remove(struct platform_device *dev) > { > - if (pdata) { > - if (gpio_is_valid(pdata->dc_dect_gpio)) > - gpio_free(pdata->dc_dect_gpio); > - if (gpio_is_valid(pdata->usb_dect_gpio)) > - gpio_free(pdata->usb_dect_gpio); > - if (gpio_is_valid(pdata->charg_stat_gpio)) > - gpio_free(pdata->charg_stat_gpio); > + if (jz_main_bat.pdata) { > + if (gpio_is_valid(jz_main_bat.pdata->dc_dect_gpio)) > + gpio_free(jz_main_bat.pdata->dc_dect_gpio); > + if (gpio_is_valid(jz_main_bat.pdata->usb_dect_gpio)) > + gpio_free(jz_main_bat.pdata->usb_dect_gpio); > + if (gpio_is_valid(jz_main_bat.pdata->charg_stat_gpio)) > + gpio_free(jz_main_bat.pdata->charg_stat_gpio); > } > > power_supply_unregister(&bat_ps); > - Lars From lars at metafoo.de Wed Sep 23 14:03:08 2009 From: lars at metafoo.de (Lars-Peter Clausen) Date: Wed, 23 Sep 2009 20:03:08 +0200 Subject: some more updates from the software part In-Reply-To: <20090923102740.GA2924@debian> References: <1253486666.11044.886.camel@mia> <20090923102740.GA2924@debian> Message-ID: <4ABA62DC.6080104@metafoo.de> > Hi, just thought I point you to this other git repository with > quite a bit of Ingenic hacking going on: > > http://git.openinkpot.org/linux-2.6.git/ > > The OpenInkpot guys are working on a 4740 based Hanvon N516 e-book, > and are doing some cleaning up and rewriting of Ingenic drivers as > well. I have heard about work in the I2C driver, USB client, LCM > and NAND. I just thought I pass the URL along in case it's not > known yet... Wolfgang Hi Yup, I've been monitoring their repository for some time now. Unfortunately I didn't had the chance to take to Yauhen Kharuzhy yet. They use a more evolutionary approach when it comes to patching the Ingenic sources, it's not that much of a cleanup or rewrite as opposed to what we did. And most of the things they do are not relevant for the nanonote anyway. Never the less we should strive towards a common code base. I'll try to make contact in the next days. We'll see then what will necessary to archive this. - Lars > > > On Mon, Sep 21, 2009 at 12:44:26AM +0200, Mirko Vogt wrote: >> Hey! >> >> As Wolfgang is doing since the beginning, from now on I also will >> try to summarize what's going on "behind the scenes" (the >> software-/OpenWrt-part) in weekly updates. >> >> So let's see what happened last days: >> >> USB-Ethernet-Gadget is working. You're now able to speak >> ethernet, and therefore IP, to your Ben Nanonote via USB. That's >> really cool, because now all the network-stuff can be used which >> simplifies lot's of things (e.g. SSH into the NanoNote, copying >> files, etc.) >> >> Lars found out the used NAND-chip is a multilevel-chip that has >> to be treated by the flash-tools in a special way which should >> fix most of our previous ECC-NAND-chip-problems. >> >> OpenZIM, an opensource implementation for handling ZIM-files >> which mainly provide wiki-articles (e.g. the wikipedia), it's >> dependencies and lynx as first webbrowser are ported to OpenWrt! >> This way the Ben NanoNote can be used as offline wikipedia >> reader. All of them need some more cleanups but will be committed >> soon. Unfortunately the amount of RAM (32MB) of the Ben limits >> applications like OpenZIM, so they'll need some more tweaking to >> get them running smoothly. >> >> Thanks to Lars and Xiang Fu Sound (based on ALSA) and keyboard >> are now supported, also work is going on to get the battery >> driver cleaned up / improved (thanks to JieJing Zhang). >> >> In addition there's now a driver for the internally used real >> time clock - also written by lars. >> >> >> Things are moving :) >> >> mirko > > > >> _______________________________________________ Qi Developer >> Mailing List Mail to list (members only): >> developer at lists.qi-hardware.com Subscribe or Unsubscribe: >> http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > _______________________________________________ Qi Developer > Mailing List Mail to list (members only): > developer at lists.qi-hardware.com Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > Hi, just thought I point you to this other git repository with > quite a bit of Ingenic hacking going on: > > http://git.openinkpot.org/linux-2.6.git/ > > The OpenInkpot guys are working on a 4740 based Hanvon N516 e-book, > and are doing some cleaning up and rewriting of Ingenic drivers as > well. I have heard about work in the I2C driver, USB client, LCM > and NAND. I just thought I pass the URL along in case it's not > known yet... Wolfgang Hi Yup, I've been monitoring their repository for some time now. Unfortunately I didn't had the chance to take to Yauhen Kharuzhy yet. They use a more evolutionary approach when it comes to patching the Ingenic sources, it's not that much of a cleanup or rewrite as opposed to what we did. And most of the things they do are not relevant for the nanonote anyway. Never the less we should strive towards a common code base. I'll try to make contact in the next days. We'll see then what will necessary to archive this. - Lars > > > On Mon, Sep 21, 2009 at 12:44:26AM +0200, Mirko Vogt wrote: >> Hey! >> >> As Wolfgang is doing since the beginning, from now on I also will >> try to summarize what's going on "behind the scenes" (the >> software-/OpenWrt-part) in weekly updates. >> >> So let's see what happened last days: >> >> USB-Ethernet-Gadget is working. You're now able to speak >> ethernet, and therefore IP, to your Ben Nanonote via USB. That's >> really cool, because now all the network-stuff can be used which >> simplifies lot's of things (e.g. SSH into the NanoNote, copying >> files, etc.) >> >> Lars found out the used NAND-chip is a multilevel-chip that has >> to be treated by the flash-tools in a special way which should >> fix most of our previous ECC-NAND-chip-problems. >> >> OpenZIM, an opensource implementation for handling ZIM-files >> which mainly provide wiki-articles (e.g. the wikipedia), it's >> dependencies and lynx as first webbrowser are ported to OpenWrt! >> This way the Ben NanoNote can be used as offline wikipedia >> reader. All of them need some more cleanups but will be committed >> soon. Unfortunately the amount of RAM (32MB) of the Ben limits >> applications like OpenZIM, so they'll need some more tweaking to >> get them running smoothly. >> >> Thanks to Lars and Xiang Fu Sound (based on ALSA) and keyboard >> are now supported, also work is going on to get the battery >> driver cleaned up / improved (thanks to JieJing Zhang). >> >> In addition there's now a driver for the internally used real >> time clock - also written by lars. >> >> >> Things are moving :) >> >> mirko > > > >> _______________________________________________ Qi Developer >> Mailing List Mail to list (members only): >> developer at lists.qi-hardware.com Subscribe or Unsubscribe: >> http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > _______________________________________________ Qi Developer > Mailing List Mail to list (members only): > developer at lists.qi-hardware.com Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer From cicamargoba at gmail.com Wed Sep 23 21:06:44 2009 From: cicamargoba at gmail.com (Carlos Camargo) Date: Wed, 23 Sep 2009 20:06:44 -0500 Subject: QI_AVT2 V1.0 Board Message-ID: <19ebea720909231806o52ded71ie2622e32a425b2dc@mail.gmail.com> Hi My new qi_avt2 v1.0 arrived today, and I'm playing with it. I have some comments about this board: 1. The keyboard pads can't fit exactly the ben layout. 2. SW1 is big, but the position is good, I think that we must replace with a3 smaller one. 3. CON3 is big and don't allow close the case. If you want to use the serial port, is necessary disassemble the device. I think that we need a right angle connector (like sw1), so we have access to serial port from the battery "hole" I'm working an my new board, so wait more reports :) Carlos -- Carlos Iv?n Camargo Bare?o Profesor Asistente Departamento de Ingenier?a El?ctrica y Electr?nica Universidad Nacional de Colombia cicamargoba at unal.edu.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From cicamargoba at gmail.com Wed Sep 23 21:27:18 2009 From: cicamargoba at gmail.com (Carlos Camargo) Date: Wed, 23 Sep 2009 20:27:18 -0500 Subject: QI_AVT2 V1.0 Board In-Reply-To: <19ebea720909231806o52ded71ie2622e32a425b2dc@mail.gmail.com> References: <19ebea720909231806o52ded71ie2622e32a425b2dc@mail.gmail.com> Message-ID: <19ebea720909231827q620e9adfg43ee1d9e8d70d382@mail.gmail.com> Hi I have some problems with the LCD connector: The LCD connector is different on Nano the tape enter without any problem on this board I can't slide the tape Carlos On Wed, Sep 23, 2009 at 8:06 PM, Carlos Camargo wrote: > Hi > > My new qi_avt2 v1.0 arrived today, and I'm playing with it. I have some > comments about this board: > > 1. The keyboard pads can't fit exactly the ben layout. > 2. SW1 is big, but the position is good, I think that we must replace with > a3 smaller one. > 3. CON3 is big and don't allow close the case. If you want to use the > serial port, is necessary disassemble the device. I think that we need a > right angle connector (like sw1), so we have access to serial port from the > battery "hole" > > I'm working an my new board, so wait more reports :) > > Carlos > > -- > Carlos Iv?n Camargo Bare?o > Profesor Asistente > Departamento de Ingenier?a El?ctrica y Electr?nica > Universidad Nacional de Colombia > cicamargoba at unal.edu.co > -- Carlos Iv?n Camargo Bare?o Profesor Asistente Departamento de Ingenier?a El?ctrica y Electr?nica Universidad Nacional de Colombia cicamargoba at unal.edu.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From wolfgang at qi-hardware.com Wed Sep 23 22:09:13 2009 From: wolfgang at qi-hardware.com (Wolfgang Spraul) Date: Wed, 23 Sep 2009 22:09:13 -0400 Subject: some more updates from the software part In-Reply-To: <4ABA62DC.6080104@metafoo.de> References: <1253486666.11044.886.camel@mia> <20090923102740.GA2924@debian> <4ABA62DC.6080104@metafoo.de> Message-ID: <20090924020913.GA4261@debian> Lars, > They use a more evolutionary approach when it comes to patching the > Ingenic sources, it's not that much of a cleanup or rewrite as opposed > to what we did. OK got it. Let me explain my plan a bit and see what you think: Right now, Ingenic is publishing their work on the Linux kernel on a daily basis, through our servers. Cross your fingers that it keeps working, but right now I see updates until 2 days ago, so it seems to work. Ingenic works on two kernel versions, 2.6.24.3 and 2.6.27. The way I see it is that people like you, Mirko, and many other upstream Linux folks have abilities that the in-house Ingenic engineers don't have, and will not have in the foreseeable future. Such as English skills, and ability to quickly communicate with upstream, understand the 'big picture' kernel architecture and interface changes. Whereas the Ingenic engineers know their chips much better than we do, so they can fix specific bugs much more effectively, and bring out the features of the chips. I like that you do a more radical approach to cleaning up the Ingenic patches, because when we have reached a good enough level and completeness, I can ask Ingenic to re-base their work on top of our kernel. It gives us the chance to define the architecture and interfaces for them, and they fill in the details. That way I believe we are all working with our respective strengths. What do you think? Does this make sense? I understand we only work on 1 board right now (the Ben NanoNote), and only care for a few peripherals (well you have the 4740 EVB as well now...) But at which point do you believe would it make sense for us to ask Ingenic to up-level to our kernel? Should we introduce some more 'boilerplate' code for them, just take some more drivers over into a better architectural structure, even if those drivers don't work or have commented-out code. And then ask Ingenic to see whether they want to continue on that basis? Right now they will continue on the 2.6.24.3 and 2.6.27 trees. They mostly run Android on the 2.6.27 tree (that's the reason they started with this kernel version in the first place). This is basically what I had in mind. Any thoughts? Wolfgang On Wed, Sep 23, 2009 at 08:03:08PM +0200, Lars-Peter Clausen wrote: > > Hi, just thought I point you to this other git repository with > > quite a bit of Ingenic hacking going on: > > > > http://git.openinkpot.org/linux-2.6.git/ > > > > The OpenInkpot guys are working on a 4740 based Hanvon N516 e-book, > > and are doing some cleaning up and rewriting of Ingenic drivers as > > well. I have heard about work in the I2C driver, USB client, LCM > > and NAND. I just thought I pass the URL along in case it's not > > known yet... Wolfgang > Hi > > Yup, I've been monitoring their repository for some time now. > Unfortunately I didn't had the chance to take to Yauhen Kharuzhy yet. > > They use a more evolutionary approach when it comes to patching the > Ingenic sources, it's not that much of a cleanup or rewrite as opposed > to what we did. And most of the things they do are not relevant for > the nanonote anyway. > > Never the less we should strive towards a common code base. I'll try > to make contact in the next days. We'll see then what will necessary > to archive this. > > - Lars > > > > > > On Mon, Sep 21, 2009 at 12:44:26AM +0200, Mirko Vogt wrote: > >> Hey! > >> > >> As Wolfgang is doing since the beginning, from now on I also will > >> try to summarize what's going on "behind the scenes" (the > >> software-/OpenWrt-part) in weekly updates. > >> > >> So let's see what happened last days: > >> > >> USB-Ethernet-Gadget is working. You're now able to speak > >> ethernet, and therefore IP, to your Ben Nanonote via USB. That's > >> really cool, because now all the network-stuff can be used which > >> simplifies lot's of things (e.g. SSH into the NanoNote, copying > >> files, etc.) > >> > >> Lars found out the used NAND-chip is a multilevel-chip that has > >> to be treated by the flash-tools in a special way which should > >> fix most of our previous ECC-NAND-chip-problems. > >> > >> OpenZIM, an opensource implementation for handling ZIM-files > >> which mainly provide wiki-articles (e.g. the wikipedia), it's > >> dependencies and lynx as first webbrowser are ported to OpenWrt! > >> This way the Ben NanoNote can be used as offline wikipedia > >> reader. All of them need some more cleanups but will be committed > >> soon. Unfortunately the amount of RAM (32MB) of the Ben limits > >> applications like OpenZIM, so they'll need some more tweaking to > >> get them running smoothly. > >> > >> Thanks to Lars and Xiang Fu Sound (based on ALSA) and keyboard > >> are now supported, also work is going on to get the battery > >> driver cleaned up / improved (thanks to JieJing Zhang). > >> > >> In addition there's now a driver for the internally used real > >> time clock - also written by lars. > >> > >> > >> Things are moving :) > >> > >> mirko > > > > > > > >> _______________________________________________ Qi Developer > >> Mailing List Mail to list (members only): > >> developer at lists.qi-hardware.com Subscribe or Unsubscribe: > >> http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > > > _______________________________________________ Qi Developer > > Mailing List Mail to list (members only): > > developer at lists.qi-hardware.com Subscribe or Unsubscribe: > > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > > Hi, just thought I point you to this other git repository with > > quite a bit of Ingenic hacking going on: > > > > http://git.openinkpot.org/linux-2.6.git/ > > > > The OpenInkpot guys are working on a 4740 based Hanvon N516 e-book, > > and are doing some cleaning up and rewriting of Ingenic drivers as > > well. I have heard about work in the I2C driver, USB client, LCM > > and NAND. I just thought I pass the URL along in case it's not > > known yet... Wolfgang > Hi > > Yup, I've been monitoring their repository for some time now. > Unfortunately I didn't had the chance to take to Yauhen Kharuzhy yet. > > They use a more evolutionary approach when it comes to patching the > Ingenic sources, it's not that much of a cleanup or rewrite as opposed > to what we did. And most of the things they do are not relevant for > the nanonote anyway. > > Never the less we should strive towards a common code base. I'll try > to make contact in the next days. We'll see then what will necessary > to archive this. > > - Lars > > > > > > On Mon, Sep 21, 2009 at 12:44:26AM +0200, Mirko Vogt wrote: > >> Hey! > >> > >> As Wolfgang is doing since the beginning, from now on I also will > >> try to summarize what's going on "behind the scenes" (the > >> software-/OpenWrt-part) in weekly updates. > >> > >> So let's see what happened last days: > >> > >> USB-Ethernet-Gadget is working. You're now able to speak > >> ethernet, and therefore IP, to your Ben Nanonote via USB. That's > >> really cool, because now all the network-stuff can be used which > >> simplifies lot's of things (e.g. SSH into the NanoNote, copying > >> files, etc.) > >> > >> Lars found out the used NAND-chip is a multilevel-chip that has > >> to be treated by the flash-tools in a special way which should > >> fix most of our previous ECC-NAND-chip-problems. > >> > >> OpenZIM, an opensource implementation for handling ZIM-files > >> which mainly provide wiki-articles (e.g. the wikipedia), it's > >> dependencies and lynx as first webbrowser are ported to OpenWrt! > >> This way the Ben NanoNote can be used as offline wikipedia > >> reader. All of them need some more cleanups but will be committed > >> soon. Unfortunately the amount of RAM (32MB) of the Ben limits > >> applications like OpenZIM, so they'll need some more tweaking to > >> get them running smoothly. > >> > >> Thanks to Lars and Xiang Fu Sound (based on ALSA) and keyboard > >> are now supported, also work is going on to get the battery > >> driver cleaned up / improved (thanks to JieJing Zhang). > >> > >> In addition there's now a driver for the internally used real > >> time clock - also written by lars. > >> > >> > >> Things are moving :) > >> > >> mirko > > > > > > > >> _______________________________________________ Qi Developer > >> Mailing List Mail to list (members only): > >> developer at lists.qi-hardware.com Subscribe or Unsubscribe: > >> http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > > > _______________________________________________ Qi Developer > > Mailing List Mail to list (members only): > > developer at lists.qi-hardware.com Subscribe or Unsubscribe: > > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer From cicamargoba at gmail.com Wed Sep 23 22:13:29 2009 From: cicamargoba at gmail.com (Carlos Camargo) Date: Wed, 23 Sep 2009 21:13:29 -0500 Subject: QI_AVT2 V1.0 Board In-Reply-To: <19ebea720909231827q620e9adfg43ee1d9e8d70d382@mail.gmail.com> References: <19ebea720909231806o52ded71ie2622e32a425b2dc@mail.gmail.com> <19ebea720909231827q620e9adfg43ee1d9e8d70d382@mail.gmail.com> Message-ID: <19ebea720909231913le9614d9je716d12805c6769@mail.gmail.com> You can see the keyboard picture here [1] [1] http://downloads.qi-hardware.com/hardware/hacking/qi_avt2.jpg Carlos On Wed, Sep 23, 2009 at 8:27 PM, Carlos Camargo wrote: > Hi > I have some problems with the LCD connector: > > The LCD connector is different > on Nano the tape enter without any problem > on this board I can't slide the tape > > Carlos > > > > > On Wed, Sep 23, 2009 at 8:06 PM, Carlos Camargo wrote: > >> Hi >> >> My new qi_avt2 v1.0 arrived today, and I'm playing with it. I have some >> comments about this board: >> >> 1. The keyboard pads can't fit exactly the ben layout. >> 2. SW1 is big, but the position is good, I think that we must replace with >> a3 smaller one. >> 3. CON3 is big and don't allow close the case. If you want to use the >> serial port, is necessary disassemble the device. I think that we need a >> right angle connector (like sw1), so we have access to serial port from the >> battery "hole" >> >> I'm working an my new board, so wait more reports :) >> >> Carlos >> >> -- >> Carlos Iv?n Camargo Bare?o >> Profesor Asistente >> Departamento de Ingenier?a El?ctrica y Electr?nica >> Universidad Nacional de Colombia >> cicamargoba at unal.edu.co >> > > > > -- > Carlos Iv?n Camargo Bare?o > Profesor Asistente > Departamento de Ingenier?a El?ctrica y Electr?nica > Universidad Nacional de Colombia > cicamargoba at unal.edu.co > -- Carlos Iv?n Camargo Bare?o Profesor Asistente Departamento de Ingenier?a El?ctrica y Electr?nica Universidad Nacional de Colombia cicamargoba at unal.edu.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at qi-hardware.com Wed Sep 23 22:45:08 2009 From: adam at qi-hardware.com (Adam Wang) Date: Thu, 24 Sep 2009 10:45:08 +0800 Subject: QI_AVT2 V1.0 Board In-Reply-To: <19ebea720909231806o52ded71ie2622e32a425b2dc@mail.gmail.com> References: <19ebea720909231806o52ded71ie2622e32a425b2dc@mail.gmail.com> Message-ID: <4ABADD34.2080905@qi-hardware.com> Hi Carlos Camargo wrote: > Hi > > My new qi_avt2 v1.0 arrived today, and I'm playing with it. I have > some comments about this board: > > 1. The keyboard pads can't fit exactly the ben layout. yes, but it still can work, need to change precisely placement.[1] > 2. SW1 is big, but the position is good, I think that we must replace > with a3 smaller one. yes, here i cut a long square hole so that's for sliding it. [2] > 3. CON3 is big and don't allow close the case. If you want to use the > serial port, is necessary disassemble the device. I think that we need > a right angle connector (like sw1), so we have access to serial port > from the battery "hole" from battery hole area, maybe we can find another place without changing more parts layout, but it's still need to evaluate.[3] This avt2 v1.0 tried to keep most partly layouts same as Ben initially and verify different layout shape of jz4720. So now the new shape layout for die is work, so we can do step by step and change additional layout way on others parts as well. But we still need s/w hacker to help us to test the stability. So we have now get 16 pcs {without glue die}can boot with 32MB SDRAM but 4 pcs I am still debugging them. Still working on this. > > I'm working an my new board, so wait more reports :) > enjoy that, i am also trying to fit it into Ben. but kind ugly a bit. The right side for micro-a plug have a gap there. [4][5] Adam [1] http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/report/photos/keypads.jpg [2] http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/report/photos/boot_switch.jpg [3] http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/report/photos/battery_serial_connector.jpg [4] http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/report/photos/whole_set.jpg [5] http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/report/photos/with_adapter.jpg > Carlos > > -- > Carlos Iv?n Camargo Bare?o > Profesor Asistente > Departamento de Ingenier?a El?ctrica y Electr?nica > Universidad Nacional de Colombia > cicamargoba at unal.edu.co > ------------------------------------------------------------------------ > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer -------------- next part -------------- An HTML attachment was scrubbed... URL: From kzjeef at gmail.com Thu Sep 24 02:02:31 2009 From: kzjeef at gmail.com (ZhangJieJing) Date: Thu, 24 Sep 2009 14:02:31 +0800 Subject: [PATCH] jz_battery: improve driver code. In-Reply-To: <4ABA1E6D.6070506@metafoo.de> References: <4ABA1E6D.6070506@metafoo.de> Message-ID: Hi, On Wed, Sep 23, 2009 at 9:11 PM, Lars-Peter Clausen wrote: > Hi >> 1. put all gobal var to a driver info struct. > You solution is not exaclty what I had in mind. You are still using a > global variable. I was talking about using > {platform,dev}_{get,set}_drvdata to avoid it. Please take a look at how > other drivers handle this. OK, I get it. >> 2. check gpio before use it. > You still register the usb and ac power supply even if the gpio is not vaild Ok, I add if condition before register power supply. > > Some more comments inlined: >> >> Signed-off-by: Jiejing.Zhang >> --- >> ?.../files-2.6.31/drivers/power/jz4740-battery.c ? ?| ?139 ++++++++++++-------- >> ?1 files changed, 81 insertions(+), 58 deletions(-) >> >> diff --git a/target/linux/xburst/files-2.6.31/drivers/power/jz4740-battery.c >> b/target/linux/xburst/files-2.6.31/drivers/power/jz4740-battery.c >> index de1f4e2..fccfc2e 100644 >> --- a/target/linux/xburst/files-2.6.31/drivers/power/jz4740-battery.c >> +++ b/target/linux/xburst/files-2.6.31/drivers/power/jz4740-battery.c >> @@ -23,16 +23,18 @@ >> ?#include >> ?#include >> >> -/*struct jz_battery {*/ >> - ? ? static int bat_status = POWER_SUPPLY_STATUS_DISCHARGING; >> - ? ? static struct jz_batt_info *pdata = 0; >> - >> +struct jz_battery_info { >> + ? ? int bat_status; >> + ? ? struct jz_batt_info *pdata; >> ? ? ? struct mutex work_lock; >> - >> ? ? ? struct workqueue_struct *monitor_wqueue; >> ? ? ? struct delayed_work bat_work; >> -/*};*/ >> +}; >> >> +static struct jz_battery_info jz_main_bat = { >> + ? ? .bat_status ? ? = POWER_SUPPLY_STATUS_DISCHARGING, >> + ? ? .pdata ? ? ? ? ?= 0, >> +}; >> >> ?/********************************************************************* >> ? * ? ? ? ? ? Power >> @@ -42,8 +44,13 @@ static int jz_get_power_prop(struct power_supply *psy, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? enum power_supply_property psp, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? union power_supply_propval *val) >> ?{ >> - ? ? int gpio = (psy->type == POWER_SUPPLY_TYPE_MAINS) ? pdata->dc_dect_gpio : >> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? pdata->usb_dect_gpio; >> + ? ? if (!jz_main_bat.pdata) >> + ? ? ? ? ? ? return -EINVAL; > It's enough if you check pdata in jz_bat_probe. If the check there fails > this function will never be called. >> + ? ? int gpio = (psy->type == POWER_SUPPLY_TYPE_MAINS) ? >> jz_main_bat.pdata->dc_dect_gpio : jz_main_bat.pdata->usb_dect_gpio; >> + >> + ? ? if (!gpio_is_valid(gpio)) >> + ? ? ? ? ? ? return -EINVAL; >> + >> ? ? ? switch (psp) { >> ? ? ? case POWER_SUPPLY_PROP_ONLINE: >> ? ? ? ? ? ? ? val->intval = !gpio_get_value(gpio); >> @@ -83,7 +90,10 @@ static struct power_supply jz_usb = { >> ?static long jz_read_bat(struct power_supply *bat_ps) >> ?{ >> ? ? ? enum jz_adc_battery_scale scale; >> - ? ? if (pdata->max_voltag > 2500000) >> + ? ? if (!jz_main_bat.pdata) >> + ? ? ? ? ? ? return -EINVAL; >> + >> + ? ? if (jz_main_bat.pdata->max_voltag > 2500000) >> ? ? ? ? ? ? ? scale = JZ_ADC_BATTERY_SCALE_7V5; >> ? ? ? else >> ? ? ? ? ? ? ? scale = JZ_ADC_BATTERY_SCALE_2V5; >> @@ -95,13 +105,16 @@ static int jz_bat_get_capacity(struct power_supply *bat_ps) >> ?{ >> ? ? ? int ret; >> >> + ? ? if (!jz_main_bat.pdata) >> + ? ? ? ? ? ? return -EINVAL; > dito >> + >> ? ? ? ret = jz_read_bat(bat_ps); >> >> ? ? ? if (ret < 0) >> ? ? ? ? ? ? ? return ret; >> >> - ? ? ret = (ret - pdata->min_voltag) * 100 >> - ? ? ? ? ? ? / (pdata->max_voltag - pdata->min_voltag); >> + ? ? ret = (ret - jz_main_bat.pdata->min_voltag) * 100 >> + ? ? ? ? ? ? / (jz_main_bat.pdata->max_voltag - jz_main_bat.pdata->min_voltag); >> >> ? ? ? if (ret > 100) >> ? ? ? ? ? ? ? ret = 100; >> @@ -115,15 +128,18 @@ static int jz_bat_get_property(struct >> power_supply *bat_ps, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? enum power_supply_property psp, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? union power_supply_propval *val) >> ?{ >> + ? ? if (!jz_main_bat.pdata) >> + ? ? ? ? ? ? return -EINVAL; > dito >> + >> ? ? ? switch (psp) { >> ? ? ? case POWER_SUPPLY_PROP_STATUS: >> - ? ? ? ? ? ? val->intval = bat_status; >> + ? ? ? ? ? ? val->intval = jz_main_bat.bat_status; >> ? ? ? ? ? ? ? break; >> ? ? ? case POWER_SUPPLY_PROP_TECHNOLOGY: >> - ? ? ? ? ? ? val->intval = pdata->batt_tech; >> + ? ? ? ? ? ? val->intval = jz_main_bat.pdata->batt_tech; >> ? ? ? ? ? ? ? break; >> ? ? ? case POWER_SUPPLY_PROP_HEALTH: >> - ? ? ? ? ? ? if(jz_read_bat(bat_ps) < pdata->min_voltag) { >> + ? ? ? ? ? ? if(jz_read_bat(bat_ps) < jz_main_bat.pdata->min_voltag) { >> ? ? ? ? ? ? ? ? ? ? ? dev_dbg(bat_ps->dev, "%s: battery is dead," >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "voltage too low!\n", __func__); >> ? ? ? ? ? ? ? ? ? ? ? val->intval = POWER_SUPPLY_HEALTH_DEAD; >> @@ -145,10 +161,10 @@ static int jz_bat_get_property(struct >> power_supply *bat_ps, >> ? ? ? ? ? ? ? break; >> ? ? ? case POWER_SUPPLY_PROP_VOLTAGE_MAX: >> ? ? ? case POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN: >> - ? ? ? ? ? ? val->intval = pdata->max_voltag; >> + ? ? ? ? ? ? val->intval = jz_main_bat.pdata->max_voltag; >> ? ? ? ? ? ? ? break; >> ? ? ? case POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN: >> - ? ? ? ? ? ? val->intval = pdata->min_voltag; >> + ? ? ? ? ? ? val->intval = jz_main_bat.pdata->min_voltag; >> ? ? ? ? ? ? ? break; >> ? ? ? case POWER_SUPPLY_PROP_PRESENT: >> ? ? ? ? ? ? ? val->intval = 1; >> @@ -161,8 +177,8 @@ static int jz_bat_get_property(struct power_supply *bat_ps, >> >> ?static void jz_bat_external_power_changed(struct power_supply *bat_ps) >> ?{ >> - ? ? cancel_delayed_work(&bat_work); >> - ? ? queue_delayed_work(monitor_wqueue, &bat_work, HZ / 8); >> + ? ? cancel_delayed_work(&jz_main_bat.bat_work); >> + ? ? queue_delayed_work(jz_main_bat.monitor_wqueue, &jz_main_bat.bat_work, HZ / 8); >> ?} >> >> ?static char *status_text[] = { >> @@ -174,31 +190,38 @@ static char *status_text[] = { >> >> ?static void jz_bat_update(struct power_supply *bat_ps) >> ?{ >> - ? ? int old_status = bat_status; >> + ? ? int old_status = jz_main_bat.bat_status; >> ? ? ? static unsigned long old_batt_vol = 0; >> ? ? ? unsigned long batt_vol = jz_read_bat(bat_ps); >> - ? ? mutex_lock(&work_lock); >> + ? ? mutex_lock(&jz_main_bat.work_lock); >> + >> + ? ? if (!jz_main_bat.pdata) >> + ? ? ? ? ? ? goto err; > dito >> + >> + ? ? if (!gpio_is_valid(jz_main_bat.pdata->charg_stat_gpio)) >> + ? ? ? ? ? ? goto err; > You should still handle voltage changes OK. >> >> - ? ? if(!gpio_get_value(pdata->charg_stat_gpio)) >> - ? ? ? ? ? ? bat_status = POWER_SUPPLY_STATUS_CHARGING; >> + ? ? if(!gpio_get_value(jz_main_bat.pdata->charg_stat_gpio)) >> + ? ? ? ? ? ? jz_main_bat.bat_status = POWER_SUPPLY_STATUS_CHARGING; >> ? ? ? else >> - ? ? ? ? ? ? bat_status = POWER_SUPPLY_STATUS_NOT_CHARGING; >> + ? ? ? ? ? ? jz_main_bat.bat_status = POWER_SUPPLY_STATUS_NOT_CHARGING; >> >> ? ? ? dev_dbg(bat_ps->dev, "%s: battery status=%s\n", >> - ? ? ? ? ? ? __func__, status_text[bat_status]); >> + ? ? ? ? ? ? __func__, status_text[jz_main_bat.bat_status]); >> >> - ? ? if ((old_status != bat_status) || >> + ? ? if ((old_status != jz_main_bat.bat_status) || >> ? ? ? ? ? ? ? (old_batt_vol - batt_vol > 50000)) { >> ? ? ? ? ? ? ? dev_dbg(bat_ps->dev, "%s %s -> %s\n", >> ? ? ? ? ? ? ? ? ? ? ? ?bat_ps->name, >> ? ? ? ? ? ? ? ? ? ? ? ?status_text[old_status], >> - ? ? ? ? ? ? ? ? ? ? ?status_text[bat_status]); >> + ? ? ? ? ? ? ? ? ? ? ?status_text[jz_main_bat.bat_status]); >> >> ? ? ? ? ? ? ? power_supply_changed(bat_ps); >> ? ? ? } >> >> ? ? ? old_batt_vol = batt_vol; >> - ? ? mutex_unlock(&work_lock); >> +err: >> + ? ? mutex_unlock(&jz_main_bat.work_lock); >> ?} >> >> ?static enum power_supply_property jz_bat_main_props[] = { >> @@ -228,22 +251,22 @@ static void jz_bat_work(struct work_struct *work) >> ? ? ? const int interval = HZ * 30; >> >> ? ? ? jz_bat_update(&bat_ps); >> - ? ? queue_delayed_work(monitor_wqueue, &bat_work, interval); >> + ? ? queue_delayed_work(jz_main_bat.monitor_wqueue, >> &jz_main_bat.bat_work, interval); >> ?} >> >> ?#ifdef CONFIG_PM >> ?static int jz_bat_suspend(struct platform_device *dev, pm_message_t state) >> ?{ >> - ? ? bat_status = ?POWER_SUPPLY_STATUS_UNKNOWN; >> + ? ? jz_main_bat.bat_status = ?POWER_SUPPLY_STATUS_UNKNOWN; >> >> ? ? ? return 0; >> ?} >> >> ?static int jz_bat_resume(struct platform_device *dev) >> ?{ >> - ? ? bat_status = ?POWER_SUPPLY_STATUS_UNKNOWN; >> - ? ? cancel_delayed_work(&bat_work); >> - ? ? queue_delayed_work(monitor_wqueue, &bat_work, HZ/10); >> + ? ? jz_main_bat.bat_status = ?POWER_SUPPLY_STATUS_UNKNOWN; >> + ? ? cancel_delayed_work(&jz_main_bat.bat_work); >> + ? ? queue_delayed_work(jz_main_bat.monitor_wqueue, &jz_main_bat.bat_work, HZ/10); >> >> ? ? ? return 0; >> ?} >> @@ -257,24 +280,24 @@ static int __devinit jz_bat_probe(struct >> platform_device *pdev) >> ? ? ? int ret = 0; >> >> ? ? ? printk("JZ battery init.\n"); >> - ? ? mutex_init(&work_lock); >> - ? ? INIT_DELAYED_WORK(&bat_work, jz_bat_work); >> + ? ? mutex_init(&jz_main_bat.work_lock); >> + ? ? INIT_DELAYED_WORK(&jz_main_bat.bat_work, jz_bat_work); >> >> ? ? ? if (!pdev->dev.platform_data) { >> ? ? ? ? ? ? ? dev_err(&pdev->dev, "Please set battery info\n"); >> ? ? ? ? ? ? ? return -EINVAL; >> ? ? ? } >> >> - ? ? pdata = pdev->dev.platform_data; >> + ? ? jz_main_bat.pdata = pdev->dev.platform_data; >> >> - ? ? if (gpio_is_valid(pdata->dc_dect_gpio)) { >> - ? ? ? ? ? ? ret = gpio_request(pdata->dc_dect_gpio, "AC/DC DECT"); >> + ? ? if (gpio_is_valid(jz_main_bat.pdata->dc_dect_gpio)) { >> + ? ? ? ? ? ? ret = gpio_request(jz_main_bat.pdata->dc_dect_gpio, "AC/DC DECT"); >> ? ? ? ? ? ? ? if (ret) { >> ? ? ? ? ? ? ? ? ? ? ? dev_err(&pdev->dev, "ac/dc dect gpio request failed.\n"); >> >> ? ? ? ? ? ? ? ? ? ? ? goto err_dc_gpio_request; >> ? ? ? ? ? ? ? } >> - ? ? ? ? ? ? ret = gpio_direction_input(pdata->dc_dect_gpio); >> + ? ? ? ? ? ? ret = gpio_direction_input(jz_main_bat.pdata->dc_dect_gpio); >> ? ? ? ? ? ? ? if (ret) { >> ? ? ? ? ? ? ? ? ? ? ? dev_err(&pdev->dev, "ac/dc dect gpio direction failed.\n"); >> >> @@ -282,30 +305,30 @@ static int __devinit jz_bat_probe(struct >> platform_device *pdev) >> ? ? ? ? ? ? ? } >> ? ? ? } >> >> - ? ? if (gpio_is_valid(pdata->usb_dect_gpio)) { >> - ? ? ? ? ? ? ret = gpio_request(pdata->usb_dect_gpio, "USB DECT"); >> + ? ? if (gpio_is_valid(jz_main_bat.pdata->usb_dect_gpio)) { >> + ? ? ? ? ? ? ret = gpio_request(jz_main_bat.pdata->usb_dect_gpio, "USB DECT"); >> ? ? ? ? ? ? ? if (ret) { >> ? ? ? ? ? ? ? ? ? ? ? dev_err(&pdev->dev, "usb dect gpio request failed.\n"); >> >> ? ? ? ? ? ? ? ? ? ? ? goto err_usb_gpio_request; >> ? ? ? ? ? ? ? } >> - ? ? ? ? ? ? ret = gpio_direction_input(pdata->usb_dect_gpio); >> + ? ? ? ? ? ? ret = gpio_direction_input(jz_main_bat.pdata->usb_dect_gpio); >> ? ? ? ? ? ? ? if (ret) { >> ? ? ? ? ? ? ? ? ? ? ? dev_err(&pdev->dev, "usb dect gpio set direction failed.\n"); >> ? ? ? ? ? ? ? ? ? ? ? goto err_usb_gpio_direction; >> ? ? ? ? ? ? ? } >> >> - ? ? ? ? ? ? jz_gpio_disable_pullup(pdata->usb_dect_gpio); >> + ? ? ? ? ? ? jz_gpio_disable_pullup(jz_main_bat.pdata->usb_dect_gpio); >> ? ? ? ? ? ? ? /* TODO: Use generic gpio is better */ >> ? ? ? } >> >> - ? ? if (gpio_is_valid(pdata->charg_stat_gpio)) { >> - ? ? ? ? ? ? ret = gpio_request(pdata->charg_stat_gpio, "CHARG STAT"); >> + ? ? if (gpio_is_valid(jz_main_bat.pdata->charg_stat_gpio)) { >> + ? ? ? ? ? ? ret = gpio_request(jz_main_bat.pdata->charg_stat_gpio, "CHARG STAT"); >> ? ? ? ? ? ? ? if (ret) { >> ? ? ? ? ? ? ? ? ? ? ? dev_err(&pdev->dev, "charger state gpio request failed.\n"); >> ? ? ? ? ? ? ? ? ? ? ? goto err_charg_gpio_request; >> ? ? ? ? ? ? ? } >> - ? ? ? ? ? ? ret = gpio_direction_input(pdata->charg_stat_gpio); >> + ? ? ? ? ? ? ret = gpio_direction_input(jz_main_bat.pdata->charg_stat_gpio); >> ? ? ? ? ? ? ? if (ret) { >> ? ? ? ? ? ? ? ? ? ? ? dev_err(&pdev->dev, "charger state gpio set direction failed.\n"); >> ? ? ? ? ? ? ? ? ? ? ? goto err_charg_gpio_direction; >> @@ -331,11 +354,11 @@ static int __devinit jz_bat_probe(struct >> platform_device *pdev) >> ? ? ? } >> >> ? ? ? if (!ret) { >> - ? ? ? ? ? ? monitor_wqueue = create_singlethread_workqueue("jz_battery"); >> - ? ? ? ? ? ? if (!monitor_wqueue) { >> + ? ? ? ? ? ? jz_main_bat.monitor_wqueue = create_singlethread_workqueue("jz_battery"); >> + ? ? ? ? ? ? if (!jz_main_bat.monitor_wqueue) { >> ? ? ? ? ? ? ? ? ? ? ? return -ESRCH; >> ? ? ? ? ? ? ? } >> - ? ? ? ? ? ? queue_delayed_work(monitor_wqueue, &bat_work, HZ * 1); >> + ? ? ? ? ? ? queue_delayed_work(jz_main_bat.monitor_wqueue, >> &jz_main_bat.bat_work, HZ * 1); >> ? ? ? } >> >> ? ? ? return ret; >> @@ -346,26 +369,26 @@ err_power_register_usb: >> ? ? ? power_supply_unregister(&jz_ac); >> ?err_power_register_ac: >> ?err_charg_gpio_direction: >> - ? ? gpio_free(pdata->charg_stat_gpio); >> + ? ? gpio_free(jz_main_bat.pdata->charg_stat_gpio); >> ?err_charg_gpio_request: >> ?err_usb_gpio_direction: >> - ? ? gpio_free(pdata->usb_dect_gpio); >> + ? ? gpio_free(jz_main_bat.pdata->usb_dect_gpio); >> ?err_usb_gpio_request: >> ?err_dc_gpio_direction: >> - ? ? gpio_free(pdata->dc_dect_gpio); >> + ? ? gpio_free(jz_main_bat.pdata->dc_dect_gpio); >> ?err_dc_gpio_request: >> ? ? ? return ret; >> ?} >> >> ?static int __devexit jz_bat_remove(struct platform_device *dev) >> ?{ >> - ? ? if (pdata) { >> - ? ? ? ? ? ? if (gpio_is_valid(pdata->dc_dect_gpio)) >> - ? ? ? ? ? ? ? ? ? ? gpio_free(pdata->dc_dect_gpio); >> - ? ? ? ? ? ? if (gpio_is_valid(pdata->usb_dect_gpio)) >> - ? ? ? ? ? ? ? ? ? ? gpio_free(pdata->usb_dect_gpio); >> - ? ? ? ? ? ? if (gpio_is_valid(pdata->charg_stat_gpio)) >> - ? ? ? ? ? ? ? ? ? ? gpio_free(pdata->charg_stat_gpio); >> + ? ? if (jz_main_bat.pdata) { >> + ? ? ? ? ? ? if (gpio_is_valid(jz_main_bat.pdata->dc_dect_gpio)) >> + ? ? ? ? ? ? ? ? ? ? gpio_free(jz_main_bat.pdata->dc_dect_gpio); >> + ? ? ? ? ? ? if (gpio_is_valid(jz_main_bat.pdata->usb_dect_gpio)) >> + ? ? ? ? ? ? ? ? ? ? gpio_free(jz_main_bat.pdata->usb_dect_gpio); >> + ? ? ? ? ? ? if (gpio_is_valid(jz_main_bat.pdata->charg_stat_gpio)) >> + ? ? ? ? ? ? ? ? ? ? gpio_free(jz_main_bat.pdata->charg_stat_gpio); >> ? ? ? } >> >> ? ? ? power_supply_unregister(&bat_ps); >> > > - Lars > From kzjeef at gmail.com Thu Sep 24 06:13:54 2009 From: kzjeef at gmail.com (ZhangJieJing) Date: Thu, 24 Sep 2009 18:13:54 +0800 Subject: [PATCH] jz_battery: improve driver code. In-Reply-To: References: <4ABA1E6D.6070506@metafoo.de> Message-ID: Hi, lars On Thu, Sep 24, 2009 at 2:02 PM, ZhangJieJing wrote: > Hi, > > On Wed, Sep 23, 2009 at 9:11 PM, Lars-Peter Clausen wrote: >> Hi >>> 1. put all gobal var to a driver info struct. >> You solution is not exaclty what I had in mind. You are still using a >> global variable. I was talking about using >> {platform,dev}_{get,set}_drvdata to avoid it. Please take a look at how >> other drivers handle this. > I change the static var to the drvdata. but I don't know how to get this ptr in static void jz_bat_work(struct work_struct *work) ? other function use blow function get drvdata ptr. static inline struct jz_battery_info *ps_to_jz_battery(struct power_supply *psy) { return container_of(psy, struct jz_battery_info, psy); } could give me some advice? > OK, I get it. > >>> 2. check gpio before use it. >> You still register the usb and ac power supply even if the gpio is not vaild > > Ok, I add if condition before register power supply. > >> >> Some more comments inlined: >>> >>> Signed-off-by: Jiejing.Zhang >>> --- >>> ?.../files-2.6.31/drivers/power/jz4740-battery.c ? ?| ?139 ++++++++++++-------- >>> ?1 files changed, 81 insertions(+), 58 deletions(-) >>> >>> diff --git a/target/linux/xburst/files-2.6.31/drivers/power/jz4740-battery.c >>> b/target/linux/xburst/files-2.6.31/drivers/power/jz4740-battery.c >>> index de1f4e2..fccfc2e 100644 >>> --- a/target/linux/xburst/files-2.6.31/drivers/power/jz4740-battery.c >>> +++ b/target/linux/xburst/files-2.6.31/drivers/power/jz4740-battery.c >>> @@ -23,16 +23,18 @@ >>> ?#include >>> ?#include >>> >>> -/*struct jz_battery {*/ >>> - ? ? static int bat_status = POWER_SUPPLY_STATUS_DISCHARGING; >>> - ? ? static struct jz_batt_info *pdata = 0; >>> - >>> +struct jz_battery_info { >>> + ? ? int bat_status; >>> + ? ? struct jz_batt_info *pdata; >>> ? ? ? struct mutex work_lock; >>> - >>> ? ? ? struct workqueue_struct *monitor_wqueue; >>> ? ? ? struct delayed_work bat_work; >>> -/*};*/ >>> +}; >>> >>> +static struct jz_battery_info jz_main_bat = { >>> + ? ? .bat_status ? ? = POWER_SUPPLY_STATUS_DISCHARGING, >>> + ? ? .pdata ? ? ? ? ?= 0, >>> +}; >>> >>> ?/********************************************************************* >>> ? * ? ? ? ? ? Power >>> @@ -42,8 +44,13 @@ static int jz_get_power_prop(struct power_supply *psy, >>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? enum power_supply_property psp, >>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? union power_supply_propval *val) >>> ?{ >>> - ? ? int gpio = (psy->type == POWER_SUPPLY_TYPE_MAINS) ? pdata->dc_dect_gpio : >>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? pdata->usb_dect_gpio; >>> + ? ? if (!jz_main_bat.pdata) >>> + ? ? ? ? ? ? return -EINVAL; >> It's enough if you check pdata in jz_bat_probe. If the check there fails >> this function will never be called. >>> + ? ? int gpio = (psy->type == POWER_SUPPLY_TYPE_MAINS) ? >>> jz_main_bat.pdata->dc_dect_gpio : jz_main_bat.pdata->usb_dect_gpio; >>> + >>> + ? ? if (!gpio_is_valid(gpio)) >>> + ? ? ? ? ? ? return -EINVAL; >>> + >>> ? ? ? switch (psp) { >>> ? ? ? case POWER_SUPPLY_PROP_ONLINE: >>> ? ? ? ? ? ? ? val->intval = !gpio_get_value(gpio); >>> @@ -83,7 +90,10 @@ static struct power_supply jz_usb = { >>> ?static long jz_read_bat(struct power_supply *bat_ps) >>> ?{ >>> ? ? ? enum jz_adc_battery_scale scale; >>> - ? ? if (pdata->max_voltag > 2500000) >>> + ? ? if (!jz_main_bat.pdata) >>> + ? ? ? ? ? ? return -EINVAL; >>> + >>> + ? ? if (jz_main_bat.pdata->max_voltag > 2500000) >>> ? ? ? ? ? ? ? scale = JZ_ADC_BATTERY_SCALE_7V5; >>> ? ? ? else >>> ? ? ? ? ? ? ? scale = JZ_ADC_BATTERY_SCALE_2V5; >>> @@ -95,13 +105,16 @@ static int jz_bat_get_capacity(struct power_supply *bat_ps) >>> ?{ >>> ? ? ? int ret; >>> >>> + ? ? if (!jz_main_bat.pdata) >>> + ? ? ? ? ? ? return -EINVAL; >> dito >>> + >>> ? ? ? ret = jz_read_bat(bat_ps); >>> >>> ? ? ? if (ret < 0) >>> ? ? ? ? ? ? ? return ret; >>> >>> - ? ? ret = (ret - pdata->min_voltag) * 100 >>> - ? ? ? ? ? ? / (pdata->max_voltag - pdata->min_voltag); >>> + ? ? ret = (ret - jz_main_bat.pdata->min_voltag) * 100 >>> + ? ? ? ? ? ? / (jz_main_bat.pdata->max_voltag - jz_main_bat.pdata->min_voltag); >>> >>> ? ? ? if (ret > 100) >>> ? ? ? ? ? ? ? ret = 100; >>> @@ -115,15 +128,18 @@ static int jz_bat_get_property(struct >>> power_supply *bat_ps, >>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? enum power_supply_property psp, >>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? union power_supply_propval *val) >>> ?{ >>> + ? ? if (!jz_main_bat.pdata) >>> + ? ? ? ? ? ? return -EINVAL; >> dito >>> + >>> ? ? ? switch (psp) { >>> ? ? ? case POWER_SUPPLY_PROP_STATUS: >>> - ? ? ? ? ? ? val->intval = bat_status; >>> + ? ? ? ? ? ? val->intval = jz_main_bat.bat_status; >>> ? ? ? ? ? ? ? break; >>> ? ? ? case POWER_SUPPLY_PROP_TECHNOLOGY: >>> - ? ? ? ? ? ? val->intval = pdata->batt_tech; >>> + ? ? ? ? ? ? val->intval = jz_main_bat.pdata->batt_tech; >>> ? ? ? ? ? ? ? break; >>> ? ? ? case POWER_SUPPLY_PROP_HEALTH: >>> - ? ? ? ? ? ? if(jz_read_bat(bat_ps) < pdata->min_voltag) { >>> + ? ? ? ? ? ? if(jz_read_bat(bat_ps) < jz_main_bat.pdata->min_voltag) { >>> ? ? ? ? ? ? ? ? ? ? ? dev_dbg(bat_ps->dev, "%s: battery is dead," >>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "voltage too low!\n", __func__); >>> ? ? ? ? ? ? ? ? ? ? ? val->intval = POWER_SUPPLY_HEALTH_DEAD; >>> @@ -145,10 +161,10 @@ static int jz_bat_get_property(struct >>> power_supply *bat_ps, >>> ? ? ? ? ? ? ? break; >>> ? ? ? case POWER_SUPPLY_PROP_VOLTAGE_MAX: >>> ? ? ? case POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN: >>> - ? ? ? ? ? ? val->intval = pdata->max_voltag; >>> + ? ? ? ? ? ? val->intval = jz_main_bat.pdata->max_voltag; >>> ? ? ? ? ? ? ? break; >>> ? ? ? case POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN: >>> - ? ? ? ? ? ? val->intval = pdata->min_voltag; >>> + ? ? ? ? ? ? val->intval = jz_main_bat.pdata->min_voltag; >>> ? ? ? ? ? ? ? break; >>> ? ? ? case POWER_SUPPLY_PROP_PRESENT: >>> ? ? ? ? ? ? ? val->intval = 1; >>> @@ -161,8 +177,8 @@ static int jz_bat_get_property(struct power_supply *bat_ps, >>> >>> ?static void jz_bat_external_power_changed(struct power_supply *bat_ps) >>> ?{ >>> - ? ? cancel_delayed_work(&bat_work); >>> - ? ? queue_delayed_work(monitor_wqueue, &bat_work, HZ / 8); >>> + ? ? cancel_delayed_work(&jz_main_bat.bat_work); >>> + ? ? queue_delayed_work(jz_main_bat.monitor_wqueue, &jz_main_bat.bat_work, HZ / 8); >>> ?} >>> >>> ?static char *status_text[] = { >>> @@ -174,31 +190,38 @@ static char *status_text[] = { >>> >>> ?static void jz_bat_update(struct power_supply *bat_ps) >>> ?{ >>> - ? ? int old_status = bat_status; >>> + ? ? int old_status = jz_main_bat.bat_status; >>> ? ? ? static unsigned long old_batt_vol = 0; >>> ? ? ? unsigned long batt_vol = jz_read_bat(bat_ps); >>> - ? ? mutex_lock(&work_lock); >>> + ? ? mutex_lock(&jz_main_bat.work_lock); >>> + >>> + ? ? if (!jz_main_bat.pdata) >>> + ? ? ? ? ? ? goto err; >> dito >>> + >>> + ? ? if (!gpio_is_valid(jz_main_bat.pdata->charg_stat_gpio)) >>> + ? ? ? ? ? ? goto err; >> You should still handle voltage changes > > OK. > > >>> >>> - ? ? if(!gpio_get_value(pdata->charg_stat_gpio)) >>> - ? ? ? ? ? ? bat_status = POWER_SUPPLY_STATUS_CHARGING; >>> + ? ? if(!gpio_get_value(jz_main_bat.pdata->charg_stat_gpio)) >>> + ? ? ? ? ? ? jz_main_bat.bat_status = POWER_SUPPLY_STATUS_CHARGING; >>> ? ? ? else >>> - ? ? ? ? ? ? bat_status = POWER_SUPPLY_STATUS_NOT_CHARGING; >>> + ? ? ? ? ? ? jz_main_bat.bat_status = POWER_SUPPLY_STATUS_NOT_CHARGING; >>> >>> ? ? ? dev_dbg(bat_ps->dev, "%s: battery status=%s\n", >>> - ? ? ? ? ? ? __func__, status_text[bat_status]); >>> + ? ? ? ? ? ? __func__, status_text[jz_main_bat.bat_status]); >>> >>> - ? ? if ((old_status != bat_status) || >>> + ? ? if ((old_status != jz_main_bat.bat_status) || >>> ? ? ? ? ? ? ? (old_batt_vol - batt_vol > 50000)) { >>> ? ? ? ? ? ? ? dev_dbg(bat_ps->dev, "%s %s -> %s\n", >>> ? ? ? ? ? ? ? ? ? ? ? ?bat_ps->name, >>> ? ? ? ? ? ? ? ? ? ? ? ?status_text[old_status], >>> - ? ? ? ? ? ? ? ? ? ? ?status_text[bat_status]); >>> + ? ? ? ? ? ? ? ? ? ? ?status_text[jz_main_bat.bat_status]); >>> >>> ? ? ? ? ? ? ? power_supply_changed(bat_ps); >>> ? ? ? } >>> >>> ? ? ? old_batt_vol = batt_vol; >>> - ? ? mutex_unlock(&work_lock); >>> +err: >>> + ? ? mutex_unlock(&jz_main_bat.work_lock); >>> ?} >>> >>> ?static enum power_supply_property jz_bat_main_props[] = { >>> @@ -228,22 +251,22 @@ static void jz_bat_work(struct work_struct *work) >>> ? ? ? const int interval = HZ * 30; >>> >>> ? ? ? jz_bat_update(&bat_ps); >>> - ? ? queue_delayed_work(monitor_wqueue, &bat_work, interval); >>> + ? ? queue_delayed_work(jz_main_bat.monitor_wqueue, >>> &jz_main_bat.bat_work, interval); >>> ?} >>> >>> ?#ifdef CONFIG_PM >>> ?static int jz_bat_suspend(struct platform_device *dev, pm_message_t state) >>> ?{ >>> - ? ? bat_status = ?POWER_SUPPLY_STATUS_UNKNOWN; >>> + ? ? jz_main_bat.bat_status = ?POWER_SUPPLY_STATUS_UNKNOWN; >>> >>> ? ? ? return 0; >>> ?} >>> >>> ?static int jz_bat_resume(struct platform_device *dev) >>> ?{ >>> - ? ? bat_status = ?POWER_SUPPLY_STATUS_UNKNOWN; >>> - ? ? cancel_delayed_work(&bat_work); >>> - ? ? queue_delayed_work(monitor_wqueue, &bat_work, HZ/10); >>> + ? ? jz_main_bat.bat_status = ?POWER_SUPPLY_STATUS_UNKNOWN; >>> + ? ? cancel_delayed_work(&jz_main_bat.bat_work); >>> + ? ? queue_delayed_work(jz_main_bat.monitor_wqueue, &jz_main_bat.bat_work, HZ/10); >>> >>> ? ? ? return 0; >>> ?} >>> @@ -257,24 +280,24 @@ static int __devinit jz_bat_probe(struct >>> platform_device *pdev) >>> ? ? ? int ret = 0; >>> >>> ? ? ? printk("JZ battery init.\n"); >>> - ? ? mutex_init(&work_lock); >>> - ? ? INIT_DELAYED_WORK(&bat_work, jz_bat_work); >>> + ? ? mutex_init(&jz_main_bat.work_lock); >>> + ? ? INIT_DELAYED_WORK(&jz_main_bat.bat_work, jz_bat_work); >>> >>> ? ? ? if (!pdev->dev.platform_data) { >>> ? ? ? ? ? ? ? dev_err(&pdev->dev, "Please set battery info\n"); >>> ? ? ? ? ? ? ? return -EINVAL; >>> ? ? ? } >>> >>> - ? ? pdata = pdev->dev.platform_data; >>> + ? ? jz_main_bat.pdata = pdev->dev.platform_data; >>> >>> - ? ? if (gpio_is_valid(pdata->dc_dect_gpio)) { >>> - ? ? ? ? ? ? ret = gpio_request(pdata->dc_dect_gpio, "AC/DC DECT"); >>> + ? ? if (gpio_is_valid(jz_main_bat.pdata->dc_dect_gpio)) { >>> + ? ? ? ? ? ? ret = gpio_request(jz_main_bat.pdata->dc_dect_gpio, "AC/DC DECT"); >>> ? ? ? ? ? ? ? if (ret) { >>> ? ? ? ? ? ? ? ? ? ? ? dev_err(&pdev->dev, "ac/dc dect gpio request failed.\n"); >>> >>> ? ? ? ? ? ? ? ? ? ? ? goto err_dc_gpio_request; >>> ? ? ? ? ? ? ? } >>> - ? ? ? ? ? ? ret = gpio_direction_input(pdata->dc_dect_gpio); >>> + ? ? ? ? ? ? ret = gpio_direction_input(jz_main_bat.pdata->dc_dect_gpio); >>> ? ? ? ? ? ? ? if (ret) { >>> ? ? ? ? ? ? ? ? ? ? ? dev_err(&pdev->dev, "ac/dc dect gpio direction failed.\n"); >>> >>> @@ -282,30 +305,30 @@ static int __devinit jz_bat_probe(struct >>> platform_device *pdev) >>> ? ? ? ? ? ? ? } >>> ? ? ? } >>> >>> - ? ? if (gpio_is_valid(pdata->usb_dect_gpio)) { >>> - ? ? ? ? ? ? ret = gpio_request(pdata->usb_dect_gpio, "USB DECT"); >>> + ? ? if (gpio_is_valid(jz_main_bat.pdata->usb_dect_gpio)) { >>> + ? ? ? ? ? ? ret = gpio_request(jz_main_bat.pdata->usb_dect_gpio, "USB DECT"); >>> ? ? ? ? ? ? ? if (ret) { >>> ? ? ? ? ? ? ? ? ? ? ? dev_err(&pdev->dev, "usb dect gpio request failed.\n"); >>> >>> ? ? ? ? ? ? ? ? ? ? ? goto err_usb_gpio_request; >>> ? ? ? ? ? ? ? } >>> - ? ? ? ? ? ? ret = gpio_direction_input(pdata->usb_dect_gpio); >>> + ? ? ? ? ? ? ret = gpio_direction_input(jz_main_bat.pdata->usb_dect_gpio); >>> ? ? ? ? ? ? ? if (ret) { >>> ? ? ? ? ? ? ? ? ? ? ? dev_err(&pdev->dev, "usb dect gpio set direction failed.\n"); >>> ? ? ? ? ? ? ? ? ? ? ? goto err_usb_gpio_direction; >>> ? ? ? ? ? ? ? } >>> >>> - ? ? ? ? ? ? jz_gpio_disable_pullup(pdata->usb_dect_gpio); >>> + ? ? ? ? ? ? jz_gpio_disable_pullup(jz_main_bat.pdata->usb_dect_gpio); >>> ? ? ? ? ? ? ? /* TODO: Use generic gpio is better */ >>> ? ? ? } >>> >>> - ? ? if (gpio_is_valid(pdata->charg_stat_gpio)) { >>> - ? ? ? ? ? ? ret = gpio_request(pdata->charg_stat_gpio, "CHARG STAT"); >>> + ? ? if (gpio_is_valid(jz_main_bat.pdata->charg_stat_gpio)) { >>> + ? ? ? ? ? ? ret = gpio_request(jz_main_bat.pdata->charg_stat_gpio, "CHARG STAT"); >>> ? ? ? ? ? ? ? if (ret) { >>> ? ? ? ? ? ? ? ? ? ? ? dev_err(&pdev->dev, "charger state gpio request failed.\n"); >>> ? ? ? ? ? ? ? ? ? ? ? goto err_charg_gpio_request; >>> ? ? ? ? ? ? ? } >>> - ? ? ? ? ? ? ret = gpio_direction_input(pdata->charg_stat_gpio); >>> + ? ? ? ? ? ? ret = gpio_direction_input(jz_main_bat.pdata->charg_stat_gpio); >>> ? ? ? ? ? ? ? if (ret) { >>> ? ? ? ? ? ? ? ? ? ? ? dev_err(&pdev->dev, "charger state gpio set direction failed.\n"); >>> ? ? ? ? ? ? ? ? ? ? ? goto err_charg_gpio_direction; >>> @@ -331,11 +354,11 @@ static int __devinit jz_bat_probe(struct >>> platform_device *pdev) >>> ? ? ? } >>> >>> ? ? ? if (!ret) { >>> - ? ? ? ? ? ? monitor_wqueue = create_singlethread_workqueue("jz_battery"); >>> - ? ? ? ? ? ? if (!monitor_wqueue) { >>> + ? ? ? ? ? ? jz_main_bat.monitor_wqueue = create_singlethread_workqueue("jz_battery"); >>> + ? ? ? ? ? ? if (!jz_main_bat.monitor_wqueue) { >>> ? ? ? ? ? ? ? ? ? ? ? return -ESRCH; >>> ? ? ? ? ? ? ? } >>> - ? ? ? ? ? ? queue_delayed_work(monitor_wqueue, &bat_work, HZ * 1); >>> + ? ? ? ? ? ? queue_delayed_work(jz_main_bat.monitor_wqueue, >>> &jz_main_bat.bat_work, HZ * 1); >>> ? ? ? } >>> >>> ? ? ? return ret; >>> @@ -346,26 +369,26 @@ err_power_register_usb: >>> ? ? ? power_supply_unregister(&jz_ac); >>> ?err_power_register_ac: >>> ?err_charg_gpio_direction: >>> - ? ? gpio_free(pdata->charg_stat_gpio); >>> + ? ? gpio_free(jz_main_bat.pdata->charg_stat_gpio); >>> ?err_charg_gpio_request: >>> ?err_usb_gpio_direction: >>> - ? ? gpio_free(pdata->usb_dect_gpio); >>> + ? ? gpio_free(jz_main_bat.pdata->usb_dect_gpio); >>> ?err_usb_gpio_request: >>> ?err_dc_gpio_direction: >>> - ? ? gpio_free(pdata->dc_dect_gpio); >>> + ? ? gpio_free(jz_main_bat.pdata->dc_dect_gpio); >>> ?err_dc_gpio_request: >>> ? ? ? return ret; >>> ?} >>> >>> ?static int __devexit jz_bat_remove(struct platform_device *dev) >>> ?{ >>> - ? ? if (pdata) { >>> - ? ? ? ? ? ? if (gpio_is_valid(pdata->dc_dect_gpio)) >>> - ? ? ? ? ? ? ? ? ? ? gpio_free(pdata->dc_dect_gpio); >>> - ? ? ? ? ? ? if (gpio_is_valid(pdata->usb_dect_gpio)) >>> - ? ? ? ? ? ? ? ? ? ? gpio_free(pdata->usb_dect_gpio); >>> - ? ? ? ? ? ? if (gpio_is_valid(pdata->charg_stat_gpio)) >>> - ? ? ? ? ? ? ? ? ? ? gpio_free(pdata->charg_stat_gpio); >>> + ? ? if (jz_main_bat.pdata) { >>> + ? ? ? ? ? ? if (gpio_is_valid(jz_main_bat.pdata->dc_dect_gpio)) >>> + ? ? ? ? ? ? ? ? ? ? gpio_free(jz_main_bat.pdata->dc_dect_gpio); >>> + ? ? ? ? ? ? if (gpio_is_valid(jz_main_bat.pdata->usb_dect_gpio)) >>> + ? ? ? ? ? ? ? ? ? ? gpio_free(jz_main_bat.pdata->usb_dect_gpio); >>> + ? ? ? ? ? ? if (gpio_is_valid(jz_main_bat.pdata->charg_stat_gpio)) >>> + ? ? ? ? ? ? ? ? ? ? gpio_free(jz_main_bat.pdata->charg_stat_gpio); >>> ? ? ? } >>> >>> ? ? ? power_supply_unregister(&bat_ps); >>> >> >> - Lars >> > From lars at metafoo.de Thu Sep 24 06:27:53 2009 From: lars at metafoo.de (Lars-Peter Clausen) Date: Thu, 24 Sep 2009 12:27:53 +0200 Subject: [PATCH] jz_battery: improve driver code. In-Reply-To: References: <4ABA1E6D.6070506@metafoo.de> Message-ID: <4ABB49A9.4010308@metafoo.de> Hi > Hi, lars > > On Thu, Sep 24, 2009 at 2:02 PM, ZhangJieJing > wrote: >> Hi, >> >> On Wed, Sep 23, 2009 at 9:11 PM, Lars-Peter Clausen >> wrote: >>> Hi >>>> 1. put all gobal var to a driver info struct. >>> You solution is not exaclty what I had in mind. You are still >>> using a global variable. I was talking about using >>> {platform,dev}_{get,set}_drvdata to avoid it. Please take a >>> look at how other drivers handle this. > > I change the static var to the drvdata. > > but I don't know how to get this ptr in static void > jz_bat_work(struct work_struct *work) ? > > other function use blow function get drvdata ptr. > > static inline struct jz_battery_info *ps_to_jz_battery(struct > power_supply *psy) { return container_of(psy, struct > jz_battery_info, psy); } > > could give me some advice? > > Sure. You can use containter_of there. work is a pointer to the bat_work struct in jz_battery_info. Something like container_of(work, struct jz_battery_info, bat_work) should do it. - Lars Hi > Hi, lars > > On Thu, Sep 24, 2009 at 2:02 PM, ZhangJieJing > wrote: >> Hi, >> >> On Wed, Sep 23, 2009 at 9:11 PM, Lars-Peter Clausen >> wrote: >>> Hi >>>> 1. put all gobal var to a driver info struct. >>> You solution is not exaclty what I had in mind. You are still >>> using a global variable. I was talking about using >>> {platform,dev}_{get,set}_drvdata to avoid it. Please take a >>> look at how other drivers handle this. > > I change the static var to the drvdata. > > but I don't know how to get this ptr in static void > jz_bat_work(struct work_struct *work) ? > > other function use blow function get drvdata ptr. > > static inline struct jz_battery_info *ps_to_jz_battery(struct > power_supply *psy) { return container_of(psy, struct > jz_battery_info, psy); } > > could give me some advice? > > Sure. You can use containter_of there. work is a pointer to the bat_work struct in jz_battery_info. Something like container_of(work, struct jz_battery_info, bat_work) should do it. - Lars From xiangfu at qi-hardware.com Thu Sep 24 09:18:11 2009 From: xiangfu at qi-hardware.com (Xiangfu Liu) Date: Thu, 24 Sep 2009 21:18:11 +0800 Subject: QI_AVT2 V1.0 Board In-Reply-To: <4ABADD34.2080905@qi-hardware.com> References: <19ebea720909231806o52ded71ie2622e32a425b2dc@mail.gmail.com> <4ABADD34.2080905@qi-hardware.com> Message-ID: <4ABB7193.9070302@qi-hardware.com> Adam Wang wrote: > [4] > http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/report/photos/whole_set.jpg Yi Zhang wrote: > However, our ESD test for CE certification has failed. The problem is on > USB connector. It is not grounded, close to the power button, therefore > easy to produce static, the lab engineer has told me. The engineers of > our vendor are working on the solutions. Hi Adam. the USB host, USB device, headphone all at the right side. is it will have problem on the CE certification ?? (I just mention that, I am not good at hardware :-) how many people like the usb_host_connecter at the left side? thanks for advice Best Regards Xiangfu From adam at qi-hardware.com Thu Sep 24 12:24:15 2009 From: adam at qi-hardware.com (Adam Wang) Date: Fri, 25 Sep 2009 00:24:15 +0800 Subject: QI_AVT2 V1.0 Board In-Reply-To: <4ABADD34.2080905@qi-hardware.com> References: <19ebea720909231806o52ded71ie2622e32a425b2dc@mail.gmail.com> <4ABADD34.2080905@qi-hardware.com> Message-ID: <4ABB9D2F.1030300@qi-hardware.com> Hi, We just have new status on running 64MB SDRAM. [1] Currently we have 3pcs of avt2 board replaced successfully from 32MB, we are now on the process about replacing all 16pcs bootable ones. Will keep you posted later. Adam [1] http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/datasheet/U8~MT48LC32M16A2P-75~64MB.pdf here is the u-boot output: --------------------------------------------------- NAND Secondary Program Loader  U-Boot 2009.06-00378-gd4cee0e-dirty (Sep 24 2009 - 16:45:22) Board: Qi LB60 (Ingenic XBurst Jz4740 SoC, Speed 336 MHz) DRAM: 64 MB NAND: 2048 MiB *** Warning - bad CRC or NAND, using default environment here is the part of kernel output: --------------------------------------------------- Linux version 2.6.31-rc6-g25c9ad7-dirty (xiangfu at xiangfu-macbook) (gcc version 4.1.2) #27 PREEMPT Mon Sep 14 23:00:45 CST 2009 console [early0] enabled CPU revision is: 0ad0024f (Ingenic JZRISC) Power Management for JZ CPU clock: 336MHz, System clock: 112MHz, Peripheral clock: 112MHz, Memory clock: 112MHz Qi Hardware JZ4740 QI_LB60 setup Determined physical RAM map: memory: 04000000 @ 00000000 (usable) User-defined physical RAM map: memory: 04000000 @ 00000000 (usable) Zone PFN ranges: Normal 0x00000000 -> 0x00004000 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0x00000000 -> 0x00004000 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 Kernel command line: mem=64M console=ttyS0,57600n8 rootfstype=jffs2 root=/dev/mtdblock2 rw rootdelay=2 here is the /proc/meminfo --------------------------------------------------- BusyBox v1.13.4 (2009-09-03 02:14:36 CST) built-in shell (ash) Enter 'help' for a list of built-in commands. _______ ________ __ | |.-----.-----.-----.| | | |.----.| |_ | - || _ | -__| || | | || _|| _| |_______|| __|_____|__|__||________||__| |____| |__| W I R E L E S S F R E E D O M KAMIKAZE (bleeding edge, r17569) ------------------- * 10 oz Vodka Shake well with ice and strain * 10 oz Triple sec mixture into 10 shot glasses. * 10 oz lime juice Salute! --------------------------------------------------- root at OpenWrt:/# more /proc/meminfo MemTotal: 61712 kB MemFree: 47060 kB Buffers: 0 kB Cached: 6052 kB SwapCached: 0 kB Active: 3484 kB Inactive: 3224 kB Active(anon): 700 kB Inactive(anon): 0 kB Active(file): 2784 kB Inactive(file): 3224 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 0 kB SwapFree: 0 kB Dirty: 0 kB Writeback: 0 kB AnonPages: 676 kB Mapped: 788 kB Slab: 1932 kB SReclaimable: 412 kB SUnreclaim: 1520 kB PageTables: 132 kB From lars at metafoo.de Thu Sep 24 14:40:28 2009 From: lars at metafoo.de (Lars-Peter Clausen) Date: Thu, 24 Sep 2009 20:40:28 +0200 Subject: some more updates from the software part In-Reply-To: <20090924020913.GA4261@debian> References: <1253486666.11044.886.camel@mia> <20090923102740.GA2924@debian> <4ABA62DC.6080104@metafoo.de> <20090924020913.GA4261@debian> Message-ID: <4ABBBD1C.9070101@metafoo.de> Hi Wolfgang Spraul wrote: > Lars, > > >> They use a more evolutionary approach when it comes to patching the >> Ingenic sources, it's not that much of a cleanup or rewrite as opposed >> to what we did. >> > > OK got it. > Let me explain my plan a bit and see what you think: > Right now, Ingenic is publishing their work on the Linux kernel on a daily > basis, through our servers. Cross your fingers that it keeps working, but > right now I see updates until 2 days ago, so it seems to work. > Ingenic works on two kernel versions, 2.6.24.3 and 2.6.27. > > The way I see it is that people like you, Mirko, and many other upstream > Linux folks have abilities that the in-house Ingenic engineers don't have, > and will not have in the foreseeable future. > Such as English skills, and ability to quickly communicate with upstream, > understand the 'big picture' kernel architecture and interface changes. > Whereas the Ingenic engineers know their chips much better than we do, so > they can fix specific bugs much more effectively, and bring out the features > of the chips. > > I like that you do a more radical approach to cleaning up the Ingenic > patches, because when we have reached a good enough level and completeness, > I can ask Ingenic to re-base their work on top of our kernel. > It gives us the chance to define the architecture and interfaces for them, > and they fill in the details. > That way I believe we are all working with our respective strengths. > > What do you think? Does this make sense? > I understand we only work on 1 board right now (the Ben NanoNote), and only > care for a few peripherals (well you have the 4740 EVB as well now...) > I think for basic support for the peripherals found in the nanonote we are feature complete. But beyond that there is no support. > But at which point do you believe would it make sense for us to ask > Ingenic to up-level to our kernel? > Should we introduce some more 'boilerplate' code for them, just take some > more drivers over into a better architectural structure, even if those > drivers don't work or have commented-out code. And then ask Ingenic > to see whether they want to continue on that basis? > I don't know when it would make sense to ask Ingenic when to use our kernel as a base. That's because I don't know what Ingenic needs support for before they consider it. In my opinion you should ask them what it would take for them to switch. But actually I'm not sure if they will consider a switch anyway, because on the short term apparently their approach seems to work well enough for them. Switching on the other hand would require additional work and resources, which they might not be willing to invest. - Lars > Right now they will continue on the 2.6.24.3 and 2.6.27 trees. They mostly > run Android on the 2.6.27 tree (that's the reason they started with this > kernel version in the first place). > > This is basically what I had in mind. Any thoughts? > Wolfgang > > On Wed, Sep 23, 2009 at 08:03:08PM +0200, Lars-Peter Clausen wrote: > >>> Hi, just thought I point you to this other git repository with >>> quite a bit of Ingenic hacking going on: >>> >>> http://git.openinkpot.org/linux-2.6.git/ >>> >>> The OpenInkpot guys are working on a 4740 based Hanvon N516 e-book, >>> and are doing some cleaning up and rewriting of Ingenic drivers as >>> well. I have heard about work in the I2C driver, USB client, LCM >>> and NAND. I just thought I pass the URL along in case it's not >>> known yet... Wolfgang >>> >> Hi >> >> Yup, I've been monitoring their repository for some time now. >> Unfortunately I didn't had the chance to take to Yauhen Kharuzhy yet. >> >> They use a more evolutionary approach when it comes to patching the >> Ingenic sources, it's not that much of a cleanup or rewrite as opposed >> to what we did. And most of the things they do are not relevant for >> the nanonote anyway. >> >> Never the less we should strive towards a common code base. I'll try >> to make contact in the next days. We'll see then what will necessary >> to archive this. >> >> - Lars >> From kzjeef at gmail.com Thu Sep 24 22:39:13 2009 From: kzjeef at gmail.com (ZhangJieJing) Date: Fri, 25 Sep 2009 10:39:13 +0800 Subject: [PATCH] jz_battery: improve driver code. In-Reply-To: <4ABB49A9.4010308@metafoo.de> References: <4ABA1E6D.6070506@metafoo.de> <4ABB49A9.4010308@metafoo.de> Message-ID: 1. clear static global var, use platform_get_drvdata. 2. check gpio state before register power supply. Signed-off-by: Jiejing.Zhang --- .../files-2.6.31/drivers/power/jz4740-battery.c | 265 +++++++++++--------- 1 files changed, 146 insertions(+), 119 deletions(-) diff --git a/target/linux/xburst/files-2.6.31/drivers/power/jz4740-battery.c b/target/linux/xburst/files-2.6.31/drivers/power/jz4740-battery.c index fccfc2e..2229833 100644 --- a/target/linux/xburst/files-2.6.31/drivers/power/jz4740-battery.c +++ b/target/linux/xburst/files-2.6.31/drivers/power/jz4740-battery.c @@ -24,6 +24,7 @@ #include struct jz_battery_info { + struct power_supply psy; int bat_status; struct jz_batt_info *pdata; struct mutex work_lock; @@ -31,10 +32,10 @@ struct jz_battery_info { struct delayed_work bat_work; }; -static struct jz_battery_info jz_main_bat = { - .bat_status = POWER_SUPPLY_STATUS_DISCHARGING, - .pdata = 0, -}; +static inline struct jz_battery_info *ps_to_jz_battery(struct power_supply *psy) +{ + return container_of(psy, struct jz_battery_info, psy); +} /********************************************************************* * Power @@ -44,9 +45,9 @@ static int jz_get_power_prop(struct power_supply *psy, enum power_supply_property psp, union power_supply_propval *val) { - if (!jz_main_bat.pdata) - return -EINVAL; - int gpio = (psy->type == POWER_SUPPLY_TYPE_MAINS) ? jz_main_bat.pdata->dc_dect_gpio : jz_main_bat.pdata->usb_dect_gpio; + struct jz_battery_info *bat_info = ps_to_jz_battery(psy); + + int gpio = (psy->type == POWER_SUPPLY_TYPE_MAINS) ? bat_info->pdata->dc_dect_gpio : bat_info->pdata->usb_dect_gpio; if (!gpio_is_valid(gpio)) return -EINVAL; @@ -87,34 +88,31 @@ static struct power_supply jz_usb = { * Battery properties *********************************************************************/ -static long jz_read_bat(struct power_supply *bat_ps) +static long jz_read_bat(struct power_supply *psy) { + struct jz_battery_info *bat_info = ps_to_jz_battery(psy); enum jz_adc_battery_scale scale; - if (!jz_main_bat.pdata) - return -EINVAL; - if (jz_main_bat.pdata->max_voltag > 2500000) + if (bat_info->pdata->max_voltag > 2500000) scale = JZ_ADC_BATTERY_SCALE_7V5; else scale = JZ_ADC_BATTERY_SCALE_2V5; - return jz4740_adc_read_battery_voltage(bat_ps->dev->parent->parent, scale); + return jz4740_adc_read_battery_voltage(psy->dev->parent->parent, scale); } -static int jz_bat_get_capacity(struct power_supply *bat_ps) +static int jz_bat_get_capacity(struct power_supply *psy) { int ret; + struct jz_battery_info *bat_info = ps_to_jz_battery(psy); - if (!jz_main_bat.pdata) - return -EINVAL; - - ret = jz_read_bat(bat_ps); + ret = jz_read_bat(psy); if (ret < 0) return ret; - ret = (ret - jz_main_bat.pdata->min_voltag) * 100 - / (jz_main_bat.pdata->max_voltag - jz_main_bat.pdata->min_voltag); + ret = (ret - bat_info->pdata->min_voltag) * 100 + / (bat_info->pdata->max_voltag - bat_info->pdata->min_voltag); if (ret > 100) ret = 100; @@ -124,47 +122,46 @@ static int jz_bat_get_capacity(struct power_supply *bat_ps) return ret; } -static int jz_bat_get_property(struct power_supply *bat_ps, +static int jz_bat_get_property(struct power_supply *psy, enum power_supply_property psp, union power_supply_propval *val) { - if (!jz_main_bat.pdata) - return -EINVAL; - + struct jz_battery_info *bat_info = ps_to_jz_battery(psy); + switch (psp) { case POWER_SUPPLY_PROP_STATUS: - val->intval = jz_main_bat.bat_status; + val->intval = bat_info->bat_status; break; case POWER_SUPPLY_PROP_TECHNOLOGY: - val->intval = jz_main_bat.pdata->batt_tech; + val->intval = bat_info->pdata->batt_tech; break; case POWER_SUPPLY_PROP_HEALTH: - if(jz_read_bat(bat_ps) < jz_main_bat.pdata->min_voltag) { - dev_dbg(bat_ps->dev, "%s: battery is dead," + if(jz_read_bat(psy) < bat_info->pdata->min_voltag) { + dev_dbg(psy->dev, "%s: battery is dead," "voltage too low!\n", __func__); val->intval = POWER_SUPPLY_HEALTH_DEAD; } else { - dev_dbg(bat_ps->dev, "%s: battery is good," + dev_dbg(psy->dev, "%s: battery is good," "voltage normal.\n", __func__); val->intval = POWER_SUPPLY_HEALTH_GOOD; } break; case POWER_SUPPLY_PROP_CAPACITY: - val->intval = jz_bat_get_capacity(bat_ps); - dev_dbg(bat_ps->dev, "%s: battery_capacity = %d\n", + val->intval = jz_bat_get_capacity(psy); + dev_dbg(psy->dev, "%s: battery_capacity = %d\n", __func__, val->intval); break; case POWER_SUPPLY_PROP_VOLTAGE_NOW: - val->intval = jz_read_bat(bat_ps); + val->intval = jz_read_bat(psy); if (val->intval < 0) return val->intval; break; case POWER_SUPPLY_PROP_VOLTAGE_MAX: case POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN: - val->intval = jz_main_bat.pdata->max_voltag; + val->intval = bat_info->pdata->max_voltag; break; case POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN: - val->intval = jz_main_bat.pdata->min_voltag; + val->intval = bat_info->pdata->min_voltag; break; case POWER_SUPPLY_PROP_PRESENT: val->intval = 1; @@ -175,10 +172,12 @@ static int jz_bat_get_property(struct power_supply *bat_ps, return 0; } -static void jz_bat_external_power_changed(struct power_supply *bat_ps) +static void jz_bat_external_power_changed(struct power_supply *psy) { - cancel_delayed_work(&jz_main_bat.bat_work); - queue_delayed_work(jz_main_bat.monitor_wqueue, &jz_main_bat.bat_work, HZ / 8); + struct jz_battery_info *bat_info = ps_to_jz_battery(psy); + + cancel_delayed_work(&bat_info->bat_work); + queue_delayed_work(bat_info->monitor_wqueue, &bat_info->bat_work, HZ / 8); } static char *status_text[] = { @@ -188,40 +187,42 @@ static char *status_text[] = { [POWER_SUPPLY_STATUS_NOT_CHARGING] = "Not charging", }; -static void jz_bat_update(struct power_supply *bat_ps) +static void jz_bat_update(struct power_supply *psy) { - int old_status = jz_main_bat.bat_status; + struct jz_battery_info *bat_info = ps_to_jz_battery(psy); + + int old_status = bat_info->bat_status; static unsigned long old_batt_vol = 0; - unsigned long batt_vol = jz_read_bat(bat_ps); - mutex_lock(&jz_main_bat.work_lock); - - if (!jz_main_bat.pdata) - goto err; - - if (!gpio_is_valid(jz_main_bat.pdata->charg_stat_gpio)) - goto err; - - if(!gpio_get_value(jz_main_bat.pdata->charg_stat_gpio)) - jz_main_bat.bat_status = POWER_SUPPLY_STATUS_CHARGING; - else - jz_main_bat.bat_status = POWER_SUPPLY_STATUS_NOT_CHARGING; - - dev_dbg(bat_ps->dev, "%s: battery status=%s\n", - __func__, status_text[jz_main_bat.bat_status]); - - if ((old_status != jz_main_bat.bat_status) || - (old_batt_vol - batt_vol > 50000)) { - dev_dbg(bat_ps->dev, "%s %s -> %s\n", - bat_ps->name, - status_text[old_status], - status_text[jz_main_bat.bat_status]); + unsigned long batt_vol = jz_read_bat(psy); + + mutex_lock(&bat_info->work_lock); + + if (gpio_is_valid(bat_info->pdata->charg_stat_gpio)) { + if(!gpio_get_value(bat_info->pdata->charg_stat_gpio)) + bat_info->bat_status = POWER_SUPPLY_STATUS_CHARGING; + else + bat_info->bat_status = POWER_SUPPLY_STATUS_NOT_CHARGING; + dev_dbg(psy->dev, "%s: battery status=%s\n", + __func__, status_text[bat_info->bat_status]); + + if (old_status != bat_info->bat_status) { + dev_dbg(psy->dev, "%s %s -> %s\n", + psy->name, + status_text[old_status], + status_text[bat_info->bat_status]); + + power_supply_changed(psy); + } + } - power_supply_changed(bat_ps); + if (old_batt_vol - batt_vol > 50000) { + dev_dbg(psy->dev, "voltage change : %ld -> %ld\n", + old_batt_vol, batt_vol); + power_supply_changed(psy); + old_batt_vol = batt_vol; } - old_batt_vol = batt_vol; -err: - mutex_unlock(&jz_main_bat.work_lock); + mutex_unlock(&bat_info->work_lock); } static enum power_supply_property jz_bat_main_props[] = { @@ -249,24 +250,31 @@ static void jz_bat_work(struct work_struct *work) { /* query interval too small will increase system workload*/ const int interval = HZ * 30; - + struct jz_battery_info *bat_info = container_of(work,struct jz_battery_info, bat_work); + jz_bat_update(&bat_ps); - queue_delayed_work(jz_main_bat.monitor_wqueue, &jz_main_bat.bat_work, interval); + queue_delayed_work(bat_info->monitor_wqueue, + &bat_info->bat_work, interval); } #ifdef CONFIG_PM -static int jz_bat_suspend(struct platform_device *dev, pm_message_t state) +static int jz_bat_suspend(struct platform_device *pdev, pm_message_t state) { - jz_main_bat.bat_status = POWER_SUPPLY_STATUS_UNKNOWN; + struct jz_battery_info *bat_info = platform_get_drvdata(pdev); + + bat_info->bat_status = POWER_SUPPLY_STATUS_UNKNOWN; return 0; } -static int jz_bat_resume(struct platform_device *dev) +static int jz_bat_resume(struct platform_device *pdev) { - jz_main_bat.bat_status = POWER_SUPPLY_STATUS_UNKNOWN; - cancel_delayed_work(&jz_main_bat.bat_work); - queue_delayed_work(jz_main_bat.monitor_wqueue, &jz_main_bat.bat_work, HZ/10); + struct jz_battery_info *bat_info = platform_get_drvdata(pdev); + + bat_info->bat_status = POWER_SUPPLY_STATUS_UNKNOWN; + + cancel_delayed_work(&bat_info->bat_work); + queue_delayed_work(bat_info->monitor_wqueue, &bat_info->bat_work, HZ/10); return 0; } @@ -278,26 +286,37 @@ static int jz_bat_resume(struct platform_device *dev) static int __devinit jz_bat_probe(struct platform_device *pdev) { int ret = 0; - + struct jz_battery_info *bat_info; + printk("JZ battery init.\n"); - mutex_init(&jz_main_bat.work_lock); - INIT_DELAYED_WORK(&jz_main_bat.bat_work, jz_bat_work); + + bat_info = kzalloc(sizeof(struct jz_battery_info), GFP_KERNEL); + if (!bat_info) { + return -ENOMEM; + } + + platform_set_drvdata(pdev, bat_info); + + mutex_init(&bat_info->work_lock); + INIT_DELAYED_WORK(&bat_info->bat_work, jz_bat_work); if (!pdev->dev.platform_data) { dev_err(&pdev->dev, "Please set battery info\n"); - return -EINVAL; + ret = -EINVAL; + goto err_platform_data; } - jz_main_bat.pdata = pdev->dev.platform_data; + + bat_info->pdata = pdev->dev.platform_data; - if (gpio_is_valid(jz_main_bat.pdata->dc_dect_gpio)) { - ret = gpio_request(jz_main_bat.pdata->dc_dect_gpio, "AC/DC DECT"); + if (gpio_is_valid(bat_info->pdata->dc_dect_gpio)) { + ret = gpio_request(bat_info->pdata->dc_dect_gpio, "AC/DC DECT"); if (ret) { dev_err(&pdev->dev, "ac/dc dect gpio request failed.\n"); goto err_dc_gpio_request; } - ret = gpio_direction_input(jz_main_bat.pdata->dc_dect_gpio); + ret = gpio_direction_input(bat_info->pdata->dc_dect_gpio); if (ret) { dev_err(&pdev->dev, "ac/dc dect gpio direction failed.\n"); @@ -305,60 +324,64 @@ static int __devinit jz_bat_probe(struct platform_device *pdev) } } - if (gpio_is_valid(jz_main_bat.pdata->usb_dect_gpio)) { - ret = gpio_request(jz_main_bat.pdata->usb_dect_gpio, "USB DECT"); + if (gpio_is_valid(bat_info->pdata->usb_dect_gpio)) { + ret = gpio_request(bat_info->pdata->usb_dect_gpio, "USB DECT"); if (ret) { dev_err(&pdev->dev, "usb dect gpio request failed.\n"); goto err_usb_gpio_request; } - ret = gpio_direction_input(jz_main_bat.pdata->usb_dect_gpio); + ret = gpio_direction_input(bat_info->pdata->usb_dect_gpio); if (ret) { dev_err(&pdev->dev, "usb dect gpio set direction failed.\n"); goto err_usb_gpio_direction; } - jz_gpio_disable_pullup(jz_main_bat.pdata->usb_dect_gpio); + jz_gpio_disable_pullup(bat_info->pdata->usb_dect_gpio); /* TODO: Use generic gpio is better */ } - if (gpio_is_valid(jz_main_bat.pdata->charg_stat_gpio)) { - ret = gpio_request(jz_main_bat.pdata->charg_stat_gpio, "CHARG STAT"); + if (gpio_is_valid(bat_info->pdata->charg_stat_gpio)) { + ret = gpio_request(bat_info->pdata->charg_stat_gpio, "CHARG STAT"); if (ret) { dev_err(&pdev->dev, "charger state gpio request failed.\n"); goto err_charg_gpio_request; } - ret = gpio_direction_input(jz_main_bat.pdata->charg_stat_gpio); + ret = gpio_direction_input(bat_info->pdata->charg_stat_gpio); if (ret) { dev_err(&pdev->dev, "charger state gpio set direction failed.\n"); goto err_charg_gpio_direction; } } - - ret = power_supply_register(&pdev->dev, &jz_ac); - if (ret) { - dev_err(&pdev->dev, "power supply ac/dc register failed.\n"); - goto err_power_register_ac; - } - - ret = power_supply_register(&pdev->dev, &jz_usb); - if (ret) { - dev_err(&pdev->dev, "power supply usb register failed.\n"); - goto err_power_register_usb; + + if (gpio_is_valid(bat_info->pdata->dc_dect_gpio)) { + ret = power_supply_register(&pdev->dev, &jz_ac); + if (ret) { + dev_err(&pdev->dev, "power supply ac/dc register failed.\n"); + goto err_power_register_ac; + } } - ret = power_supply_register(&pdev->dev, &bat_ps); - if (ret) { - dev_err(&pdev->dev, "power supply battery register failed.\n"); - goto err_power_register_bat; + if (gpio_is_valid(bat_info->pdata->usb_dect_gpio)) { + ret = power_supply_register(&pdev->dev, &jz_usb); + if (ret) { + dev_err(&pdev->dev, "power supply usb register failed.\n"); + goto err_power_register_usb; + } } - if (!ret) { - jz_main_bat.monitor_wqueue = create_singlethread_workqueue("jz_battery"); - if (!jz_main_bat.monitor_wqueue) { - return -ESRCH; + if (gpio_is_valid(bat_info->pdata->charg_stat_gpio)) { + ret = power_supply_register(&pdev->dev, &bat_ps); + if (ret) { + dev_err(&pdev->dev, "power supply battery register failed.\n"); + goto err_power_register_bat; + } else { + bat_info->monitor_wqueue = create_singlethread_workqueue("jz_battery"); + if (!bat_info->monitor_wqueue) { + return -ESRCH; + } + queue_delayed_work(bat_info->monitor_wqueue, &bat_info->bat_work, HZ * 1); } - queue_delayed_work(jz_main_bat.monitor_wqueue, &jz_main_bat.bat_work, HZ * 1); } return ret; @@ -369,26 +392,30 @@ err_power_register_usb: power_supply_unregister(&jz_ac); err_power_register_ac: err_charg_gpio_direction: - gpio_free(jz_main_bat.pdata->charg_stat_gpio); + gpio_free(bat_info->pdata->charg_stat_gpio); err_charg_gpio_request: err_usb_gpio_direction: - gpio_free(jz_main_bat.pdata->usb_dect_gpio); + gpio_free(bat_info->pdata->usb_dect_gpio); err_usb_gpio_request: err_dc_gpio_direction: - gpio_free(jz_main_bat.pdata->dc_dect_gpio); + gpio_free(bat_info->pdata->dc_dect_gpio); err_dc_gpio_request: +err_platform_data: + kfree(bat_info); return ret; } -static int __devexit jz_bat_remove(struct platform_device *dev) +static int __devexit jz_bat_remove(struct platform_device *pdev) { - if (jz_main_bat.pdata) { - if (gpio_is_valid(jz_main_bat.pdata->dc_dect_gpio)) - gpio_free(jz_main_bat.pdata->dc_dect_gpio); - if (gpio_is_valid(jz_main_bat.pdata->usb_dect_gpio)) - gpio_free(jz_main_bat.pdata->usb_dect_gpio); - if (gpio_is_valid(jz_main_bat.pdata->charg_stat_gpio)) - gpio_free(jz_main_bat.pdata->charg_stat_gpio); + struct jz_battery_info *bat_info = platform_get_drvdata(pdev); + + if (bat_info->pdata) { + if (gpio_is_valid(bat_info->pdata->dc_dect_gpio)) + gpio_free(bat_info->pdata->dc_dect_gpio); + if (gpio_is_valid(bat_info->pdata->usb_dect_gpio)) + gpio_free(bat_info->pdata->usb_dect_gpio); + if (gpio_is_valid(bat_info->pdata->charg_stat_gpio)) + gpio_free(bat_info->pdata->charg_stat_gpio); } power_supply_unregister(&bat_ps); -- 1.6.0.4 From adam at qi-hardware.com Fri Sep 25 06:03:55 2009 From: adam at qi-hardware.com (Adam Wang) Date: Fri, 25 Sep 2009 18:03:55 +0800 Subject: QI_AVT2 V1.0 Board In-Reply-To: <4ABB7193.9070302@qi-hardware.com> References: <19ebea720909231806o52ded71ie2622e32a425b2dc@mail.gmail.com> <4ABADD34.2080905@qi-hardware.com> <4ABB7193.9070302@qi-hardware.com> Message-ID: <4ABC958B.8070906@qi-hardware.com> Hi, Xiangfu Liu wrote: > Adam Wang wrote: > >> [4] >> http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/report/photos/whole_set.jpg >> > > Yi Zhang wrote: > >> However, our ESD test for CE certification has failed. The problem is on >> USB connector. It is not grounded, close to the power button, therefore >> easy to produce static, the lab engineer has told me. The engineers of >> our vendor are working on the solutions. >> > > Hi Adam. > the USB host, USB device, headphone all at the right side. > is it will have problem on the CE certification ?? > The probability is pretty high, this version is trying to keep the same Ben's board outline and most components' layout; so we focus the functionalities on usb host, little features-added and new die's layout shape firstly, not reliability-oriented this time. But from Yi's report, the ways proposed to eliminate failure must be added-in if it only change components; for additional ESD or EMI parts added on new design, will always be the trade-off and design-in stuff between limited board space and parts placement (different classification of signals arranging). This avt2 v1.0 is facing compression effect caused by new added-on parts without changing pcb layers and outline, it has met risks already. but it's worth to have this prototype first. so we still need s/w can help us to find out that if any defects behind. > (I just mention that, I am not good at hardware :-) > > ha, me too; especially on linux software. :-) > how many people like the usb_host_connecter at the left side? > thanks for advice > I don't know either. Hope any comments to be proposed. Adam > Best Regards > Xiangfu > > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cicamargoba at gmail.com Sat Sep 26 23:49:38 2009 From: cicamargoba at gmail.com (Carlos Camargo) Date: Sat, 26 Sep 2009 22:49:38 -0500 Subject: stuff we should port to the NanoNote Message-ID: <19ebea720909262049o49abc32cv4fd91aecc005f73b@mail.gmail.com> Hi I'm thinking in some stuff we should port to Nano: getty: We can use getty to create a serial console when we use g_serial octave: GNU Octave is a high-level language, primarily intended for numerical computations.[1] mp3 player: curses based mp3 player like [2], [3] These tools are text based, so, I think is not difficult add them to openwrt, and we can provide some extra-functionality to Nano. [1] http://www.gnu.org/software/octave/ [2] http://www.cse.unsw.edu.au/~dons/hmp3.html [3] http://www-users.cs.umn.edu/~wburdick/gamp/#shots Carlos -- Carlos Iv?n Camargo Bare?o Profesor Asistente Departamento de Ingenier?a El?ctrica y Electr?nica Universidad Nacional de Colombia cicamargoba at unal.edu.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjeffries at gmail.com Sun Sep 27 00:14:08 2009 From: rjeffries at gmail.com (Ron K. Jeffries) Date: Sat, 26 Sep 2009 21:14:08 -0700 Subject: stuff we should port to the NanoNote In-Reply-To: <19ebea720909262049o49abc32cv4fd91aecc005f73b@mail.gmail.com> References: <19ebea720909262049o49abc32cv4fd91aecc005f73b@mail.gmail.com> Message-ID: <886128c30909262114j774b3f56lc032a93613c7c3f4@mail.gmail.com> Re: apps for NanoNote Shouldn't NanoNote (the machine) also support Nano (the editor)? Nothing wrong with vi, but ordinary citizens will find Nano the editor easier to use, because one only needs to remember one or two magic keys. --- Ron K. Jeffries From wolfgang at qi-hardware.com Sun Sep 27 00:44:13 2009 From: wolfgang at qi-hardware.com (Wolfgang Spraul) Date: Sun, 27 Sep 2009 00:44:13 -0400 Subject: stuff we should port to the NanoNote In-Reply-To: <19ebea720909262049o49abc32cv4fd91aecc005f73b@mail.gmail.com> References: <19ebea720909262049o49abc32cv4fd91aecc005f73b@mail.gmail.com> Message-ID: <20090927044413.GA10966@debian> Carlos, > mp3 player: curses based mp3 player like [2], [3] We need to keep MP3 and probably also MP4 out, at least from anything Qi Hardware officially offers. The patent situation is pretty bad. Ogg Vorbis any time, of course. Wolfgang On Sat, Sep 26, 2009 at 10:49:38PM -0500, Carlos Camargo wrote: > Hi > > I'm thinking in some stuff we should port to Nano: > > getty: We can use getty to create a serial console when we use g_serial > octave: GNU Octave is a high-level language, primarily intended for > numerical computations.[1] > mp3 player: curses based mp3 player like [2], [3] > > These tools are text based, so, I think is not difficult add them to > openwrt, and we can provide some extra-functionality to Nano. > > [1] http://www.gnu.org/software/octave/ > [2] http://www.cse.unsw.edu.au/~dons/hmp3.html > [3] http://www-users.cs.umn.edu/~wburdick/gamp/#shots > > > > Carlos > > -- > Carlos Iv?n Camargo Bare?o > Profesor Asistente > Departamento de Ingenier?a El?ctrica y Electr?nica > Universidad Nacional de Colombia > cicamargoba at unal.edu.co > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer From iggarpe at gmail.com Mon Sep 28 13:29:55 2009 From: iggarpe at gmail.com (=?ISO-8859-1?Q?Ignacio_Garc=EDa_P=E9rez?=) Date: Mon, 28 Sep 2009 19:29:55 +0200 Subject: configure mpd/mpc in openwrt. music player in Ben NanoNote In-Reply-To: References: <4AA463E5.5090802@qi-hardware.com> <19ebea720909071630t1a680beexf5d62ec2084090ba@mail.gmail.com> <4AA5B590.5000000@qi-hardware.com> <9f2feba00909110240s4169fe78mfe38db486e30fc1d@mail.gmail.com> Message-ID: <9f2feba00909281029l5290da66y423c5da9fbf1db40@mail.gmail.com> (sorry for taking so long to reply... somehow this message got buried in the inbox) 2009/9/11 ZhangJieJing > > 2009/9/11 Ignacio Garc?a P?rez > >> I never got ALSA to work on the A320 (dingux). Instead I tried OSS and as >> it worked I forgot about ALSA. The OSS > > > what type OSS, from I know , ALSA have an emulated OSS plugin, or a pure > OSS driver? > A pure OSS driver. ALSA is very advanced, but IMHO way too engineered for an embedded device with such a limited memory. Last time I compiled ALSA for the JZ4740 I ended up with a 1MB shared library (and that's the usespace part only). What the hell have the put there?. The downside is that the OSS code in the Ingenic kernel is cleary deprecated. It is very dirty and buggy. Had to fix several things to make it usable. > > code, though, seems to be deprecated by Ingenic and is very very very ugly >> and buggy. Had to make several fixes to get sample rates other than S16_LE >> working. However, sticking to OSS because "it just works" is probably only >> acceptable in the A320 case because it is intended to be used as a gaming >> console and as such almost eveybody is using the SDL, which dingux provides >> precompiled and configured for OSS. >> >> 2009/9/8 ZhangJieJing >> >> Hi, >>> >>> Sound card on my kernel tree is just can be found by alsa driver, But the >>> driver have problem with DMA(jz's driver use too old DMA method) I 'm trying >>> to fix it. >>> >>> The sound cann't play for now. >>> --- >>> Best regards, >>> Zhang Jiejing >>> >>> >>> >>> On Tue, Sep 8, 2009 at 9:38 AM, Xiangfu Liu wrote: >>> >>>> Carlos Camargo wrote: >>>> > Hi >>>> > >>>> > We are trying to test the sound driver, with alsa, mplayer, but >>>> doesn't >>>> > work :( The Qi kernel source support the JZ sound driver? If not, >>>> where >>>> > can I foun information about this driver? >>>> >>>> the Qi kernel not support JZ sound driver not. Jieijing Zhang and larsc >>>> work on that. >>>> >>>> you can find the Jieijing Zhange sound code: >>>> >>>> http://projects.qi-hardware.com/index.php/p/kzjeef-kernel/source/changes/master/ >>>> >>>> you can find JZ 2.6.27 sound driver at: >>>> >>>> http://downloads.qi-hardware.com/software/sources/linux-2.6.27.git.svn.tgz >>>> >>>> > >>>> > >>>> > $ scripts/feeds install mpd >>>> > $ scripts/feeds install mpc >>>> >>>> run 'scripts/feeds update' before install mpd/mpc. >>>> >>>> > >>>> > I try to run this command but I get the following error: >>>> > >>>> > Ignoring feed 'packages' - index missing >>>> > Ignoring feed 'xwrt' - index missing >>>> > Ignoring feed 'luci' - index missing >>>> > WARNING: No feed for package 'mpd' found, maybe it's already part of >>>> the >>>> > standard packages? >>>> > >>>> > >>>> > >>>> > Carlos >>>> > >>>> > >>>> > >>>> > On Sun, Sep 6, 2009 at 8:37 PM, Xiangfu Liu >>> > > wrote: >>>> > >>>> > >>>> > 1. in terminal, under openwrt folder run >>>> > >>>> > >>>> > >>>> > 2. run [make menuconfig] then select --> sound --> enable [mpc] >>>> [mpd] >>>> > 3. run [make menuconfig] --> Base System --> enable [libstdcpp] >>>> > >>>> > then you run make. you will get the [mpd] [mpc] in you rootfs. >>>> > you need change the [/etc/mpd.conf] to make the mpd work. >>>> > >>>> >>>> _______________________________________________ >>>> Qi Developer Mailing List >>>> Mail to list (members only): developer at lists.qi-hardware.com >>>> Subscribe or Unsubscribe: >>>> http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer >>>> >>> >>> >>> _______________________________________________ >>> Qi Developer Mailing List >>> Mail to list (members only): developer at lists.qi-hardware.com >>> Subscribe or Unsubscribe: >>> http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer >>> >> >> >> _______________________________________________ >> Qi Developer Mailing List >> Mail to list (members only): developer at lists.qi-hardware.com >> Subscribe or Unsubscribe: >> http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer >> > > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kzjeef at gmail.com Tue Sep 29 01:20:33 2009 From: kzjeef at gmail.com (ZhangJieJing) Date: Tue, 29 Sep 2009 13:20:33 +0800 Subject: configure mpd/mpc in openwrt. music player in Ben NanoNote In-Reply-To: <9f2feba00909281029l5290da66y423c5da9fbf1db40@mail.gmail.com> References: <4AA463E5.5090802@qi-hardware.com> <19ebea720909071630t1a680beexf5d62ec2084090ba@mail.gmail.com> <4AA5B590.5000000@qi-hardware.com> <9f2feba00909110240s4169fe78mfe38db486e30fc1d@mail.gmail.com> <9f2feba00909281029l5290da66y423c5da9fbf1db40@mail.gmail.com> Message-ID: Hi, Our OSS plugin of ALSA driver is working now, maybe you can try it? --- Best regards, Zhang Jiejing On Tue, Sep 29, 2009 at 1:29 AM, Ignacio Garc?a P?rez wrote: > (sorry for taking so long to reply... somehow this message got buried in the > inbox) > > 2009/9/11 ZhangJieJing >> >> 2009/9/11 Ignacio Garc?a P?rez >>> >>> I never got ALSA to work on the A320 (dingux). Instead I tried OSS and as >>> it worked I forgot about ALSA. The OSS >> >> what type OSS, from I know , ALSA have an emulated OSS plugin,? or a pure >> OSS driver? > > A pure OSS driver. ALSA is very advanced, but IMHO way too engineered for an > embedded device with such a limited memory. Last time I compiled ALSA for > the JZ4740 I ended up with a 1MB shared library (and that's the usespace > part only). What the hell have the put there?. > > The downside is that the OSS code in the Ingenic kernel is cleary > deprecated. It is very dirty and buggy. Had to fix several things to make it > usable. > > >>> >>> code, though, seems to be deprecated by Ingenic and is very very very >>> ugly and buggy. Had to make several fixes to get sample rates other than >>> S16_LE working. However, sticking to OSS because "it just works" is probably >>> only acceptable in the A320 case because it is intended to be used as a >>> gaming console and as such almost eveybody is using the SDL, which dingux >>> provides precompiled and configured for OSS. >>> >>> 2009/9/8 ZhangJieJing >>>> >>>> Hi, >>>> >>>> Sound card on my kernel tree is just can be found by alsa driver, But >>>> the driver have problem with DMA(jz's driver use too old DMA method) I 'm >>>> trying to fix it. >>>> >>>> The sound cann't play for now. >>>> --- >>>> Best regards, >>>> Zhang Jiejing >>>> >>>> >>>> On Tue, Sep 8, 2009 at 9:38 AM, Xiangfu Liu >>>> wrote: >>>>> >>>>> Carlos Camargo wrote: >>>>> > Hi >>>>> > >>>>> > We are trying to test the sound driver, with alsa, mplayer, but >>>>> > doesn't >>>>> > work :( ?The Qi kernel source support the JZ sound driver? If not, >>>>> > where >>>>> > can I foun information about this driver? >>>>> >>>>> the Qi kernel not support JZ sound driver not. Jieijing Zhang and larsc >>>>> work on that. >>>>> >>>>> you can find the Jieijing Zhange sound code: >>>>> >>>>> http://projects.qi-hardware.com/index.php/p/kzjeef-kernel/source/changes/master/ >>>>> >>>>> you can find JZ 2.6.27 sound driver at: >>>>> >>>>> http://downloads.qi-hardware.com/software/sources/linux-2.6.27.git.svn.tgz >>>>> >>>>> > >>>>> > >>>>> > ?$ scripts/feeds install mpd >>>>> > ?$ scripts/feeds install mpc >>>>> >>>>> run 'scripts/feeds update' before install mpd/mpc. >>>>> >>>>> > >>>>> > I try to run this command but I get the following error: >>>>> > >>>>> > Ignoring feed 'packages' - index missing >>>>> > Ignoring feed 'xwrt' - index missing >>>>> > Ignoring feed 'luci' - index missing >>>>> > WARNING: No feed for package 'mpd' found, maybe it's already part of >>>>> > the >>>>> > standard packages? >>>>> > >>>>> > >>>>> > >>>>> > Carlos >>>>> > >>>>> > >>>>> > >>>>> > On Sun, Sep 6, 2009 at 8:37 PM, Xiangfu Liu >>>> > > wrote: >>>>> > >>>>> > >>>>> > ? ? 1. in terminal, under openwrt folder run >>>>> > >>>>> > >>>>> > >>>>> > ? ? 2. run [make menuconfig] then select --> sound --> enable [mpc] >>>>> > [mpd] >>>>> > ? ? 3. run [make menuconfig] --> Base System --> enable [libstdcpp] >>>>> > >>>>> > ? ? then you run make. you will get the [mpd] [mpc] in you rootfs. >>>>> > ? ? you need change the [/etc/mpd.conf] to make the mpd work. >>>>> > >>>>> >>>>> _______________________________________________ >>>>> Qi Developer Mailing List >>>>> Mail to list (members only): developer at lists.qi-hardware.com >>>>> Subscribe or Unsubscribe: >>>>> http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer >>>> >>>> >>>> _______________________________________________ >>>> Qi Developer Mailing List >>>> Mail to list (members only): developer at lists.qi-hardware.com >>>> Subscribe or Unsubscribe: >>>> http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer >>> >>> >>> _______________________________________________ >>> Qi Developer Mailing List >>> Mail to list (members only): developer at lists.qi-hardware.com >>> Subscribe or Unsubscribe: >>> http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer >> >> >> _______________________________________________ >> Qi Developer Mailing List >> Mail to list (members only): developer at lists.qi-hardware.com >> Subscribe or Unsubscribe: >> http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > From mirko at qi-hardware.com Tue Sep 29 05:16:12 2009 From: mirko at qi-hardware.com (Mirko Lindner) Date: Tue, 29 Sep 2009 11:16:12 +0200 Subject: stuff we should port to the NanoNote In-Reply-To: <886128c30909262114j774b3f56lc032a93613c7c3f4@mail.gmail.com> References: <19ebea720909262049o49abc32cv4fd91aecc005f73b@mail.gmail.com> <886128c30909262114j774b3f56lc032a93613c7c3f4@mail.gmail.com> Message-ID: <11ac140a0909290216l5338bb93vc9776611c0c0a8e3@mail.gmail.com> Hey, On Sun, Sep 27, 2009 at 6:14 AM, Ron K. Jeffries wrote: > Re: apps for NanoNote > > Shouldn't NanoNote (the machine) also support Nano (the editor)? > Nothing wrong with vi, but ordinary citizens will find Nano the editor > easier to use, because one only needs to remember one or two magic keys. > Without knowing the exact details I am very certain that a simple editor such as joe or nano has been ported to OpenWrt already. So it should be only a matter of building the package and installing it. /mirko -------------- next part -------------- An HTML attachment was scrubbed... URL: From iggarpe at gmail.com Tue Sep 29 06:59:44 2009 From: iggarpe at gmail.com (=?ISO-8859-1?Q?Ignacio_Garc=EDa_P=E9rez?=) Date: Tue, 29 Sep 2009 12:59:44 +0200 Subject: configure mpd/mpc in openwrt. music player in Ben NanoNote In-Reply-To: References: <4AA463E5.5090802@qi-hardware.com> <19ebea720909071630t1a680beexf5d62ec2084090ba@mail.gmail.com> <4AA5B590.5000000@qi-hardware.com> <9f2feba00909110240s4169fe78mfe38db486e30fc1d@mail.gmail.com> <9f2feba00909281029l5290da66y423c5da9fbf1db40@mail.gmail.com> Message-ID: <9f2feba00909290359qf9ab425pba0cc2d6b9e0f5c2@mail.gmail.com> > > Our OSS plugin of ALSA driver is working now, > maybe you can try it? > I'll give it a try just to confirm its functionality, but for dingux I'll stick to OSS for the time being. As I said, the code is ugly as hell but seems to work fine and developers haven't complained. > > --- > Best regards, > Zhang Jiejing > > > > On Tue, Sep 29, 2009 at 1:29 AM, Ignacio Garc?a P?rez > wrote: > > (sorry for taking so long to reply... somehow this message got buried in > the > > inbox) > > > > 2009/9/11 ZhangJieJing > >> > >> 2009/9/11 Ignacio Garc?a P?rez > >>> > >>> I never got ALSA to work on the A320 (dingux). Instead I tried OSS and > as > >>> it worked I forgot about ALSA. The OSS > >> > >> what type OSS, from I know , ALSA have an emulated OSS plugin, or a > pure > >> OSS driver? > > > > A pure OSS driver. ALSA is very advanced, but IMHO way too engineered for > an > > embedded device with such a limited memory. Last time I compiled ALSA for > > the JZ4740 I ended up with a 1MB shared library (and that's the usespace > > part only). What the hell have the put there?. > > > > The downside is that the OSS code in the Ingenic kernel is cleary > > deprecated. It is very dirty and buggy. Had to fix several things to make > it > > usable. > > > > > >>> > >>> code, though, seems to be deprecated by Ingenic and is very very very > >>> ugly and buggy. Had to make several fixes to get sample rates other > than > >>> S16_LE working. However, sticking to OSS because "it just works" is > probably > >>> only acceptable in the A320 case because it is intended to be used as a > >>> gaming console and as such almost eveybody is using the SDL, which > dingux > >>> provides precompiled and configured for OSS. > >>> > >>> 2009/9/8 ZhangJieJing > >>>> > >>>> Hi, > >>>> > >>>> Sound card on my kernel tree is just can be found by alsa driver, But > >>>> the driver have problem with DMA(jz's driver use too old DMA method) I > 'm > >>>> trying to fix it. > >>>> > >>>> The sound cann't play for now. > >>>> --- > >>>> Best regards, > >>>> Zhang Jiejing > >>>> > >>>> > >>>> On Tue, Sep 8, 2009 at 9:38 AM, Xiangfu Liu > >>>> wrote: > >>>>> > >>>>> Carlos Camargo wrote: > >>>>> > Hi > >>>>> > > >>>>> > We are trying to test the sound driver, with alsa, mplayer, but > >>>>> > doesn't > >>>>> > work :( The Qi kernel source support the JZ sound driver? If not, > >>>>> > where > >>>>> > can I foun information about this driver? > >>>>> > >>>>> the Qi kernel not support JZ sound driver not. Jieijing Zhang and > larsc > >>>>> work on that. > >>>>> > >>>>> you can find the Jieijing Zhange sound code: > >>>>> > >>>>> > http://projects.qi-hardware.com/index.php/p/kzjeef-kernel/source/changes/master/ > >>>>> > >>>>> you can find JZ 2.6.27 sound driver at: > >>>>> > >>>>> > http://downloads.qi-hardware.com/software/sources/linux-2.6.27.git.svn.tgz > >>>>> > >>>>> > > >>>>> > > >>>>> > $ scripts/feeds install mpd > >>>>> > $ scripts/feeds install mpc > >>>>> > >>>>> run 'scripts/feeds update' before install mpd/mpc. > >>>>> > >>>>> > > >>>>> > I try to run this command but I get the following error: > >>>>> > > >>>>> > Ignoring feed 'packages' - index missing > >>>>> > Ignoring feed 'xwrt' - index missing > >>>>> > Ignoring feed 'luci' - index missing > >>>>> > WARNING: No feed for package 'mpd' found, maybe it's already part > of > >>>>> > the > >>>>> > standard packages? > >>>>> > > >>>>> > > >>>>> > > >>>>> > Carlos > >>>>> > > >>>>> > > >>>>> > > >>>>> > On Sun, Sep 6, 2009 at 8:37 PM, Xiangfu Liu < > xiangfu at qi-hardware.com > >>>>> > > wrote: > >>>>> > > >>>>> > > >>>>> > 1. in terminal, under openwrt folder run > >>>>> > > >>>>> > > >>>>> > > >>>>> > 2. run [make menuconfig] then select --> sound --> enable [mpc] > >>>>> > [mpd] > >>>>> > 3. run [make menuconfig] --> Base System --> enable [libstdcpp] > >>>>> > > >>>>> > then you run make. you will get the [mpd] [mpc] in you rootfs. > >>>>> > you need change the [/etc/mpd.conf] to make the mpd work. > >>>>> > > >>>>> > >>>>> _______________________________________________ > >>>>> Qi Developer Mailing List > >>>>> Mail to list (members only): developer at lists.qi-hardware.com > >>>>> Subscribe or Unsubscribe: > >>>>> http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > >>>> > >>>> > >>>> _______________________________________________ > >>>> Qi Developer Mailing List > >>>> Mail to list (members only): developer at lists.qi-hardware.com > >>>> Subscribe or Unsubscribe: > >>>> http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > >>> > >>> > >>> _______________________________________________ > >>> Qi Developer Mailing List > >>> Mail to list (members only): developer at lists.qi-hardware.com > >>> Subscribe or Unsubscribe: > >>> http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > >> > >> > >> _______________________________________________ > >> Qi Developer Mailing List > >> Mail to list (members only): developer at lists.qi-hardware.com > >> Subscribe or Unsubscribe: > >> http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > > > > > _______________________________________________ > > Qi Developer Mailing List > > Mail to list (members only): developer at lists.qi-hardware.com > > Subscribe or Unsubscribe: > > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at nanl.de Tue Sep 29 08:14:43 2009 From: lists at nanl.de (Mirko Vogt) Date: Tue, 29 Sep 2009 14:14:43 +0200 Subject: updates from the software part Message-ID: <1254226483.6540.555.camel@mia> Hey folks, some more updates from the software part :) I created a new repository called "OpenWrt packages" which is meant to contain OpenWrt-packages (ports of Software to OpenWrt) which are not (yet) ready to get upstream to the OpenWrt project. This repository is added to the openwrt-xburst-project as "feed" (you may want to take a look at the file (http://projects.qi-hardware.com/index.php/p/openwrt-xburst/source/tree/xburst/feeds.conf.default)), so that these packages will be included and show up in the main openwrt-xburst-project. After some more testing and bug fixing I'll commit, as mentioned in the previous mail, the ports of lynx, OpenZIM and it's dependencies to the new repository to get the Ben NanoNote working as an offline wikipedia reader. We're in direct contact with the OpenZIM-team, communicating a lot and they're willing to support and help us - to get the advantages and goals of both projects combined. Cheers, mirko -- This email address is used for mailinglist purposes only. Non-mailinglist emails will be dropped automatically. If you want to get in contact with me personally, please mail to: mirko.vogt nanl de From adam at qi-hardware.com Tue Sep 29 08:44:02 2009 From: adam at qi-hardware.com (Adam Wang) Date: Tue, 29 Sep 2009 20:44:02 +0800 Subject: What does this Error stand for? Message-ID: <4AC20112.7080402@qi-hardware.com> Hi, Is there anyone knows that this Error stand for? Can describe in more details like that the software it wants to do what tasks in hardware side and get this error? Thanks, Adam ========================================================================== Now checking whether all configure args valid: YES Current device information: CPU type is Ingenic XBurst Jz4740 Crystal work at 12MHz, the CCLK up to 252MHz and PMH_CLK up to 84MHz SDRAM Total size is 32 MB, work in 4 bank and 16 bit mode Nand page per block 128, Nand page size 4096, ECC offset in OOB 12, bad block offset in OOB 0, bad block page 127, use 1 plane mode Execute command: nprog 0 openwrt-xburst-u-boot.bin 0 0 -n Programing No.0 device, flen 469224, start page 0... CPU data: Boot4740 Erasing No.0 device No.0 flash (start_blk 0 blk_num 1)...... Finish! Return: 80 00 00 00 00 00 00 00 (position 1) Force erase, no bad block infomation! Size to send 469224, transfer_size 524288 Image type : without oob It will cause 1 times buffer transfer. Writing NAND page 0 len 471040... CPU data: Boot4740 Finish! (len 471040 start_page 0 page_num 115) Error - can't set the address on Ingenic device: -110 Error - can't set data length on Ingenic device: -110 Error - can't set Ingenic device nand ops: -110 Checking 471040 bytes... no check! End at Page: -193254056 Skip a old bad block !usbboot - Ingenic XBurst USB Boot Utility From rjeffries at gmail.com Tue Sep 29 11:14:09 2009 From: rjeffries at gmail.com (Ron K. Jeffries) Date: Tue, 29 Sep 2009 08:14:09 -0700 Subject: WikiTravel and OpenZim Message-ID: <886128c30909290814mf56fd32v368f4f35f2049bf2@mail.gmail.com> background info for NanoNote team:: Evan Promodoro, co-developer of WikiTravel, has given his blessing to the idea of putting WikiTravel on NanoNote. However, Evan is not familiar with OpenZim, and is very busy with http://identi.ca and http://status.net, so someone else will need to lead the effort to port WikiTravel to OpenZim and thence to NanoNote when the time is right. --- Ron K. Jeffries http://identi.ca/rkj From adam at qi-hardware.com Tue Sep 29 11:52:47 2009 From: adam at qi-hardware.com (Adam Wang) Date: Tue, 29 Sep 2009 23:52:47 +0800 Subject: qi_avt2 v1.0 board status In-Reply-To: <19ebea720909130648xf701545v2920050efd67a4f0@mail.gmail.com> References: <4AAA0C6A.5050409@qi-hardware.com> <4AACB2EB.7030601@qi-hardware.com> <19ebea720909130630u154dad1w6d206965830aa342@mail.gmail.com> <19ebea720909130648xf701545v2920050efd67a4f0@mail.gmail.com> Message-ID: <4AC22D4F.3070306@qi-hardware.com> Hi Carlos, Sorry for the late, you can check those pictures of actual bonding wire here[1]. It's an 0.7mil golden wire. I can illustrate a little bit in report to show how make it layout right. Local vendors here are having aluminum capability but can not meet our die's pitch between pads, because they have only 1.0 mil. Will not have good quality in aluminum process on our case. Fortunately here have 0.7 mil gold wire process but expensive. :-) And most early vendors here had moved into China. [1] http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/pcb/cob/bonding_wire/ Adam Carlos Camargo wrote: > Hi Adam > > Can you please upload a processor close-up photo? > > Best Regards > > > Carlos > > > On Sun, Sep 13, 2009 at 8:30 AM, Carlos Camargo > wrote: > > hi adam, good job. i want one new board :). > when finish all tests, please check the kicad brd file. we want that > the next board will be designed in kicad. > We've already uploaded pcb and footprints files, all components > placed, and remove a lot of test-points > > Can you please check if the placement and size are right ? > > Best Regards > > > Carlos > > > On Sun, Sep 13, 2009 at 3:52 AM, Adam Wang > wrote: > > Hi All, > > The picture of avt2_v1.0 board with die is here[1]. > And it just works and shown up[2]. > I'll keep do more basic IO tests. > Adam > > [1] > http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/smt/pictures/top_jz4720.jpg > [2] > http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/report/photos/avt2_v1.0_works.JPG > > > > Adam Wang wrote: > > Hi All, > > We're now on the process to produce small run of avt2 > board, here is the top side of avt2 without jz4720 > temporarily; > http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/smt/pictures/top.jpg > > Will keep you posted later. > Adam > > > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > > > > -- > Carlos Iv?n Camargo Bare?o > Profesor Asistente > Departamento de Ingenier?a El?ctrica y Electr?nica > Universidad Nacional de Colombia > cicamargoba at unal.edu.co > > > > > -- > Carlos Iv?n Camargo Bare?o > Profesor Asistente > Departamento de Ingenier?a El?ctrica y Electr?nica > Universidad Nacional de Colombia > cicamargoba at unal.edu.co > ------------------------------------------------------------------------ > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer -------------- next part -------------- An HTML attachment was scrubbed... URL: From mirko at qi-hardware.com Tue Sep 29 12:15:44 2009 From: mirko at qi-hardware.com (Mirko Lindner) Date: Tue, 29 Sep 2009 18:15:44 +0200 Subject: WikiTravel and OpenZim In-Reply-To: <886128c30909290814mf56fd32v368f4f35f2049bf2@mail.gmail.com> References: <886128c30909290814mf56fd32v368f4f35f2049bf2@mail.gmail.com> Message-ID: <11ac140a0909290915m19df0734h2d0d85641c715eda@mail.gmail.com> Hey Ron, On Tue, Sep 29, 2009 at 5:14 PM, Ron K. Jeffries wrote: > background info for NanoNote team:: > > Evan Promodoro, co-developer of WikiTravel, has given his > blessing to the idea of putting WikiTravel on NanoNote. > Iirc he pointed out, that the content is free content anyhow :) However, Evan is not familiar with OpenZim, and is very busy > with http://identi.ca and http://status.net, so someone else > will need to lead the effort to port WikiTravel to OpenZim > and thence to NanoNote when the time is right. > I hope we will get to this eventually. As it looks right now a wiki that can be used/parsed by openzim needs to follow a certain syntax. A project creating an offline version of wikitravel would need a dump of the whole database in order to generate a zim file. Once that is completed so is the port :) /mirko -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjeffries at gmail.com Tue Sep 29 12:42:57 2009 From: rjeffries at gmail.com (Ron K. Jeffries) Date: Tue, 29 Sep 2009 09:42:57 -0700 Subject: WikiTravel and OpenZim In-Reply-To: <11ac140a0909290915m19df0734h2d0d85641c715eda@mail.gmail.com> References: <886128c30909290814mf56fd32v368f4f35f2049bf2@mail.gmail.com> <11ac140a0909290915m19df0734h2d0d85641c715eda@mail.gmail.com> Message-ID: <886128c30909290942l2a072ffoaaa2cfad1be1f6a6@mail.gmail.com> Just learned that Brion Vibber CTO at MedaWiki is joining Evan Promodoro's Status.net team: http://status.net/2009/09/28/brion-vibber-joins-statusnet/ While that is a separate effort from WikiTravel, one might hope it will not be all that hard to get an OpenZim dump for NanoNote when qi-hardware team is ready. In some ways, WikiTravel might be a more compelling NanoNote app than Wipipedia. --- Ron K. Jeffries On Tue, Sep 29, 2009 at 09:15, Mirko Lindner wrote: > Hey Ron, > > On Tue, Sep 29, 2009 at 5:14 PM, Ron K. Jeffries > wrote: >> >> background info for NanoNote team:: >> >> Evan Promodoro, co-developer of WikiTravel, has given his >> blessing to the idea of putting WikiTravel on NanoNote. > > Iirc he pointed out, that the content is free content anyhow :) > >> However, Evan is not familiar with OpenZim, and is very busy >> with http://identi.ca and http://status.net, so someone else >> will need to lead the effort to port WikiTravel to OpenZim >> and thence to NanoNote when the time is right. > > I hope we will get to this eventually. As it looks right now a wiki that can > be used/parsed by openzim needs to follow a certain syntax. A project > creating an offline version of wikitravel would need a dump of the whole > database in order to generate a zim file. Once that is completed so is the > port :) > > /mirko > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > From mirko at qi-hardware.com Tue Sep 29 14:01:30 2009 From: mirko at qi-hardware.com (Mirko Lindner) Date: Tue, 29 Sep 2009 20:01:30 +0200 Subject: WikiTravel and OpenZim In-Reply-To: <886128c30909290942l2a072ffoaaa2cfad1be1f6a6@mail.gmail.com> References: <886128c30909290814mf56fd32v368f4f35f2049bf2@mail.gmail.com> <11ac140a0909290915m19df0734h2d0d85641c715eda@mail.gmail.com> <886128c30909290942l2a072ffoaaa2cfad1be1f6a6@mail.gmail.com> Message-ID: <11ac140a0909291101u35501ac2w820b40a5d3cb229d@mail.gmail.com> Hey, While that is a separate effort from WikiTravel, one might > hope it will not be all that hard to get an OpenZim dump > for NanoNote when qi-hardware team is ready. > This is not really a time issue for the qi developers, they are focusing on the kernel and working on getting that stable. It would be great if you could get a zim file for wikitravel. Best would be not bigger than 1.8GB and without pictures. > > In some ways, WikiTravel might be a more compelling > NanoNote app than Wipipedia. > Maybe you would want to lead such an effort? /mirko -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at nanl.de Tue Sep 29 14:50:06 2009 From: lists at nanl.de (Mirko Vogt) Date: Tue, 29 Sep 2009 20:50:06 +0200 Subject: stuff we should port to the NanoNote In-Reply-To: <11ac140a0909290216l5338bb93vc9776611c0c0a8e3@mail.gmail.com> References: <19ebea720909262049o49abc32cv4fd91aecc005f73b@mail.gmail.com> <886128c30909262114j774b3f56lc032a93613c7c3f4@mail.gmail.com> <11ac140a0909290216l5338bb93vc9776611c0c0a8e3@mail.gmail.com> Message-ID: <1254250206.6540.1255.camel@mia> On Tue, 2009-09-29 at 11:16 +0200, Mirko Lindner wrote: > Hey, Hey > > On Sun, Sep 27, 2009 at 6:14 AM, Ron K. Jeffries > wrote: > Re: apps for NanoNote > > Shouldn't NanoNote (the machine) also support Nano (the > editor)? > Nothing wrong with vi, but ordinary citizens will find Nano > the editor > easier to use, because one only needs to remember one or two > magic keys. > > Without knowing the exact details I am very certain that a simple > editor such as joe or nano has been ported to OpenWrt already. So it > should be only a matter of building the package and installing it. Indeed - nano was committed in 2005, joe in 2007 :) > > /mirko /mirko (the other one) > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer -- This email address is used for mailinglist purposes only. Non-mailinglist emails will be dropped automatically. If you want to get in contact with me personally, please mail to: mirko.vogt nanl de From lists at nanl.de Tue Sep 29 15:05:28 2009 From: lists at nanl.de (Mirko Vogt) Date: Tue, 29 Sep 2009 21:05:28 +0200 Subject: stuff we should port to the NanoNote In-Reply-To: <19ebea720909262049o49abc32cv4fd91aecc005f73b@mail.gmail.com> References: <19ebea720909262049o49abc32cv4fd91aecc005f73b@mail.gmail.com> Message-ID: <1254251128.6540.1304.camel@mia> On Sat, 2009-09-26 at 22:49 -0500, Carlos Camargo wrote: > Hi Hey > > I'm thinking in some stuff we should port to Nano: Most of them are already. The main repository for official non-base packages is located here: https://dev.openwrt.org/browser/packages > getty: We can use getty to create a serial console when we use > g_serial getty is already part of busybox which is used as userspace environment by OpenWrt. > octave: GNU Octave is a high-level language, primarily intended for > numerical computations.[1] This isn't indeed, bust at least most of it's dependencies are already ported, so it should be quite easy. > mp3 player: curses based mp3 player like [2], [3] There are quite some, but, as Wolfgang already said, mp3/mp4 might not be the format of choice. However there are some nice ogg/vorbis players within the OpenWrt repo as well. > > These tools are text based, so, I think is not difficult add them to > openwrt, and we can provide some extra-functionality to Nano. > > [1] http://www.gnu.org/software/octave/ > [2] http://www.cse.unsw.edu.au/~dons/hmp3.html Uh, written in haskell - recalls my 1st semester of computer science ;) > [3] http://www-users.cs.umn.edu/~wburdick/gamp/#shots Might be an option; e.g. mpd and various frontends, madplay, etc. are already ported and might be capable of doing what you have in mind. > > > > Carlos mirko > > -- > Carlos Iv?n Camargo Bare?o > Profesor Asistente > Departamento de Ingenier?a El?ctrica y Electr?nica > Universidad Nacional de Colombia > cicamargoba at unal.edu.co > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer -- This email address is used for mailinglist purposes only. Non-mailinglist emails will be dropped automatically. If you want to get in contact with me personally, please mail to: mirko.vogt nanl de From wolfgang at qi-hardware.com Tue Sep 29 20:37:15 2009 From: wolfgang at qi-hardware.com (Wolfgang Spraul) Date: Tue, 29 Sep 2009 20:37:15 -0400 Subject: qi_avt2 v1.0 board status In-Reply-To: <4AC22D4F.3070306@qi-hardware.com> References: <4AAA0C6A.5050409@qi-hardware.com> <4AACB2EB.7030601@qi-hardware.com> <19ebea720909130630u154dad1w6d206965830aa342@mail.gmail.com> <19ebea720909130648xf701545v2920050efd67a4f0@mail.gmail.com> <4AC22D4F.3070306@qi-hardware.com> Message-ID: <20090930003715.GA12667@debian> Adam beautiful pictures! Who took them? I think at some point we will want to move away from COB packaging, but right now it's good and at least we all learn a lot :-) Thanks a lot for uploading the pictures, very nice I think... Wolfgang On Tue, Sep 29, 2009 at 11:52:47PM +0800, Adam Wang wrote: > Hi Carlos, > > Sorry for the late, you can check those pictures of actual bonding wire > here[1]. It's an 0.7mil golden wire. I can illustrate a little bit in > report to show how make > it layout right. Local vendors here are having aluminum capability but > can not meet our die's pitch between pads, because they have only 1.0 > mil. Will not have > good quality in aluminum process on our case. Fortunately here have 0.7 > mil gold wire process but expensive. :-) And most early vendors here > had moved into China. > > [1] > http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/pcb/cob/bonding_wire/ > > Adam > > Carlos Camargo wrote: >> Hi Adam >> >> Can you please upload a processor close-up photo? >> >> Best Regards >> >> >> Carlos >> >> >> On Sun, Sep 13, 2009 at 8:30 AM, Carlos Camargo > > wrote: >> >> hi adam, good job. i want one new board :). >> when finish all tests, please check the kicad brd file. we want that >> the next board will be designed in kicad. >> We've already uploaded pcb and footprints files, all components >> placed, and remove a lot of test-points >> >> Can you please check if the placement and size are right ? >> >> Best Regards >> >> >> Carlos >> >> >> On Sun, Sep 13, 2009 at 3:52 AM, Adam Wang > > wrote: >> >> Hi All, >> >> The picture of avt2_v1.0 board with die is here[1]. >> And it just works and shown up[2]. >> I'll keep do more basic IO tests. >> Adam >> >> [1] >> http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/smt/pictures/top_jz4720.jpg >> [2] >> http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/report/photos/avt2_v1.0_works.JPG >> >> >> >> Adam Wang wrote: >> >> Hi All, >> >> We're now on the process to produce small run of avt2 >> board, here is the top side of avt2 without jz4720 >> temporarily; >> http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/smt/pictures/top.jpg >> >> Will keep you posted later. >> Adam >> >> >> >> _______________________________________________ >> Qi Developer Mailing List >> Mail to list (members only): developer at lists.qi-hardware.com >> >> Subscribe or Unsubscribe: >> http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer >> >> >> >> >> -- Carlos Iv?n Camargo Bare?o >> Profesor Asistente >> Departamento de Ingenier?a El?ctrica y Electr?nica >> Universidad Nacional de Colombia >> cicamargoba at unal.edu.co >> >> >> >> >> -- >> Carlos Iv?n Camargo Bare?o >> Profesor Asistente >> Departamento de Ingenier?a El?ctrica y Electr?nica >> Universidad Nacional de Colombia >> cicamargoba at unal.edu.co >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Qi Developer Mailing List >> Mail to list (members only): developer at lists.qi-hardware.com >> Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer From adam at qi-hardware.com Tue Sep 29 22:09:50 2009 From: adam at qi-hardware.com (Adam Wang) Date: Wed, 30 Sep 2009 10:09:50 +0800 Subject: qi_avt2 v1.0 board status In-Reply-To: <20090930003715.GA12667@debian> References: <4AAA0C6A.5050409@qi-hardware.com> <4AACB2EB.7030601@qi-hardware.com> <19ebea720909130630u154dad1w6d206965830aa342@mail.gmail.com> <19ebea720909130648xf701545v2920050efd67a4f0@mail.gmail.com> <4AC22D4F.3070306@qi-hardware.com> <20090930003715.GA12667@debian> Message-ID: <4AC2BDEE.8070908@qi-hardware.com> Hi Wolfgang, > Adam > beautiful pictures! Who took them? > We took them when we were at vendor there. :-) > I think at some point we will want to move away from COB packaging, > but right now it's good and at least we all learn a lot :-) > Yeah, we should think in another way to approach. Adam From andres.calderon at emqbit.com Tue Sep 29 23:38:44 2009 From: andres.calderon at emqbit.com (=?ISO-8859-1?Q?Andr=E9s_Calder=F3n?=) Date: Tue, 29 Sep 2009 22:38:44 -0500 Subject: qi_avt2 v1.0 board status In-Reply-To: <4AC22D4F.3070306@qi-hardware.com> References: <4AAA0C6A.5050409@qi-hardware.com> <4AACB2EB.7030601@qi-hardware.com> <19ebea720909130630u154dad1w6d206965830aa342@mail.gmail.com> <19ebea720909130648xf701545v2920050efd67a4f0@mail.gmail.com> <4AC22D4F.3070306@qi-hardware.com> Message-ID: <6e36f2f00909292038g1343d3cna2aa6a7d2368439e@mail.gmail.com> On Tue, Sep 29, 2009 at 10:52 AM, Adam Wang wrote: > Hi Carlos, > > Sorry for the late, you can check those pictures of actual bonding wire > here[1]. It's an 0.7mil golden wire. I can illustrate a little bit in report > to show how make > it layout right. Local vendors here are having aluminum capability but can > not meet our die's pitch between pads, because they have only 1.0 mil. Will > not have > good quality in aluminum process on our case. Fortunately here have 0.7 mil > gold wire process but expensive. :-)? And most early vendors here had moved > into China. > > [1] > http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/pcb/cob/bonding_wire/ > Amazing pictures (the bonding_wire7.jpg is my new desktop background :) ) The price of the jz4720 plus the bonding wire price is competitive against the jz4740 price plus the BGA soldering process? BR, Andr?s Calder?n Cel: +57 (300) 275 3666 Email: andres.calderon at emqbit.com Web: www.emqbit.com > Adam > > Carlos Camargo wrote: > > Hi Adam > > Can you please upload a processor close-up photo? > > Best Regards > > > Carlos > > > On Sun, Sep 13, 2009 at 8:30 AM, Carlos Camargo > wrote: >> >> hi adam, good job. i want one new board :). >> when finish all tests, please check the kicad brd file. we want that >> the next board will be designed in kicad. >> We've already uploaded pcb and footprints files, all components placed, >> and remove a lot of test-points >> >> Can you please check if the placement and size are right ? >> >> Best Regards >> >> >> Carlos >> >> On Sun, Sep 13, 2009 at 3:52 AM, Adam Wang wrote: >>> >>> Hi All, >>> >>> The picture of avt2_v1.0 board with die is here[1]. >>> And it just works and shown up[2]. >>> I'll keep do more basic IO tests. >>> Adam >>> >>> [1] >>> http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/smt/pictures/top_jz4720.jpg >>> [2] >>> http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/report/photos/avt2_v1.0_works.JPG >>> >>> Adam Wang wrote: >>>> >>>> Hi All, >>>> >>>> We're now on the process to produce small run of avt2 board, here is the >>>> top side of avt2 without jz4720 temporarily; >>>> >>>> http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/smt/pictures/top.jpg >>>> Will keep you posted later. >>>> Adam >>> >>> >>> _______________________________________________ >>> Qi Developer Mailing List >>> Mail to list (members only): developer at lists.qi-hardware.com >>> Subscribe or Unsubscribe: >>> http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer >> >> >> >> -- >> Carlos Iv?n Camargo Bare?o >> Profesor Asistente >> Departamento de Ingenier?a El?ctrica y Electr?nica >> Universidad Nacional de Colombia >> cicamargoba at unal.edu.co > > > > -- > Carlos Iv?n Camargo Bare?o > Profesor Asistente > Departamento de Ingenier?a El?ctrica y Electr?nica > Universidad Nacional de Colombia > cicamargoba at unal.edu.co > > ________________________________ > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > From mirko at qi-hardware.com Wed Sep 30 04:33:25 2009 From: mirko at qi-hardware.com (Mirko Lindner) Date: Wed, 30 Sep 2009 10:33:25 +0200 Subject: Software Wishlist Message-ID: <11ac140a0909300133k2cce2430t62efec4777c97d50@mail.gmail.com> Hey all, As there have been many discussion surrounding software that could and should be ported to the Ben, I created a wikipage[1]. I filled the table with a few sample apps to get us started :) Please feel free to edit, comment on the discussion page etc. /mirko [1] http://wiki.qi-hardware.com/index.php/Software_Wishlist -------------- next part -------------- An HTML attachment was scrubbed... URL: From yi at qi-hardware.com Wed Sep 30 05:40:59 2009 From: yi at qi-hardware.com (Yi Zhang) Date: Wed, 30 Sep 2009 17:40:59 +0800 Subject: samples arrived Message-ID: <1A432CE7-6684-4E9D-8FF6-07EE34F50D9A@qi-hardware.com> Hi, We got the second batch of Ben NanoNote samples [1][2][3][4]! Yi [1] http://downloads.qi-hardware.com/hardware/Photos/ 2009_09_30-19_samples.jpg [2] http://downloads.qi-hardware.com/hardware/Photos/ 2009_09_30_front.jpg [3] http://downloads.qi-hardware.com/hardware/Photos/ 2009_09_30_inside.jpg [4] http://downloads.qi-hardware.com/hardware/Photos/ 2009_09_30_keyboard.jpg From wolfgang at qi-hardware.com Wed Sep 30 06:05:59 2009 From: wolfgang at qi-hardware.com (Wolfgang Spraul) Date: Wed, 30 Sep 2009 06:05:59 -0400 Subject: qi_avt2 v1.0 board status In-Reply-To: <6e36f2f00909292038g1343d3cna2aa6a7d2368439e@mail.gmail.com> References: <4AAA0C6A.5050409@qi-hardware.com> <4AACB2EB.7030601@qi-hardware.com> <19ebea720909130630u154dad1w6d206965830aa342@mail.gmail.com> <19ebea720909130648xf701545v2920050efd67a4f0@mail.gmail.com> <4AC22D4F.3070306@qi-hardware.com> <6e36f2f00909292038g1343d3cna2aa6a7d2368439e@mail.gmail.com> Message-ID: <20090930100559.GA4387@debian> Andres, > The price of the jz4720 plus the bonding wire price is competitive > against the jz4740 price plus the BGA soldering process? Well that's a very long story, as always with prices :-) COB is getting more popular in China (and that means in most consumer electronics), because it is cheaper. At least that's what the manufacturers are saying but I'm sure companies that are producing millions of devices each month know their numbers. For the 20 boards we produced, we paid about 30 USD / chip for the COB :-) Not exactly cheaper... See a more detailed cost breakdown for the 20 boards at http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/report/expense/avt2_v1.0_expense.ods For 500 boards the price would go down to ca. 15 USD / chip for the COB alone. Now, one problem we had was that Adam could not find COB places in northern Taiwan that could do .8mil aluminum wires (see Adam's mail that you just responded to). So in order to just 'get the boards done', he chose .7mil gold wires. Going forward we need to improve all this. Maybe for another few small runs we continue to do COB, especially since Adam has it all figured out now. But then we will probably look into QFP/QFN versions, or BGA. The problem with switching to BGA on the current NanoNote board was that Adam said because the other side of the PCB was all covered by keys, we would need to go from a 4-layer to a 6-layer PCB when using BGA. Wolfgang On Tue, Sep 29, 2009 at 10:38:44PM -0500, Andr?s Calder?n wrote: > On Tue, Sep 29, 2009 at 10:52 AM, Adam Wang wrote: > > Hi Carlos, > > > > Sorry for the late, you can check those pictures of actual bonding wire > > here[1]. It's an 0.7mil golden wire. I can illustrate a little bit in report > > to show how make > > it layout right. Local vendors here are having aluminum capability but can > > not meet our die's pitch between pads, because they have only 1.0 mil. Will > > not have > > good quality in aluminum process on our case. Fortunately here have 0.7 mil > > gold wire process but expensive. :-)? And most early vendors here had moved > > into China. > > > > [1] > > http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/pcb/cob/bonding_wire/ > > > > Amazing pictures (the bonding_wire7.jpg is my new desktop background :) ) > > The price of the jz4720 plus the bonding wire price is competitive > against the jz4740 price plus the BGA soldering process? > > BR, > > Andr?s Calder?n > Cel: +57 (300) 275 3666 > Email: andres.calderon at emqbit.com > Web: www.emqbit.com > > > > Adam > > > > Carlos Camargo wrote: > > > > Hi Adam > > > > Can you please upload a processor close-up photo? > > > > Best Regards > > > > > > Carlos > > > > > > On Sun, Sep 13, 2009 at 8:30 AM, Carlos Camargo > > wrote: > >> > >> hi adam, good job. i want one new board :). > >> when finish all tests, please check the kicad brd file. we want that > >> the next board will be designed in kicad. > >> We've already uploaded pcb and footprints files, all components placed, > >> and remove a lot of test-points > >> > >> Can you please check if the placement and size are right ? > >> > >> Best Regards > >> > >> > >> Carlos > >> > >> On Sun, Sep 13, 2009 at 3:52 AM, Adam Wang wrote: > >>> > >>> Hi All, > >>> > >>> The picture of avt2_v1.0 board with die is here[1]. > >>> And it just works and shown up[2]. > >>> I'll keep do more basic IO tests. > >>> Adam > >>> > >>> [1] > >>> http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/smt/pictures/top_jz4720.jpg > >>> [2] > >>> http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/report/photos/avt2_v1.0_works.JPG > >>> > >>> Adam Wang wrote: > >>>> > >>>> Hi All, > >>>> > >>>> We're now on the process to produce small run of avt2 board, here is the > >>>> top side of avt2 without jz4720 temporarily; > >>>> > >>>> http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/smt/pictures/top.jpg > >>>> Will keep you posted later. > >>>> Adam > >>> > >>> > >>> _______________________________________________ > >>> Qi Developer Mailing List > >>> Mail to list (members only): developer at lists.qi-hardware.com > >>> Subscribe or Unsubscribe: > >>> http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > >> > >> > >> > >> -- > >> Carlos Iv?n Camargo Bare?o > >> Profesor Asistente > >> Departamento de Ingenier?a El?ctrica y Electr?nica > >> Universidad Nacional de Colombia > >> cicamargoba at unal.edu.co > > > > > > > > -- > > Carlos Iv?n Camargo Bare?o > > Profesor Asistente > > Departamento de Ingenier?a El?ctrica y Electr?nica > > Universidad Nacional de Colombia > > cicamargoba at unal.edu.co > > > > ________________________________ > > _______________________________________________ > > Qi Developer Mailing List > > Mail to list (members only): developer at lists.qi-hardware.com > > Subscribe or Unsubscribe: > > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > > > _______________________________________________ > > Qi Developer Mailing List > > Mail to list (members only): developer at lists.qi-hardware.com > > Subscribe or Unsubscribe: > > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer From yi at qi-hardware.com Wed Sep 30 08:44:46 2009 From: yi at qi-hardware.com (Yi Zhang) Date: Wed, 30 Sep 2009 20:44:46 +0800 Subject: CE and FCC certification Message-ID: <77051FCA-EDAE-4D49-8985-29E7F07A1C1C@qi-hardware.com> Hi All, We have gotten our final FCC and CE certificate for Ben NanoNote [1] [2]. In the end, we have resolved both radiation and ESD problems. You can find fixes in Modification section of the test reports [3] [4]. All of our new Ben NanoNote samples have already included these fixes. Also we have received battery CE certificate [5][6]. Next we will send 2 new samples to the certification lab for a re- test, then Ben NanoNote is ready for US and European markets in terms of certification. Thanks, Yi [1] http://downloads.qi-hardware.com/hardware/certification/ 2009_09_30_final/Certificate_CE_Ben_NanoNote.pdf [2] http://downloads.qi-hardware.com/hardware/certification/ 2009_09_30_final/Certificate_FCC_Ben_NanoNote.pdf [3] http://downloads.qi-hardware.com/hardware/certification/ 2009_09_30_final/Test_Report_CE_Ben_NanoNote.pdf [4] http://downloads.qi-hardware.com/hardware/certification/ 2009_09_30_final/Test_Report_FCC_Ben_NanoNote.pdf [5] http://downloads.qi-hardware.com/hardware/certification/ 2009_09_30_final/Certificate_CE_Battery.pdf [6] http://downloads.qi-hardware.com/hardware/certification/ 2009_09_30_final/Test_Report_CE_Battery.pdf From wolfgang at qi-hardware.com Wed Sep 30 09:20:24 2009 From: wolfgang at qi-hardware.com (Wolfgang Spraul) Date: Wed, 30 Sep 2009 09:20:24 -0400 Subject: [Company] Weekly Operations Update 38/2009 Message-ID: <20090930132024.GA5353@debian> Hi, ---1 daily Linux kernel updates from Ingenic Inc. this week I want to point people again to the daily updated Ingenic Linux kernel sources that are on our servers since last week. It seems to work, when I do 'svn update' I see new fixes coming down both for the 2.6.24.3 and 2.6.27 trees. I hope over time we get more people to unite behind a 2.6.31/2.6.32 kernel, then ask Ingenic to up-level to our 'cleaned up' kernel. All projects: http://projects.qi-hardware.com/ Ingenic usbboot: svn co http://projects.qi-hardware.com/svn/ingenic-tools-usb-boot/trunk Ingenic U-Boot 1.1.6: svn co http://projects.qi-hardware.com/svn/ingenic-linux-01boot-u-boot-1-1-6/trunk Linux 2.6.24.3: svn co http://projects.qi-hardware.com/svn/ingenic-linux-02os-linux-2-6-24-3/trunk Linux 2.6.27: svn co http://projects.qi-hardware.com/svn/ingenic-linux-02os-linux-2-6-27/trunk ---2 bringing more software onto the NanoNotes Mirko Vogt created a project that will serve as our Qi 'local' repository to port more software to the NanoNote by adding it to OpenWrt, before they go upstream. http://projects.qi-hardware.com/p/openwrt-packages/ Along the same lines, we started a wiki page at http://wiki.qi-hardware.com/index.php/Software_Wishlist where anybody can add software they would like to see ported to the NanoNote. Looking at the list right now, I need to go add mutt, w3m and GNU Octave :-) ---3 CE & FCC certification As Yi just pointed out, we got the final CE & FCC certification for the Ben NanoNote. That's about it for this week, - a Ben flash mob was seen in Shanghai today! - http://downloads.qi-hardware.com/hardware/Photos/2009_09_30-19_samples.jpg cu next week, Wolfgang From wijnen at debian.org Wed Sep 30 15:37:43 2009 From: wijnen at debian.org (Bas Wijnen) Date: Wed, 30 Sep 2009 21:37:43 +0200 Subject: What does this Error stand for? In-Reply-To: <4AC20112.7080402@qi-hardware.com> References: <4AC20112.7080402@qi-hardware.com> Message-ID: <20090930193743.GB19184@a82-93-13-222.adsl.xs4all.nl> On Tue, Sep 29, 2009 at 08:44:02PM +0800, Adam Wang wrote: > Is there anyone knows that this Error stand for? ... > Error - can't set the address on Ingenic device: -110 > Error - can't set data length on Ingenic device: -110 > Error - can't set Ingenic device nand ops: -110 Error 110 means "Operation timed out". I usually see it for usb devices when there is something wrong with the firmware (that I wrote), so the device no longer responds to the host. It often means the device hangs or crashed. Thanks, Bas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From xiangfu at qi-hardware.com Wed Sep 30 18:33:46 2009 From: xiangfu at qi-hardware.com (XiangFu Liu) Date: Thu, 1 Oct 2009 06:33:46 +0800 Subject: What does this Error stand for? In-Reply-To: <4AC20112.7080402@qi-hardware.com> References: <4AC20112.7080402@qi-hardware.com> Message-ID: <2b92b9a80909301533m3a97a7ccw176cf103cf76ffb9@mail.gmail.com> Hi Adam write down all command you have run. try "sudo usbboot -c "boot;nquery" On Tue, Sep 29, 2009 at 8:44 PM, Adam Wang wrote: > Hi, > > Is there anyone knows that this Error stand for? > > Can describe in more details like that the software it wants to do what > tasks in hardware side and get this error? > Thanks, > Adam > > ========================================================================== > > Now checking whether all configure args valid: YES > Current device information: > CPU type is Ingenic XBurst Jz4740 > Crystal work at 12MHz, the CCLK up to 252MHz and PMH_CLK up to 84MHz > SDRAM Total size is 32 MB, work in 4 bank and 16 bit mode > Nand page per block 128, Nand page size 4096, ECC offset in OOB 12, bad > block offset in OOB 0, bad block page 127, use 1 plane mode > Execute command: nprog 0 openwrt-xburst-u-boot.bin 0 0 -n > Programing No.0 device, flen 469224, start page 0... > CPU data: Boot4740 > Erasing No.0 device No.0 flash (start_blk 0 blk_num 1)...... > Finish! Return: 80 00 00 00 00 00 00 00 (position 1) > Force erase, no bad block infomation! > Size to send 469224, transfer_size 524288 > Image type : without oob > It will cause 1 times buffer transfer. > Writing NAND page 0 len 471040... > CPU data: Boot4740 > Finish! (len 471040 start_page 0 page_num 115) > Error - can't set the address on Ingenic device: -110 > Error - can't set data length on Ingenic device: -110 > Error - can't set Ingenic device nand ops: -110 > Checking 471040 bytes... no check! End at Page: -193254056 > Skip a old bad block !usbboot - Ingenic XBurst USB Boot Utility > > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cicamargoba at gmail.com Wed Sep 30 18:59:03 2009 From: cicamargoba at gmail.com (Carlos Camargo) Date: Wed, 30 Sep 2009 17:59:03 -0500 Subject: qi_avt2 v1.0 board status In-Reply-To: <20090930100559.GA4387@debian> References: <4AAA0C6A.5050409@qi-hardware.com> <4AACB2EB.7030601@qi-hardware.com> <19ebea720909130630u154dad1w6d206965830aa342@mail.gmail.com> <19ebea720909130648xf701545v2920050efd67a4f0@mail.gmail.com> <4AC22D4F.3070306@qi-hardware.com> <6e36f2f00909292038g1343d3cna2aa6a7d2368439e@mail.gmail.com> <20090930100559.GA4387@debian> Message-ID: <19ebea720909301559w7f174f2akadac0e138c212d54@mail.gmail.com> Hello Very beautiful pictures Adam!!! I have two boards with 64MB and works fine, I have a little problem with the LCD connector, I Think that this connector change its shape in the soldering process, so I replace this connector in both boards by another one (thanks Adam) and I can use both LCDs. I'm starting to test the sound and USB host port. I'm attaching some Nano pictures [1] New Nano show openwrt Logo [2] Using a custom FTDI USB-serial (I think that we can provide this board with a Nano developer version) [3] With usb host connector attached [1] http://downloads.qi-hardware.com/hardware/hacking/Nano_works.jpg [2] http://downloads.qi-hardware.com/hardware/hacking/usb_serial.jpg [3] http://downloads.qi-hardware.com/hardware/hacking/usb_host.jpg Best Regards Carlos On Wed, Sep 30, 2009 at 5:05 AM, Wolfgang Spraul wrote: > Andres, > > > The price of the jz4720 plus the bonding wire price is competitive > > against the jz4740 price plus the BGA soldering process? > > Well that's a very long story, as always with prices :-) > COB is getting more popular in China (and that means in most consumer > electronics), because it is cheaper. At least that's what the manufacturers > are saying but I'm sure companies that are producing millions of devices > each > month know their numbers. > > For the 20 boards we produced, we paid about 30 USD / chip for the COB :-) > Not exactly cheaper... > See a more detailed cost breakdown for the 20 boards at > > http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/report/expense/avt2_v1.0_expense.ods > For 500 boards the price would go down to ca. 15 USD / chip for the COB > alone. > > Now, one problem we had was that Adam could not find COB places in northern > Taiwan that could do .8mil aluminum wires (see Adam's mail that you just > responded to). So in order to just 'get the boards done', he chose .7mil > gold wires. > > Going forward we need to improve all this. > Maybe for another few small runs we continue to do COB, especially since > Adam has it all figured out now. But then we will probably look into > QFP/QFN > versions, or BGA. The problem with switching to BGA on the current NanoNote > board was that Adam said because the other side of the PCB was all covered > by keys, we would need to go from a 4-layer to a 6-layer PCB when using > BGA. > > Wolfgang > > On Tue, Sep 29, 2009 at 10:38:44PM -0500, Andr?s Calder?n wrote: > > On Tue, Sep 29, 2009 at 10:52 AM, Adam Wang > wrote: > > > Hi Carlos, > > > > > > Sorry for the late, you can check those pictures of actual bonding wire > > > here[1]. It's an 0.7mil golden wire. I can illustrate a little bit in > report > > > to show how make > > > it layout right. Local vendors here are having aluminum capability but > can > > > not meet our die's pitch between pads, because they have only 1.0 mil. > Will > > > not have > > > good quality in aluminum process on our case. Fortunately here have 0.7 > mil > > > gold wire process but expensive. :-) And most early vendors here had > moved > > > into China. > > > > > > [1] > > > > http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/pcb/cob/bonding_wire/ > > > > > > > Amazing pictures (the bonding_wire7.jpg is my new desktop background :) > ) > > > > The price of the jz4720 plus the bonding wire price is competitive > > against the jz4740 price plus the BGA soldering process? > > > > BR, > > > > Andr?s Calder?n > > Cel: +57 (300) 275 3666 > > Email: andres.calderon at emqbit.com > > Web: www.emqbit.com > > > > > > > Adam > > > > > > Carlos Camargo wrote: > > > > > > Hi Adam > > > > > > Can you please upload a processor close-up photo? > > > > > > Best Regards > > > > > > > > > Carlos > > > > > > > > > On Sun, Sep 13, 2009 at 8:30 AM, Carlos Camargo > > > > wrote: > > >> > > >> hi adam, good job. i want one new board :). > > >> when finish all tests, please check the kicad brd file. we want that > > >> the next board will be designed in kicad. > > >> We've already uploaded pcb and footprints files, all components > placed, > > >> and remove a lot of test-points > > >> > > >> Can you please check if the placement and size are right ? > > >> > > >> Best Regards > > >> > > >> > > >> Carlos > > >> > > >> On Sun, Sep 13, 2009 at 3:52 AM, Adam Wang > wrote: > > >>> > > >>> Hi All, > > >>> > > >>> The picture of avt2_v1.0 board with die is here[1]. > > >>> And it just works and shown up[2]. > > >>> I'll keep do more basic IO tests. > > >>> Adam > > >>> > > >>> [1] > > >>> > http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/smt/pictures/top_jz4720.jpg > > >>> [2] > > >>> > http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/report/photos/avt2_v1.0_works.JPG > > >>> > > >>> Adam Wang wrote: > > >>>> > > >>>> Hi All, > > >>>> > > >>>> We're now on the process to produce small run of avt2 board, here is > the > > >>>> top side of avt2 without jz4720 temporarily; > > >>>> > > >>>> > http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/smt/pictures/top.jpg > > >>>> Will keep you posted later. > > >>>> Adam > > >>> > > >>> > > >>> _______________________________________________ > > >>> Qi Developer Mailing List > > >>> Mail to list (members only): developer at lists.qi-hardware.com > > >>> Subscribe or Unsubscribe: > > >>> http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > >> > > >> > > >> > > >> -- > > >> Carlos Iv?n Camargo Bare?o > > >> Profesor Asistente > > >> Departamento de Ingenier?a El?ctrica y Electr?nica > > >> Universidad Nacional de Colombia > > >> cicamargoba at unal.edu.co > > > > > > > > > > > > -- > > > Carlos Iv?n Camargo Bare?o > > > Profesor Asistente > > > Departamento de Ingenier?a El?ctrica y Electr?nica > > > Universidad Nacional de Colombia > > > cicamargoba at unal.edu.co > > > > > > ________________________________ > > > _______________________________________________ > > > Qi Developer Mailing List > > > Mail to list (members only): developer at lists.qi-hardware.com > > > Subscribe or Unsubscribe: > > > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > > > > > _______________________________________________ > > > Qi Developer Mailing List > > > Mail to list (members only): developer at lists.qi-hardware.com > > > Subscribe or Unsubscribe: > > > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > > > > > > _______________________________________________ > > Qi Developer Mailing List > > Mail to list (members only): developer at lists.qi-hardware.com > > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > -- Carlos Iv?n Camargo Bare?o Profesor Asistente Departamento de Ingenier?a El?ctrica y Electr?nica Universidad Nacional de Colombia cicamargoba at unal.edu.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From cicamargoba at gmail.com Wed Sep 30 20:36:12 2009 From: cicamargoba at gmail.com (Carlos Camargo) Date: Wed, 30 Sep 2009 19:36:12 -0500 Subject: qi_avt2 v1.0 board status In-Reply-To: <19ebea720909301559w7f174f2akadac0e138c212d54@mail.gmail.com> References: <4AAA0C6A.5050409@qi-hardware.com> <4AACB2EB.7030601@qi-hardware.com> <19ebea720909130630u154dad1w6d206965830aa342@mail.gmail.com> <19ebea720909130648xf701545v2920050efd67a4f0@mail.gmail.com> <4AC22D4F.3070306@qi-hardware.com> <6e36f2f00909292038g1343d3cna2aa6a7d2368439e@mail.gmail.com> <20090930100559.GA4387@debian> <19ebea720909301559w7f174f2akadac0e138c212d54@mail.gmail.com> Message-ID: <19ebea720909301736r7e1a5779o76e18cb8ddafec5c@mail.gmail.com> I'm starting the tests I'm using: ########################################################################## root at xburst:~# uname -a Linux xburst 2.6.27-dirty #40 PREEMPT Wed Sep 23 12:28:02 COT 2009 mips unknown ########################################################################## root filesystem on SD card works fine, is necessary change in include/configs/qi_lb60.h ########################################################################## #define GPIO_SD_DETECT (3 * 32 + 0) to: #define GPIO_SD_DETECT (3 * 32 + 15) // qi_AVT2 v1.0 use GPD15 And #define SDRAM_COL 9 /* Column address: 8 to 12 */ to: #define SDRAM_COL 10 /* Column address: 8 to 12 */ // qi_AVT2 v1.0 have 64MB ########################################################################## Linux use 64MB: ########################################################################## root at xburst:~# free total used free shared buffers cached Mem: 61088 22336 38752 0 1228 10320 -/+ buffers/cache: 10788 50300 Swap: 0 0 0 ########################################################################## I've already compile mplayer from ingenic source and I can play a mp3 file I can hear the sound on headphones, but no on speaker, maybe AMPEN is not enabled, I will change the AMPEN signal value and try again tomorrow. I've already attached a USB memory but the kernel don't detect it, maybe the USB_ID signal has a wrong value, I will tyr to change this value tomorrow an d try again Best Regards Carlos On Wed, Sep 30, 2009 at 5:59 PM, Carlos Camargo wrote: > Hello > > Very beautiful pictures Adam!!! > > I have two boards with 64MB and works fine, I have a little problem with > the LCD connector, I Think that this connector change its shape in the > soldering process, so I replace this connector in both boards by another one > (thanks Adam) and I can use both LCDs. I'm starting to test the sound and > USB host port. I'm attaching some Nano pictures [1] New Nano show openwrt > Logo [2] Using a custom FTDI USB-serial (I think that we can provide this > board with a Nano developer version) [3] With usb host connector attached > > > [1] http://downloads.qi-hardware.com/hardware/hacking/Nano_works.jpg > [2] http://downloads.qi-hardware.com/hardware/hacking/usb_serial.jpg > [3] http://downloads.qi-hardware.com/hardware/hacking/usb_host.jpg > > Best Regards > > > Carlos > > > > On Wed, Sep 30, 2009 at 5:05 AM, Wolfgang Spraul > wrote: > >> Andres, >> >> > The price of the jz4720 plus the bonding wire price is competitive >> > against the jz4740 price plus the BGA soldering process? >> >> Well that's a very long story, as always with prices :-) >> COB is getting more popular in China (and that means in most consumer >> electronics), because it is cheaper. At least that's what the >> manufacturers >> are saying but I'm sure companies that are producing millions of devices >> each >> month know their numbers. >> >> For the 20 boards we produced, we paid about 30 USD / chip for the COB :-) >> Not exactly cheaper... >> See a more detailed cost breakdown for the 20 boards at >> >> http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/report/expense/avt2_v1.0_expense.ods >> For 500 boards the price would go down to ca. 15 USD / chip for the COB >> alone. >> >> Now, one problem we had was that Adam could not find COB places in >> northern >> Taiwan that could do .8mil aluminum wires (see Adam's mail that you just >> responded to). So in order to just 'get the boards done', he chose .7mil >> gold wires. >> >> Going forward we need to improve all this. >> Maybe for another few small runs we continue to do COB, especially since >> Adam has it all figured out now. But then we will probably look into >> QFP/QFN >> versions, or BGA. The problem with switching to BGA on the current >> NanoNote >> board was that Adam said because the other side of the PCB was all covered >> by keys, we would need to go from a 4-layer to a 6-layer PCB when using >> BGA. >> >> Wolfgang >> >> On Tue, Sep 29, 2009 at 10:38:44PM -0500, Andr?s Calder?n wrote: >> > On Tue, Sep 29, 2009 at 10:52 AM, Adam Wang >> wrote: >> > > Hi Carlos, >> > > >> > > Sorry for the late, you can check those pictures of actual bonding >> wire >> > > here[1]. It's an 0.7mil golden wire. I can illustrate a little bit in >> report >> > > to show how make >> > > it layout right. Local vendors here are having aluminum capability but >> can >> > > not meet our die's pitch between pads, because they have only 1.0 mil. >> Will >> > > not have >> > > good quality in aluminum process on our case. Fortunately here have >> 0.7 mil >> > > gold wire process but expensive. :-) And most early vendors here had >> moved >> > > into China. >> > > >> > > [1] >> > > >> http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/pcb/cob/bonding_wire/ >> > > >> > >> > Amazing pictures (the bonding_wire7.jpg is my new desktop background :) >> ) >> > >> > The price of the jz4720 plus the bonding wire price is competitive >> > against the jz4740 price plus the BGA soldering process? >> > >> > BR, >> > >> > Andr?s Calder?n >> > Cel: +57 (300) 275 3666 >> > Email: andres.calderon at emqbit.com >> > Web: www.emqbit.com >> > >> > >> > > Adam >> > > >> > > Carlos Camargo wrote: >> > > >> > > Hi Adam >> > > >> > > Can you please upload a processor close-up photo? >> > > >> > > Best Regards >> > > >> > > >> > > Carlos >> > > >> > > >> > > On Sun, Sep 13, 2009 at 8:30 AM, Carlos Camargo < >> cicamargoba at gmail.com> >> > > wrote: >> > >> >> > >> hi adam, good job. i want one new board :). >> > >> when finish all tests, please check the kicad brd file. we want that >> > >> the next board will be designed in kicad. >> > >> We've already uploaded pcb and footprints files, all components >> placed, >> > >> and remove a lot of test-points >> > >> >> > >> Can you please check if the placement and size are right ? >> > >> >> > >> Best Regards >> > >> >> > >> >> > >> Carlos >> > >> >> > >> On Sun, Sep 13, 2009 at 3:52 AM, Adam Wang >> wrote: >> > >>> >> > >>> Hi All, >> > >>> >> > >>> The picture of avt2_v1.0 board with die is here[1]. >> > >>> And it just works and shown up[2]. >> > >>> I'll keep do more basic IO tests. >> > >>> Adam >> > >>> >> > >>> [1] >> > >>> >> http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/smt/pictures/top_jz4720.jpg >> > >>> [2] >> > >>> >> http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/report/photos/avt2_v1.0_works.JPG >> > >>> >> > >>> Adam Wang wrote: >> > >>>> >> > >>>> Hi All, >> > >>>> >> > >>>> We're now on the process to produce small run of avt2 board, here >> is the >> > >>>> top side of avt2 without jz4720 temporarily; >> > >>>> >> > >>>> >> http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/smt/pictures/top.jpg >> > >>>> Will keep you posted later. >> > >>>> Adam >> > >>> >> > >>> >> > >>> _______________________________________________ >> > >>> Qi Developer Mailing List >> > >>> Mail to list (members only): developer at lists.qi-hardware.com >> > >>> Subscribe or Unsubscribe: >> > >>> http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer >> > >> >> > >> >> > >> >> > >> -- >> > >> Carlos Iv?n Camargo Bare?o >> > >> Profesor Asistente >> > >> Departamento de Ingenier?a El?ctrica y Electr?nica >> > >> Universidad Nacional de Colombia >> > >> cicamargoba at unal.edu.co >> > > >> > > >> > > >> > > -- >> > > Carlos Iv?n Camargo Bare?o >> > > Profesor Asistente >> > > Departamento de Ingenier?a El?ctrica y Electr?nica >> > > Universidad Nacional de Colombia >> > > cicamargoba at unal.edu.co >> > > >> > > ________________________________ >> > > _______________________________________________ >> > > Qi Developer Mailing List >> > > Mail to list (members only): developer at lists.qi-hardware.com >> > > Subscribe or Unsubscribe: >> > > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer >> > > >> > > _______________________________________________ >> > > Qi Developer Mailing List >> > > Mail to list (members only): developer at lists.qi-hardware.com >> > > Subscribe or Unsubscribe: >> > > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer >> > > >> > >> > _______________________________________________ >> > Qi Developer Mailing List >> > Mail to list (members only): developer at lists.qi-hardware.com >> > Subscribe or Unsubscribe: >> http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer >> >> _______________________________________________ >> Qi Developer Mailing List >> Mail to list (members only): developer at lists.qi-hardware.com >> Subscribe or Unsubscribe: >> http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer >> > > > > -- > Carlos Iv?n Camargo Bare?o > Profesor Asistente > Departamento de Ingenier?a El?ctrica y Electr?nica > Universidad Nacional de Colombia > cicamargoba at unal.edu.co > -- Carlos Iv?n Camargo Bare?o Profesor Asistente Departamento de Ingenier?a El?ctrica y Electr?nica Universidad Nacional de Colombia cicamargoba at unal.edu.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at qi-hardware.com Wed Sep 30 21:03:49 2009 From: adam at qi-hardware.com (Adam Wang) Date: Thu, 01 Oct 2009 09:03:49 +0800 Subject: qi_avt2 v1.0 board status In-Reply-To: <19ebea720909301559w7f174f2akadac0e138c212d54@mail.gmail.com> References: <4AAA0C6A.5050409@qi-hardware.com> <4AACB2EB.7030601@qi-hardware.com> <19ebea720909130630u154dad1w6d206965830aa342@mail.gmail.com> <19ebea720909130648xf701545v2920050efd67a4f0@mail.gmail.com> <4AC22D4F.3070306@qi-hardware.com> <6e36f2f00909292038g1343d3cna2aa6a7d2368439e@mail.gmail.com> <20090930100559.GA4387@debian> <19ebea720909301559w7f174f2akadac0e138c212d54@mail.gmail.com> Message-ID: <4AC3FFF5.5020105@qi-hardware.com> Hi Carlos, Congradulations!!! Carlos Camargo wrote: > Hello > > Very beautiful pictures Adam!!! > > I have two boards with 64MB and works fine, I have a little problem > with the LCD connector, I Think that this connector change its shape > in the soldering process, Yes, you are right. The LCD connector should be normally in mounting by SMT process, but for cob process they need a smooth and flat bottom side which so i cannot use automatically mount machine to do it first because it will need an extra expense for jig to meet the bottom side's all components' shape on cob site. If having more quantities, the jig can be applied, so this condition should won't be occurred. :-) > so I replace this connector in both boards by another one (thanks > Adam) and I can use both LCDs. I'm starting to test the sound and USB > host port. I'm attaching The whole new picture of Nanonote for avt2 is now same as me here. :-) The sound and USB host port yeah need your help later. And the current status of avt2 v2.0 is at here, you all can quickly see that. http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/report/qi_avt2_v1.0_report.ods > some Nano pictures [1] New Nano show openwrt Logo [2] Using a custom > FTDI USB-serial (I think that we can provide this board with a Nano > developer version) Do you think that the serial console cable provided to you is good for h/w hacker in purpose? It was made by here vendor in free. The question is that I've not been used to meet the FTDI USB-serial board's female pin holders, from the pictures it seems a 2.54mm or 2.00mm pitch, right? I have 20 pcs about such kind of serial console cable. We can do this work by ourselves to meet any board we're using. But I am not sure if this is easy and reachable for s/w hacker. Adam > [3] With usb host connector attached > > > [1] http://downloads.qi-hardware.com/hardware/hacking/Nano_works.jpg > [2] http://downloads.qi-hardware.com/hardware/hacking/usb_serial.jpg > [3] http://downloads.qi-hardware.com/hardware/hacking/usb_host.jpg > > Best Regards > > > Carlos > > > On Wed, Sep 30, 2009 at 5:05 AM, Wolfgang Spraul > > wrote: > > Andres, > > > The price of the jz4720 plus the bonding wire price is competitive > > against the jz4740 price plus the BGA soldering process? > > Well that's a very long story, as always with prices :-) > COB is getting more popular in China (and that means in most consumer > electronics), because it is cheaper. At least that's what the > manufacturers > are saying but I'm sure companies that are producing millions of > devices each > month know their numbers. > > For the 20 boards we produced, we paid about 30 USD / chip for the > COB :-) > Not exactly cheaper... > See a more detailed cost breakdown for the 20 boards at > http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/report/expense/avt2_v1.0_expense.ods > For 500 boards the price would go down to ca. 15 USD / chip for > the COB alone. > > Now, one problem we had was that Adam could not find COB places in > northern > Taiwan that could do .8mil aluminum wires (see Adam's mail that > you just > responded to). So in order to just 'get the boards done', he chose > .7mil > gold wires. > > Going forward we need to improve all this. > Maybe for another few small runs we continue to do COB, especially > since > Adam has it all figured out now. But then we will probably look > into QFP/QFN > versions, or BGA. The problem with switching to BGA on the current > NanoNote > board was that Adam said because the other side of the PCB was all > covered > by keys, we would need to go from a 4-layer to a 6-layer PCB when > using BGA. > > Wolfgang > > On Tue, Sep 29, 2009 at 10:38:44PM -0500, Andr?s Calder?n wrote: > > On Tue, Sep 29, 2009 at 10:52 AM, Adam Wang > > wrote: > > > Hi Carlos, > > > > > > Sorry for the late, you can check those pictures of actual > bonding wire > > > here[1]. It's an 0.7mil golden wire. I can illustrate a little > bit in report > > > to show how make > > > it layout right. Local vendors here are having aluminum > capability but can > > > not meet our die's pitch between pads, because they have only > 1.0 mil. Will > > > not have > > > good quality in aluminum process on our case. Fortunately here > have 0.7 mil > > > gold wire process but expensive. :-) And most early vendors > here had moved > > > into China. > > > > > > [1] > > > > http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/pcb/cob/bonding_wire/ > > > > > > > Amazing pictures (the bonding_wire7.jpg is my new desktop > background :) ) > > > > The price of the jz4720 plus the bonding wire price is competitive > > against the jz4740 price plus the BGA soldering process? > > > > BR, > > > > Andr?s Calder?n > > Cel: +57 (300) 275 3666 > > Email: andres.calderon at emqbit.com > > > Web: www.emqbit.com > > > > > > > Adam > > > > > > Carlos Camargo wrote: > > > > > > Hi Adam > > > > > > Can you please upload a processor close-up photo? > > > > > > Best Regards > > > > > > > > > Carlos > > > > > > > > > On Sun, Sep 13, 2009 at 8:30 AM, Carlos Camargo > > > > > wrote: > > >> > > >> hi adam, good job. i want one new board :). > > >> when finish all tests, please check the kicad brd file. we > want that > > >> the next board will be designed in kicad. > > >> We've already uploaded pcb and footprints files, all > components placed, > > >> and remove a lot of test-points > > >> > > >> Can you please check if the placement and size are right ? > > >> > > >> Best Regards > > >> > > >> > > >> Carlos > > >> > > >> On Sun, Sep 13, 2009 at 3:52 AM, Adam Wang > > wrote: > > >>> > > >>> Hi All, > > >>> > > >>> The picture of avt2_v1.0 board with die is here[1]. > > >>> And it just works and shown up[2]. > > >>> I'll keep do more basic IO tests. > > >>> Adam > > >>> > > >>> [1] > > >>> > http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/smt/pictures/top_jz4720.jpg > > >>> [2] > > >>> > http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/report/photos/avt2_v1.0_works.JPG > > >>> > > >>> Adam Wang wrote: > > >>>> > > >>>> Hi All, > > >>>> > > >>>> We're now on the process to produce small run of avt2 > board, here is the > > >>>> top side of avt2 without jz4720 temporarily; > > >>>> > > >>>> > http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/smt/pictures/top.jpg > > >>>> Will keep you posted later. > > >>>> Adam > > >>> > > >>> > > >>> _______________________________________________ > > >>> Qi Developer Mailing List > > >>> Mail to list (members only): developer at lists.qi-hardware.com > > > >>> Subscribe or Unsubscribe: > > >>> http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > >> > > >> > > >> > > >> -- > > >> Carlos Iv?n Camargo Bare?o > > >> Profesor Asistente > > >> Departamento de Ingenier?a El?ctrica y Electr?nica > > >> Universidad Nacional de Colombia > > >> cicamargoba at unal.edu.co > > > > > > > > > > > > -- > > > Carlos Iv?n Camargo Bare?o > > > Profesor Asistente > > > Departamento de Ingenier?a El?ctrica y Electr?nica > > > Universidad Nacional de Colombia > > > cicamargoba at unal.edu.co > > > > > > ________________________________ > > > _______________________________________________ > > > Qi Developer Mailing List > > > Mail to list (members only): developer at lists.qi-hardware.com > > > > Subscribe or Unsubscribe: > > > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > > > > > _______________________________________________ > > > Qi Developer Mailing List > > > Mail to list (members only): developer at lists.qi-hardware.com > > > > Subscribe or Unsubscribe: > > > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > > > > > > _______________________________________________ > > Qi Developer Mailing List > > Mail to list (members only): developer at lists.qi-hardware.com > > > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > > > > -- > Carlos Iv?n Camargo Bare?o > Profesor Asistente > Departamento de Ingenier?a El?ctrica y Electr?nica > Universidad Nacional de Colombia > cicamargoba at unal.edu.co > ------------------------------------------------------------------------ > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at qi-hardware.com Wed Sep 30 21:20:01 2009 From: adam at qi-hardware.com (Adam Wang) Date: Thu, 01 Oct 2009 09:20:01 +0800 Subject: qi_avt2 v1.0 board status In-Reply-To: <19ebea720909301736r7e1a5779o76e18cb8ddafec5c@mail.gmail.com> References: <4AAA0C6A.5050409@qi-hardware.com> <4AACB2EB.7030601@qi-hardware.com> <19ebea720909130630u154dad1w6d206965830aa342@mail.gmail.com> <19ebea720909130648xf701545v2920050efd67a4f0@mail.gmail.com> <4AC22D4F.3070306@qi-hardware.com> <6e36f2f00909292038g1343d3cna2aa6a7d2368439e@mail.gmail.com> <20090930100559.GA4387@debian> <19ebea720909301559w7f174f2akadac0e138c212d54@mail.gmail.com> <19ebea720909301736r7e1a5779o76e18cb8ddafec5c@mail.gmail.com> Message-ID: <4AC403C1.6060805@qi-hardware.com> Carlos Camargo wrote: > I'm starting the tests > > > I'm using: > > ########################################################################## > root at xburst:~# uname -a > Linux xburst 2.6.27-dirty #40 PREEMPT Wed Sep 23 12:28:02 COT 2009 > mips unknown > ########################################################################## > > root filesystem on SD card works fine, is necessary change in > include/configs/qi_lb60.h > ########################################################################## > > #define GPIO_SD_DETECT (3 * 32 + 0) > > to: > > #define GPIO_SD_DETECT (3 * 32 + 15) // qi_AVT2 v1.0 use GPD15 > > And > #define SDRAM_COL 9 /* Column address: 8 to 12 */ > > to: > > #define SDRAM_COL 10 /* Column address: 8 to 12 */ // > qi_AVT2 v1.0 have 64MB > ########################################################################## > > Linux use 64MB: > > ########################################################################## > root at xburst:~# free > total used free shared buffers cached > Mem: 61088 22336 38752 0 1228 10320 > -/+ buffers/cache: 10788 50300 > Swap: 0 0 0 > ########################################################################## > > I've already compile mplayer from ingenic source and I can play a mp3 > file I can hear the sound on headphones, but no on speaker, maybe > AMPEN is not enabled, I will change the AMPEN signal value and try > again tomorrow. > given AMPEN "high" to enable. > I've already attached a USB memory but the kernel don't detect it, > maybe the USB_ID signal has a wrong value, I will tyr to change this > value tomorrow an d try again > > The Adapter when you plug into avt2 board (without plugging your USB memory) will automatically let USB_ID signal to be as "low" condition. <<< The +5V should already provided out. Yeah...may be the initial value. Could you try to disable the USB_ID pin in s/w to check it first? Adam > Best Regards > > > Carlos > > > On Wed, Sep 30, 2009 at 5:59 PM, Carlos Camargo > wrote: > > Hello > > Very beautiful pictures Adam!!! > > I have two boards with 64MB and works fine, I have a little > problem with the LCD connector, I Think that this connector change > its shape in the soldering process, so I replace this connector in > both boards by another one (thanks Adam) and I can use both LCDs. > I'm starting to test the sound and USB host port. I'm attaching > some Nano pictures [1] New Nano show openwrt Logo [2] Using a > custom FTDI USB-serial (I think that we can provide this board > with a Nano developer version) [3] With usb host connector attached > > > [1] http://downloads.qi-hardware.com/hardware/hacking/Nano_works.jpg > [2] http://downloads.qi-hardware.com/hardware/hacking/usb_serial.jpg > [3] http://downloads.qi-hardware.com/hardware/hacking/usb_host.jpg > > Best Regards > > > Carlos > > > > On Wed, Sep 30, 2009 at 5:05 AM, Wolfgang Spraul > > wrote: > > Andres, > > > The price of the jz4720 plus the bonding wire price is > competitive > > against the jz4740 price plus the BGA soldering process? > > Well that's a very long story, as always with prices :-) > COB is getting more popular in China (and that means in most > consumer > electronics), because it is cheaper. At least that's what the > manufacturers > are saying but I'm sure companies that are producing millions > of devices each > month know their numbers. > > For the 20 boards we produced, we paid about 30 USD / chip for > the COB :-) > Not exactly cheaper... > See a more detailed cost breakdown for the 20 boards at > http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/report/expense/avt2_v1.0_expense.ods > For 500 boards the price would go down to ca. 15 USD / chip > for the COB alone. > > Now, one problem we had was that Adam could not find COB > places in northern > Taiwan that could do .8mil aluminum wires (see Adam's mail > that you just > responded to). So in order to just 'get the boards done', he > chose .7mil > gold wires. > > Going forward we need to improve all this. > Maybe for another few small runs we continue to do COB, > especially since > Adam has it all figured out now. But then we will probably > look into QFP/QFN > versions, or BGA. The problem with switching to BGA on the > current NanoNote > board was that Adam said because the other side of the PCB was > all covered > by keys, we would need to go from a 4-layer to a 6-layer PCB > when using BGA. > > Wolfgang > > On Tue, Sep 29, 2009 at 10:38:44PM -0500, Andr?s Calder?n wrote: > > On Tue, Sep 29, 2009 at 10:52 AM, Adam Wang > > wrote: > > > Hi Carlos, > > > > > > Sorry for the late, you can check those pictures of actual > bonding wire > > > here[1]. It's an 0.7mil golden wire. I can illustrate a > little bit in report > > > to show how make > > > it layout right. Local vendors here are having aluminum > capability but can > > > not meet our die's pitch between pads, because they have > only 1.0 mil. Will > > > not have > > > good quality in aluminum process on our case. Fortunately > here have 0.7 mil > > > gold wire process but expensive. :-) And most early > vendors here had moved > > > into China. > > > > > > [1] > > > > http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/pcb/cob/bonding_wire/ > > > > > > > Amazing pictures (the bonding_wire7.jpg is my new desktop > background :) ) > > > > The price of the jz4720 plus the bonding wire price is > competitive > > against the jz4740 price plus the BGA soldering process? > > > > BR, > > > > Andr?s Calder?n > > Cel: +57 (300) 275 3666 > > Email: andres.calderon at emqbit.com > > > Web: www.emqbit.com > > > > > > > Adam > > > > > > Carlos Camargo wrote: > > > > > > Hi Adam > > > > > > Can you please upload a processor close-up photo? > > > > > > Best Regards > > > > > > > > > Carlos > > > > > > > > > On Sun, Sep 13, 2009 at 8:30 AM, Carlos Camargo > > > > > wrote: > > >> > > >> hi adam, good job. i want one new board :). > > >> when finish all tests, please check the kicad brd file. > we want that > > >> the next board will be designed in kicad. > > >> We've already uploaded pcb and footprints files, all > components placed, > > >> and remove a lot of test-points > > >> > > >> Can you please check if the placement and size are right ? > > >> > > >> Best Regards > > >> > > >> > > >> Carlos > > >> > > >> On Sun, Sep 13, 2009 at 3:52 AM, Adam Wang > > wrote: > > >>> > > >>> Hi All, > > >>> > > >>> The picture of avt2_v1.0 board with die is here[1]. > > >>> And it just works and shown up[2]. > > >>> I'll keep do more basic IO tests. > > >>> Adam > > >>> > > >>> [1] > > >>> > http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/smt/pictures/top_jz4720.jpg > > >>> [2] > > >>> > http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/report/photos/avt2_v1.0_works.JPG > > >>> > > >>> Adam Wang wrote: > > >>>> > > >>>> Hi All, > > >>>> > > >>>> We're now on the process to produce small run of avt2 > board, here is the > > >>>> top side of avt2 without jz4720 temporarily; > > >>>> > > >>>> > http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/smt/pictures/top.jpg > > >>>> Will keep you posted later. > > >>>> Adam > > >>> > > >>> > > >>> _______________________________________________ > > >>> Qi Developer Mailing List > > >>> Mail to list (members only): > developer at lists.qi-hardware.com > > > >>> Subscribe or Unsubscribe: > > >>> > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > >> > > >> > > >> > > >> -- > > >> Carlos Iv?n Camargo Bare?o > > >> Profesor Asistente > > >> Departamento de Ingenier?a El?ctrica y Electr?nica > > >> Universidad Nacional de Colombia > > >> cicamargoba at unal.edu.co > > > > > > > > > > > > -- > > > Carlos Iv?n Camargo Bare?o > > > Profesor Asistente > > > Departamento de Ingenier?a El?ctrica y Electr?nica > > > Universidad Nacional de Colombia > > > cicamargoba at unal.edu.co > > > > > > ________________________________ > > > _______________________________________________ > > > Qi Developer Mailing List > > > Mail to list (members only): > developer at lists.qi-hardware.com > > > > Subscribe or Unsubscribe: > > > > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > > > > > _______________________________________________ > > > Qi Developer Mailing List > > > Mail to list (members only): > developer at lists.qi-hardware.com > > > > Subscribe or Unsubscribe: > > > > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > > > > > > _______________________________________________ > > Qi Developer Mailing List > > Mail to list (members only): developer at lists.qi-hardware.com > > > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > > Subscribe or Unsubscribe: > http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer > > > > > -- > Carlos Iv?n Camargo Bare?o > Profesor Asistente > Departamento de Ingenier?a El?ctrica y Electr?nica > Universidad Nacional de Colombia > cicamargoba at unal.edu.co > > > > > -- > Carlos Iv?n Camargo Bare?o > Profesor Asistente > Departamento de Ingenier?a El?ctrica y Electr?nica > Universidad Nacional de Colombia > cicamargoba at unal.edu.co > ------------------------------------------------------------------------ > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer -------------- next part -------------- An HTML attachment was scrubbed... URL: From andres.calderon at emqbit.com Wed Sep 30 21:42:57 2009 From: andres.calderon at emqbit.com (=?ISO-8859-1?Q?Andr=E9s_Calder=F3n?=) Date: Wed, 30 Sep 2009 20:42:57 -0500 Subject: jz4760 Message-ID: <6e36f2f00909301842r2a45c88p96defaf58c2c76eb@mail.gmail.com> Anyone have information on jz4760 SoC? Ingenic added in the kernel 2.6.27 jz4760 support (ethernet included). in some places mentioned 700Mhz clock[1][2] [1] http://www.gp32spain.com/foros/showthread.php?t=66873&page=7 [2] http://bbs.imp3.net/thread-626846-2-1.html There is a DS anywhere? package? availability? BR, Andr?s Calder?n Cel: +57 (300) 275 3666 Email: andres.calderon at emqbit.com Web: www.emqbit.com From wolfgang at qi-hardware.com Wed Sep 30 22:24:17 2009 From: wolfgang at qi-hardware.com (Wolfgang Spraul) Date: Wed, 30 Sep 2009 22:24:17 -0400 Subject: jz4760 In-Reply-To: <6e36f2f00909301842r2a45c88p96defaf58c2c76eb@mail.gmail.com> References: <6e36f2f00909301842r2a45c88p96defaf58c2c76eb@mail.gmail.com> Message-ID: <20091001022417.GA5855@debian> Andres, > There is a DS anywhere? package? availability? No datasheet, not decided which package, not available. They are working on it but I would not expect it before next year. Maybe we can do a copyleft reference design with Ingenic, we'll see... Wolfgang On Wed, Sep 30, 2009 at 08:42:57PM -0500, Andr?s Calder?n wrote: > Anyone have information on jz4760 SoC? > > Ingenic added in the kernel 2.6.27 jz4760 support (ethernet included). > > in some places mentioned 700Mhz clock[1][2] > > [1] http://www.gp32spain.com/foros/showthread.php?t=66873&page=7 > [2] http://bbs.imp3.net/thread-626846-2-1.html > > There is a DS anywhere? package? availability? > > BR, > > Andr?s Calder?n > Cel: +57 (300) 275 3666 > Email: andres.calderon at emqbit.com > Web: www.emqbit.com > > _______________________________________________ > Qi Developer Mailing List > Mail to list (members only): developer at lists.qi-hardware.com > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer