[ADM] migrating from gitweb to cgit
Hi! Sometimes people run quite extensive crawlers or recursive site-rips even on git repositories, and even ignoring robots.txt (which we didn't even have on git.openezx.org). I've had this on a number of sites and it is generally fixed by installing cgit instead of gitweb. I've done this for openezx.org, and you can see the result at http://cgit.openezx.org/ I would like to request your comments on how to proceed: 1) simply run cgit on http://git.openezx.org ? or 2) deactivate http://git.openezx.org and put a redirect to http://cgit.openezx.org/ What do you think? Regards, Harald -- - Harald Welte lafo...@gnumonks.org http://laforge.gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6)
wiki.openezx.org administrative downtime
Hi all, due to some problems during a distribution upgrade resulting in old Mediawiki - new PHP incompatibilities, wiki.openezx.org is currently down. We expect it to be back online until the weekend. Sorry for any inconvenience, Harald -- - Harald Welte lafo...@gnumonks.org http://laforge.gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6)
Kernel/Userspace 07.10 muxer (was Re: Code from OpenEZX used for Motorola Milestone.)
Hi Erik On Mon, Jan 04, 2010 at 12:49:34PM -0800, Erik Gilling wrote: My personal opinion is that this code doesn't really need to be in the kernel. In Android's case it could be integrated into the radio interface layer in user space. Well, the question is if you really can afford that many additional context switches. For a GPRS modem, you can still afford to pipe all the data from the kernel through userspace, back into the kernel and back into userspace. But once you move into the 3G world, I doubt you want the added latency and power consumption that results from a userspace 07.10 multiplexer. Sure, if your baseband has a separate interface for data and you use 07.10 just for signalling / SMS, then it doesn't matter. Regards, Harald -- - Harald Welte lafo...@gnumonks.org http://laforge.gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6)
Thanks to drwyrm for his mainline efforts
Dear Daniel, I know it's quite late but I've been so far away from OpenEZX for a long time. I would just like to thank you once again for all the marvellous work that you've been doing getting the PCAP and other bits in shape, merging them mainline. I've worked on this stuff three to five years ago, and finally, you complete it by getting it mainline. Thanks for your dedication. I still use my A780, A1200 every day, and the E6 every time I visit Taiwan, all with the original firmware though. If I find some time on Linux phone related hacking, I have (and will) spend it on the E-TEN glofiish units, if not only for the fact that they're based on Samsung application processors that I'm very familiar with by now... So keep up the great work on the OpenEZX kernel... -- - Harald Welte lafo...@gnumonks.org http://laforge.gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6)
Re: Motorola replaces EZX+MAGX with Android
On Thu, Oct 30, 2008 at 08:26:04AM -0400, Jason wrote: So my basic question is this. Using something like openocd, once a JTAG is found on a given phone, is it possible to wipe this junk out or work around it? How much work is it to build a _basic_ bootloader to replace the locked down one? Am I missing some EE/crypto magic in this process? Modern SoC's for secure applications usually include hardware-enhanced boot security. I've seen JTAG with cryptographic authentication in TV set top boxes before, and most of the modern SoC are available in a special 'secure' version that actually contains mask-rom boot code that can do signature checks, etc. I think with most current-generation cellphones you still don't see this in widespread use. But expect anything released in 1-2 years from now to use this kind of technology. -- - Harald Welte [EMAIL PROTECTED] http://laforge.gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) signature.asc Description: Digital signature
Motorola replaces EZX+MAGX with Android
Sorry, in German: http://www.heise.de/newsticker/Bericht-Motorola-setzt-auf-Android--/meldung/118126 it basically states that motorola wants to consolidate the mobile phone platforms to P2K, Android and Windows Mobile. -- - Harald Welte [EMAIL PROTECTED] http://laforge.gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) signature.asc Description: Digital signature
Re: pcap changes, a910 mmc.
hi drwyrm, On Sun, Aug 24, 2008 at 09:14:03PM -0300, Daniel Ribeiro wrote: On Sun, Aug 24, 2008 at 3:54 PM, Daniel Ribeiro [EMAIL PROTECTED] wrote: I still have some problems with lost interrupts and and zeroed adc readings, but the latency is all gone, if we manage to get the pcap event handler right, i think that the TS will be as smooth as it was when running on irq context. Done, TS latency issues solved, no adc errors, pcap event handler seems to be working fine. The TS is just as smooth as it was with the previous hardirq context code, and much smoother than it is on the 2.4 kernel. ok. great work. thanks. -- - Harald Welte [EMAIL PROTECTED] http://laforge.gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) signature.asc Description: Digital signature
Re: pcap changes, a910 mmc.
Hi Daniel! On Sun, Aug 17, 2008 at 03:47:01PM -0300, Daniel Ribeiro wrote: ezx-pcap: convert pcap to spi, remove irq demultiplexer http://git.openezx.org/?p=openezx.git;a=commitdiff;h=78e4f5efc84cdf123095268f544000cd91819297 http://git.openezx.org/?p=openezx.git;a=commitdiff;h=da576d7e2de31e1d325545916e955b86766cd0c7 This is the main pcap design change, It uses a workqueue to run events instead of an IRQ chip. The advantage on doing this is that we dont need to block the CPU to wait for IO, this has the potential of bringing average system load down, but it will certainly increase latency. This patch also stop using ssp.c directly, and uses the pxa2xx_spi driver, this is needed to share the SPI bus, but also creates a lot of problems with the ordering that the drivers are loaded, so i had to do substantial changes to ezx.c to assert that other drivers dont try to use the pcap driver before it was loaded. I think this has both advantages and disadvantages. I may be biased since I invented (and spent a lot of time debugging) the IRQ demux based method. I like about the IRQ method the simplicity of the actual device drivers. They just use regular struct resource and an IRQ number, rather than some fancy (and pcap driver specific) callback mechanism. Sure, I also understand the disadvantages of this approach, particularly the latency implications of blocking the CPU while waiting for SPI I/O. With regard to driver load ordering, a single 'hack' to make sure the pcap core is initialized early enough (by using link order) would probably have resolved the problem, too. Anyway, since you are the person working on this code now, the decision is yours. I just wanted to note that I have a hard time deciding which advantages outweigh which disadvantages. In any case, the IRQ number for the PCAP core driver should not be passed in platform data, but as part of a resource structure. Don't you agree. ezx-pcap, pcap_ts: change MODULE_AUTHOR http://git.openezx.org/?p=openezx.git;a=commitdiff;h=0a26861fc1dc6fda8eada4714545075d7fe0e740 Since most code of these two drivers changed a lot since Harald last worked on them, i am changing the module_author to me. I would prefer if it lists both names separated by a comma. I've seen other drivers doing it like this, too. The code is not well tested yet, some instability may occur on the pcap and pcap_ts drivers. The increased latency may also make the TS driver less responsive, tough I think that most people would not even notice. Tests and comments are welcome. This should definitely be tested a lot on non-a910 devices. -- - Harald Welte [EMAIL PROTECTED] http://laforge.gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) signature.asc Description: Digital signature
usb_mode and miniUSB mode switching (was Re: weekend hacking report / git work flow suggestions)
On Mon, Jul 28, 2008 at 09:50:03PM -0300, Daniel Ribeiro wrote: And, is the sysfs layout be something like that: http://wiki.openmoko.org/wiki/GTA02_sysfs ? For instance, the usb_mode entry looks useful :) Yes, something like that. But usb_mode switching at run-time is still a long way to go.. Proper detection of what is plugged to the miniUSB port, and charger support[*] is my short term goal. well, the question is whether you want to do that in the kernel anyway. You could just expose some kind of event interface to hal (like other power management events) and give the respective controls in sysfs files for a userspace event handler to decide what to do in which event. -- - Harald Welte [EMAIL PROTECTED] http://laforge.gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) signature.asc Description: Digital signature
Re: pcap changes, a910 mmc.
Hi Daniel, On Sat, Aug 23, 2008 at 11:05:37AM -0300, Daniel Ribeiro wrote: On Sat, Aug 23, 2008 at 4:18 AM, Harald Welte [EMAIL PROTECTED] wrote: I think this has both advantages and disadvantages. I may be biased since I invented (and spent a lot of time debugging) the IRQ demux based method. I like about the IRQ method the simplicity of the actual device drivers. They just use regular struct resource and an IRQ number, rather than some fancy (and pcap driver specific) callback mechanism. Sure, I also understand the disadvantages of this approach, particularly the latency implications of blocking the CPU while waiting for SPI I/O. In fact, using a workqueue has added much more latency than blocking the cpu for I/O. So much latency that the TS is unusable. well, it depends on which latency. Obviously, the latency of the 'interrupts' themselves will go up, no matter what you do. I think the irq_chip method that I implemented is possibly the fastest option that we have. But the overall system latency (e.g. for realtime tasks) should decrease, since the kernel doesn't do synchronous SPI in interrupt context anymore. I'm sorry to hear that the latency is so high that the touchscreen is unusable. This is a real indication that asynchronous processing by workqueue or other deferred mechanism is not a good solution, after all. But the problem is that i need to share the SPI bus with mmc_spi. To do this, i have to use the spi subsystem and pxa2xx_spi driver. But spi_sync sleeps. I will have a look at this, maybe I can find some other hack to make this work. What about going as far as to actually making the PCAP spi driver drivers/spi aware? I'm thinking about something like * pcap interrupt comes in via GPIO * pcap interrupt handler finds out if there still is an ongoing spi_sync() transfer. ** if no, we can directly do the old-style method of SPI PCAP register read and IRQ demux via irq_chip method. ** if yes, we need to somehow complete the existing spi_sync() transfer and schedule our SPI PCAP register read after it has finished. This obviously cannot happen in interrupt context, i.e. we need some kind of deferred execution for the entire demultiplex. Maybe I'm missing something, it's really been a long time since I last worked with all this code. But at least from my current point of view I don't see any big theoretical problem from doing so. The advantage would be that we keep the irq_chip semantics, we still have low-latency access unless we're right now in the middle of a MMC-related SPI transfer. That still sounds fairly reasonable to me. With regard to driver load ordering, a single 'hack' to make sure the pcap core is initialized early enough (by using link order) would probably have resolved the problem, too. Not really. As the pcap driver is loaded by the spi subsystem, we need to assert that the spi subsystem/pcap is ready before calling pxa_set_mci_info and pxa_set_udc_info. But anyway, the ordering seems to work. well, maybe the udc/mci drivers can be modified in a way to not start to talk to the actual devices before SPI is up. I'm sure there must be some kind of solution to this. maybe some magic with setting the device's parent pointer in order to reflect the actual inter-dependency also helps. I think openmoko had similar issues and they could be solved in a more-or-less elegant way. -- - Harald Welte [EMAIL PROTECTED] http://laforge.gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) signature.asc Description: Digital signature
Re: Time for git.openezx.org?
On Tue, Jul 15, 2008 at 05:22:23PM +0200, Stefan Schmidt wrote: I can craeate the DNS record and you just tell me which kind of ports you want me to open in the packet filter. We already have git.openezx.org which points to 213.95.46.71 like www, svn, etc http for the webinterface is open already, same for ssh for pushing. That means only the git server part needs to be opened. /etc/services tells me: git 9418/tcp# Git Version Control System done. should be open now. -- - Harald Welte [EMAIL PROTECTED] http://laforge.gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) signature.asc Description: Digital signature
Re: Questions and suggestions for the ezx-pcap driver
On Fri, Jun 27, 2008 at 01:01:38PM +0200, Stefan Schmidt wrote:
-int ezx_pcap_read(u_int8_t reg_num, u_int32_t *value)
+void ezx_pcap_read(u_int8_t reg_num, u_int32_t *value)
We give back an int that calling function could use as error indicator, but as
we always give back 0 that does not make much sense. Remove it or do error
checking in the fuction and give back a meaningfull value.
It's the same for ezx_pcap_write and this return values are really used.
I think I am the culprit for this. Thinking that even if the initial
code doesn't yet implement error handling, it would be good if the
higher-levle functions were written in a way that they could cope with
low-level errors being propagated.
If there is a way how to get error checking from the lower levels
through the read/write functions up the stack, I'm for it. If not, just
change them to void.
-EXPORT_SYMBOL_GPL(ezx_pcap_vibrator_level);
+EXPORT_SYMBOL_GPL(ezx_pcap_set_vibrator_level);
We are *setting* the value. Brings it in line with the other function names.
fine.
Add a case for the E2. Funny enough I booted into a rootfs on the sd card
yesterday on the E2 without this case. Makes me wonder a bit. Default values
seem to fit, but still I like an explicit case for it.
good.
+#ifdef CONFIG_PM
.suspend= ezx_pcap_suspend,
.resume = ezx_pcap_resume,
+#endif
.driver = {
.name = ezx-pcap,
.owner = THIS_MODULE,
At least this is the qay all other modules handle this.
alternatively you can #define ezx_pcap_suspend to NULL in the case
CONFIG_PM is switched off. Might look a bit cleaner since the structure
initializers are without #ifdef/endif. But probably a matter of taste.
--
- Harald Welte [EMAIL PROTECTED] http://laforge.gnumonks.org/
Privacy in residential applications is a desirable marketing option.
(ETSI EN 300 175-7 Ch. A6)
signature.asc
Description: Digital signature
Re: GIT tree for all kernel sources released by Motorola
On Mon, Feb 18, 2008 at 12:05:20AM +0100, Stefan Schmidt wrote: Hello. On Sun, 2008-02-17 at 20:05, Harald Welte wrote: On Sun, Feb 17, 2008 at 05:01:21PM +0100, Stefan Schmidt wrote: Still I liked the idea a lot, so I tried it out myself. http://git.datenfreihafen.org/?p=2.4-ezx-motorola.git;a=summary thansk a lot, this is great. We should publish this at openezx.org, what do you think? the git.openmoko.org dns entry exists for years, we just don't have the server running :) You really worked to much for OM. ;) Guess you mean git.openezx.org. ARGH. Of course. Too many Open* projects in my CV Would be great to have it there. Was not sure if the setup work would be worth it. If you setup the git stuff, I happily push it there and remove the one from datenfreihafen.org ok, will take care of the git server. Now I'll only need to do the same thing for opentom :) Do they still just dumping tarballs? yes, tarballs and diffs. Which is fine, and actually the complete tarballs is what they are required to publish under GPL. It would just be convenient to have a close look at the differences between their (many, many) releases. Cheers, -- - Harald Welte [EMAIL PROTECTED] http://laforge.gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) signature.asc Description: Digital signature
My recent committs to kernel-2.6.23.x-patches
[re-send since I mistyped the list address when sending it the first time] Hi Daniel! Sorry for just committing into the tree that you maintain. This is usually bad style. But I think this time it was ok, as Stefan and Alphaone agreed on #openezx. The commit's contain only cosmetic fixes and should not change any code at all. If I had sent a patch to the list, the patch would only contain whitespace changes and thus be quite ridiculous to read. Also, the faster I committed this stuff, the less likely are clahshes with work of other people. One big favor I would like to ask you is to please pay attention to tab/space indentation. This is definitely a no-go for mainline merge, and a big mess to clean up. I've done this once, so please keep it clean now. All indents should be tab-based. Oh, and another one: Please use the quilt --no-timestamps option. This helps to keep the svn changelog clean. In order to continue heading for mainline integration, I think the biggest issue is the machine type issue. I have thus registered machine types for A780, A1200, E2 and E6. My first idea was to recycle the old EZX for E680, but by now I'm convinced we should keep the old one unused by new code, just for the sake of clarity. Thus, I've now also registered a new E680 machine type. So as soon as we have decided how we want to assign the missing machine type before/during early kernel boot, the new types should be used throughout the code. Some additional comments: ezx_lcd_power() contains mdelay(). mdelay is always ugly since it keeps the CPU blocked. I think it is not called from IRQ context and thus should use msleep(). Am I missing something? Those 'extern ezx_lcd_power() and ezx_backlight_power have to go. please move them into a shared include file. Thanks. Oh, another issue: I think it would look great if you would also use an @openezx.org email address when referring to your email account throughout the source code. What do you think? Do you already have an account or a forward? If not, I'm happy to create one. Cheers, Finalmente: Eu lembro de voce era do Brasil, certo? Onde voce mora? Vou ficar em Brasil todo Marco 2008. Vou dar uma palestra na conferencia BOSSA 2008 em Recife (http://www.bossaconference.indt.org/). Ainda nao sei quais outros cidades/locais eu vou visitar, mas se possivel, queria encontrar voce! -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) signature.asc Description: Digital signature
Re: boot_usb and MOTORAZR2 V8
On Sun, Dec 09, 2007 at 04:31:00AM +0100, Daniel Willmann wrote: Hello list, tonight I decided to look a little at my the RAZR2 V8. It turns out that you can enter boot loader mode if you press and hold both the '*' and '#' buttons and then turn the phone on. Thanks a lot for your research so far. I've now ordered my own V8 and will probably start playing with it around 24C3 time. Maybe at that point we can share our experience. -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) signature.asc Description: Digital signature
Re: What is needed for getting ezx-core.patch ready for upstream submission?
On Tue, Dec 11, 2007 at 03:21:49PM +0100, Stefan Schmidt wrote: Anyway, MMC, USB and TS will not work without PCAP, so it needs to be the next one on the queue. Right. I just thought we could cheat in some more code before coming to this one. ;) I'm facing the same issue with regard to the pfc50606 / pcf50633 drivers for OpenMoko. It's impossible to even boot the hardware without the power management driver. I'll spend some time today/tomorrow to review the current EZX situation and comment on it. I'm happy to bring the PCAP driver (at least the power management parts) in line with what OpenMoko does, if you agree it is good to have some coherency here. -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) signature.asc Description: Digital signature
[EMAIL PROTECTED]: usb_boot ezx phones,]
Hi, this should have gone to the list instead to me: -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) ---BeginMessage--- hy i'm trying to boot a custom kernel version into my motorla ROKR E2. I download(co from svn) and compile the program but when i try to boot with the example kernel i only obtain this [EMAIL PROTECTED]:~/usbboot/boot_usb# ./boot_usb zImage-2.6.16.13-ezx3-32mb-p1 E2/A1200/E6 found. TX: RQSN ( 02 52 51 53 4e 03) TX: RQVN ( 02 52 51 56 4e 03) TX: ADDRA0DEBA ( 02 41 44 44 52 1e 41 30 44 45 30 30 30 30 42 41 03) TX: JUMPA0DEBA ( 02 4a 55 4d 50 1e 41 30 44 45 30 30 30 30 42 41 03) yo quiero I'm learning how ti works because i want to put a kernel with SDHC support in my rokr Thanks sorry for buggin you by email. -- Pablo PDA http://www.pablopda.com.ar/blog ---End Message---
Re: AP -- BP Problem
On Tue, Jan 16, 2007 at 10:42:39PM +0800, 王永来 wrote: Hello I want to write a new driver for PCAP, For which kernel are you writing that new driver, and why? Have you seen the 2.6.x driver that I implemented for the -ezx kernel series? but as I read the PCAP registors,I just got zeros,so I guess that BP and PCAP was powerof. No, there must be some software problem. The PXA cannot be running while the PCAP is powered off, that would be a contradiction of terms. -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) signature.asc Description: Digital signature
boot_usb and A1200
Hi Stefan! This is just a short notice that I was able to successfully boot a kernel image on the A1200 using your latest boot_usb modifications. Cheers, -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) signature.asc Description: Digital signature
Re: tapisrv command set
On Mon, Dec 18, 2006 at 02:38:48PM +0100, Florent THIERY wrote: In fact i'm realizing that a lot of listed commands (on the wiki) aren't described in the pdf file. Which is about the G24: http://www.avnet.co.za/New_Products/Motorola/GSM/g24/g24_Module.htm I can add generic information, in order to add a human readable explanation of a related command set, assuming that the command is the same for EZX. ex: AT+CCWA: AT+CCWA=1,%d,1 AT+CCWA=,2 AT+CCWA:%8D,%8D This command controls the Call Waiting supplementary service, including settings and querying of the network. When the Call Waiting indication is enabled and there is a waiting call, a +CCWA: indication is sent from the BP to the AP. The questions are: - how verbose should i go? - what if it's only G24 specific info? please don't copy / re-phrase commands that are specified in GSM TS 07.07 (such +CCWA). -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) signature.asc Description: Digital signature
Re: Rokr E2 JTag Lines (Update)
On Mon, Oct 30, 2006 at 04:44:12PM -0800, Justin Treon wrote: The male connector that you will need to access the port without soldering under a microscope is QT500166-L020-9F. I have yet to find out where to get the part from. Did you succeed in obtaining samples of that Foxconn part so far? I have (jut today, sorry for the delay) asked some friends to try to locate a source of samples of that connector. Ordering the regular minimum quantity of 1,500 units is just a bit too much... but getting samples should be easy for some existing [large] Foxconn customer. Cheers, -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) signature.asc Description: Digital signature
Re: AP-BP comms
On Wed, Dec 13, 2006 at 10:50:42PM +0100, Jeremy Lainé wrote: - From what I have seen so far, the AT commands used on the /dev/mux* device are pretty standard. The response format seem to be somewhat extended (for instance you get NO CARRIER : call_id instead of a plain NO CARRIER). I would say they are about 50:50. Half are compliant to GSM 07.07, but there are many proprietary extensions and modifications. Anything call related seems more or less standards compliant, but anything related to the specific hardware is proprietary. And it's those hardware related bits that are relevant for getting our own kernel (or any 100% free software) running on the AP. -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) signature.asc Description: Digital signature
accounts on openezx.org (was Re: Patchset for 2.4.20 from motorola.)
On Wed, Dec 13, 2006 at 11:39:24AM +0100, Stefan Schmidt wrote: On the other hand you can get an dev account as well. At the moment only Harald can give dev accounts. Stefan, I've added your key to [EMAIL PROTECTED], now you can create accounts (among other things), too. -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) signature.asc Description: Digital signature
