Re: A910 and boot_usb
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Antonio Ospite wrote: Daniel Ribeiro proposed to move GPIO definitions to ezx-phone.c, what about factoring out the common definitions in a ezx-common.h and let the different parts go into ezx-phone.h ? Do you have any more thought about this issue? I believe that all gpio configuration should be done on the machine file, and drivers should have no hardcoded gpio assignments. I think that we should NOT configure GPIOs by using a common name and changing its assigned value on a header file (like motorola did, with #ifdefs), or, if i get what you mean, use common names and different header files. I agree with something like GPIOxx_phone_what as it enforces that no drivers will rely on hardcoded gpio configuration (unless the driver is specific to a single phone) Most drivers already get their gpio configuration from a platform_device, PCAP(and childs) is ok, BP handshake is just a matter of moving the platform_device out of ezx.c. EMU will need some (a lot) work, but i think that this is not the case with A910 (no EMU?). And.. Are the new machine ids assigned?? If they are, we could start thinking into merging all the phone.c files back on ezx.c and use the machine_is_* macros to switch configuration at runtime (thats why it is so important that all drivers get GPIO configuration from a platform_device), and use a single kernel on all models. - -- Daniel Ribeiro -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHmRnGw3OYl0G0liQRAga0AKCBEQ0nFNJlzgSuBjtHG0YZIxS6ZwCgha68 YzCaDiEZ0WQr3mCthOBKvzg= =dC8X -END PGP SIGNATURE-
Re: A910 and boot_usb
On Tue, 16 Oct 2007 00:57:36 +, Daniel Gimpelevich wrote: Just tried this one: http://people.openezx.org/wyrm/images/20070930/zImage-2.6.21.4-ezxWM-20070930-a1200 No OpenEZX usplash, unlike the previous ones, and the dmesg text is still green, of course. The first part scrolls by too fast for me to read. What I see is successful recognition of the Bluetooth and USB, but ultimately culminating in: VFS: Cannot open root device mmcblk0p2 or unknown-block(0,0) It obviously panics right after that. OK, I've compiled my own kernel from the patchset in SVN. I added a quickdirty port of support for the model while I was there. This kernel never gets beyond the garbage screen. I have re-uploaded the sources Motorola released here for reference: http://homepage.mac.com/danielg4/R57_G_10.06.48R.zip Here is a patch against the current SVN that reflects what I built: http://homepage.mac.com/danielg4/2066.patch Can someone please take a look to see how obvious what I did wrong might be? Thanks.
Re: A910 and boot_usb
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Gimpelevich wrote: Here is a patch against the current SVN that reflects what I built: http://homepage.mac.com/danielg4/2066.patch Can someone please take a look to see how obvious what I did wrong might be? Thanks. Hi Daniel, I think that what you are doing wrong is using a780 as base for your work, use a1200 instead. May i suggest a different way for adding a910 support? It will make debugging much easier. 1. Start over, apply all patches up to ezx-core.patch. 2. quilt edit ezx-a910.c 3. copy ezx-a1200.c to ezx-a910.c 4. edit ezx-a910.c and s/a1200/a910/ 5. add any gpio assignment you feel necessary to ezx.h, and the Kconfig/Makefile entries for a910. 6. create a defconfig-a910 based on defconfig-1200. 7. quilt refresh. 8. compile and test, continue to 9 if you get a successful boot, fix it (or report to ML) if it doesnt work. 9. copy all a1200-*.patch to a910-*.patch 10. edit all a910-*.patch, s/a1200/a910/ 11. add all a910-*.patch to the series file, after the respective a1200-*.patch reference. 12. quilt push until the next a910-*.patch 13. do any changes you feel necessary to properly support a910. 14. quilt refresh if you changed anything, compile and test. 15. goto 12. The most important thing after step 8 is PCAP, to test if it is working enable the DEBUG macro on ezx-pcap.c, and assure that you are getting valid register reads (no null and/or random values). Please, report your results. Thank you for your work, send me a diff to ezx-core.patch, defconfig-a910, and the a910-*.patch files (in separate files please!) and i will be happy to review/incorporate them. - -- Daniel Ribeiro -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHG/e+w3OYl0G0liQRAuU/AJ0VyJi5Jm6AW5Gnd0j7gKxyYplQ7gCfTEdK P3xD+S5Pdr+/oJdK3gaz1HU= =TrbM -END PGP SIGNATURE-
Re: A910 and boot_usb
On Sun, 21 Oct 2007 22:07:11 -0300, Daniel Ribeiro wrote: Hi Daniel, I think that what you are doing wrong is using a780 as base for your work, use a1200 instead. I'd love to, but there just isn't that much a1200 stuff in SVN. The a910 tarball Motorola released is full of #ifdef's for many different models, including the a780, but when I compare it to the patchset in SVN, those patches seem to make assumptions that development will always be either for the a780 or the e680, without allowances for any of the other models that the Motorola A910 source accommodates. The extent to which I used a780 as a base was that I used the current SVN as a base, putting as much relevant a1200 stuff in as I could see in it. Mostly, the stuff I added comes directly from the Motorola A910 source, and nowhere else. May i suggest a different way for adding a910 support? It will make debugging much easier. 1. Start over, apply all patches up to ezx-core.patch. 2. quilt edit ezx-a910.c 3. copy ezx-a1200.c to ezx-a910.c 4. edit ezx-a910.c and s/a1200/a910/ These four steps seem like complete overkill in contrast to just changing whatever in ezx-a910.c differs from ezx-a1200.c where it matters. I would like to point out again that kernels built for a780 and kernels built for a1200 behave _identically_ on the a910 in every way, so obviously a780/a1200 differences can not at all account for the different behavior of the kernel that I built. 5. add any gpio assignment you feel necessary to ezx.h, and the Kconfig/Makefile entries for a910. I propose simply deleting the ezx.h in SVN and completely replacing it with the ezx.h from the Motorola A910 sources, but with the #ifdef's adjusted. Maybe the ezx.h in the Motorola A1200 sources is even more complete; I haven't looked. Either would be better than what's there. 6. create a defconfig-a910 based on defconfig-1200. 7. quilt refresh. That is exactly where the defconfig-a910 I included came from. I manually put in the edits that make it look more like defconfig-a780 afterward, because defconfig-a1200 had some settings that made no sense for a910 where the analogous lines in defconfig-a780 made more sense. 8. compile and test, continue to 9 if you get a successful boot, fix it (or report to ML) if it doesnt work. Again, this ignores the behavior of a780 and a1200 kernels that I previously observed on the A910. The point of my building a kernel with quickdirty a910-awareness was to see something _different_ to contrast with. Now that that's accomplished, it seems to me that it would be more worthwhile to try to understand what caused the differences than to undo the changes. 9. copy all a1200-*.patch to a910-*.patch 10. edit all a910-*.patch, s/a1200/a910/ 11. add all a910-*.patch to the series file, after the respective a1200-*.patch reference. Good idea, though I think I'll need some more help understanding which parts of that are needed for a boot. 12. quilt push until the next a910-*.patch 13. do any changes you feel necessary to properly support a910. 14. quilt refresh if you changed anything, compile and test. 15. goto 12. The most important thing after step 8 is PCAP, to test if it is working enable the DEBUG macro on ezx-pcap.c, and assure that you are getting valid register reads (no null and/or random values). Please elaborate on how I could monitor those values and/or validate them. Thanks! Please, report your results. Thank you for your work, send me a diff to ezx-core.patch, defconfig-a910, and the a910-*.patch files (in separate files please!) and i will be happy to review/incorporate them. Oh, sorry. Since SVN is used, I simply assumed svn diff was preferable. Using quilt as an extra layer certainly complicates things...
Re: A910 and boot_usb
On Tue, 16 Oct 2007 09:01:07 +0200, Antonio Ospite wrote: This is a good news If the kernel complains about the root device it means the mmc device has been recognized. So it's time for you to buy an addidional MicroSD card and setup userspace software. You can try openmoko but it is mainly for Touchsreen devices so it will not be that fuctional on A910. What ever gave you that idea? I saw no evidence whatsoever in the messages that it was recognized, and the proof is that I non-destructively repartitioned with GNU Parted, creating an ext2 root, and it had no effect.
Re: A910 and boot_usb
On Tue, 16 Oct 2007 11:36:52 -0300, Daniel Ribeiro wrote: Most SD vendors ship the cards with *two* partition tables, one on the card itself, and another on the first partition. GPARTED failed to repartition my card, because it gets confused and uses the second partition table. Just to be sure, use cdisk, and confirm that you have 2 partitions on the card, and not 2 partitions on the first partition. You seem to have that backwards; cfdisk failed to see the partition table, and parted worked.
Re: A910 and boot_usb
On Wed, 06 Jun 2007 11:50:30 +0100, Paulo Marques wrote: Marc Bobillier wrote: * Daniel Ribeiro [2007-06-04 18:10:46 -0300]: A typo broke boot_usb for e2, e6, a1200 and a910. Its fixed on r2025, please try again. It boots now! I get a muticolor garbage screen, then tux logo and scrolling green kernel messages, then panic :-) Next step : booting a 2.6.21 kernel. If you see green text messages you probably have the same problem I have with the ROKR E6: the framebuffer is 18bpp and not 16bpp. You can see a picture of a ROKR E6 booting a 2.6.21 kernel here: http://people.openezx.org/pmarques/pictures/rokr_e6_booting.jpg I already did some changes to the pxafb driver to support 18bpp, but I guess I need to change fbcon to support 18bpp too, as the screen did come up (turned on the backlight), but no text was displayed :( This work is not really ezx specific, so I'll probably be trying to send patches to linux-arm-kernel so that the support for 18bpp gets merged into the upstream kernel, as soon as I get everything working. In #openezx, ao2 told me to try the following two kernels: http://www.angstrom-distribution.org/unstable/images/a780/20071003/zImage-2.6.21.4-ezxdev http://www.angstrom-distribution.org/unstable/images/a1200/20071001/zImage-2.6.21-ezxdev-r23-a1200-20071001092558.bin Both kernels behave identically, and the colors are still off. It's just as Marc Bobillier said, still. Also, the kernel messages are very tiny on the A910's screen.
Re: A910 and boot_usb
* Paulo Marques [2007-06-06 11:50:30 +0100]: If you see green text messages you probably have the same problem I have with the ROKR E6: the framebuffer is 18bpp and not 16bpp. Yes, A910 is 256k colors. -- marc
A910 and boot_usb
Hi all, Here is my attempt at booting a zImage on a A910 : # ./boot_usb zImage-2.6.13-ezx6-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) # boot_usb was downloaded and compiled today, and run as root. Here is lsusb 0.1.12 output with the A910 in bootloader mode : Bus 001 Device 005: ID 22b8:6023 Motorola PCS Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize016 idVendor 0x22b8 Motorola PCS idProduct 0x6023 bcdDevice0.01 iManufacturer 1 iProduct2 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 4 bmAttributes 0xc0 Self Powered MaxPower 10mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 10 bInterfaceProtocol255 iInterface 5 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 regards -- marc
Re: A910 and boot_usb
Sorry, all my fault. A typo broke boot_usb for e2, e6, a1200 and a910. Its fixed on r2025, please try again. 2007/6/4, [EMAIL PROTECTED] [EMAIL PROTECTED]: Hi all, Here is my attempt at booting a zImage on a A910 : # ./boot_usb zImage-2.6.13-ezx6-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) # boot_usb was downloaded and compiled today, and run as root. Here is lsusb 0.1.12 output with the A910 in bootloader mode : Bus 001 Device 005: ID 22b8:6023 Motorola PCS Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize016 idVendor 0x22b8 Motorola PCS idProduct 0x6023 bcdDevice0.01 iManufacturer 1 iProduct2 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 4 bmAttributes 0xc0 Self Powered MaxPower 10mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 10 bInterfaceProtocol255 iInterface 5 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 regards -- marc -- EOF Daniel Ribeiro
