On Sat, Oct 6, 2012 at 11:04 AM, Enric Balletbò i Serra <eballetbo@xxxxxxxxx> wrote: > 2012/10/5 Javier Martinez Canillas <martinez.javier@xxxxxxxxx>: >> On Fri, Oct 5, 2012 at 10:10 AM, Thomas Petazzoni >> <thomas.petazzoni@xxxxxxxxxxxxxxxxxx> wrote: >>> >>> On Fri, 5 Oct 2012 09:32:07 +0200, Javier Martinez Canillas wrote: >>> >>>> As Enric said, u-boot has SPL and NAND support for IGEP since >>>> v2012.10-rc1. I just tried kernel a 3.6 with u-boot v2012.10-rc2 and >>>> it works for me. >>> >>> Ok, I'll try this out. >>> >>>> But I agree that the kernel shouldn't do any assumptions about the >>>> bootloader setting correctly the omap mux. Could you please share your >>>> bootloader that makes the kernel to fail (or your IGEP NAND patches on >>>> top of u-boot U-boot 2011.12) so I can reproduce the issue and try to >>>> fix it? >>> >>> Ok, I'm using the X-Loader from git://git.igep.es/pub/scm/x-loader.git, >>> tag v1.4.4-3, on top of which I apply >>> http://git.free-electrons.com/training-materials/plain/lab-data/sysdev/u-boot/x-loader-1.4.4-3-igep-nand-support.patch >>> to add support for the NAND-based IGEPv2 rev6. >>> >>> In terms of U-Boot, I use U-Boot 2011.12, on top of which I apply >>> http://git.free-electrons.com/training-materials/plain/lab-data/sysdev/u-boot/u-boot-2011.12-igep-nand-support.patch >>> to add support for the NAND-based IGEPv2 rev6. >>> >>> To make things easier if you don't need to rebuild those, I've put >>> online pre-built binaries of X-Loader and U-Boot I'm using: >>> http://free-electrons.com/~thomas/pub/igep-serial-problem/. >>> >>> Thanks, >>> >>> Thomas >> >> Perfect, I'll try it and let you know if I find a fix for the issue. >> > > Sorry if someone receives this email twice, I had some problems to > send this email and Mail Delivery Subsystem tells me > that the Delivery to the following recipient has been delayed. > > Also I tried and works for me which make me think that could be a > hardware issue. Please make sure that pins 6, 8 and 9 of the J990 > header are not connected. I'm noticed that some US-to-RS232 converters > had problems with this. If you use the IDC10 to DB9 cable take a look > at this article: > > http://labs.isee.biz/index.php/How_to_setup_the_IDC10_cable > > If it's a hardware issue, then , why it worked before 3.2 ? Well, I'm > not sure, but maybe the mux is different for pins of uart1 that are > connected to J990 and causes the problem. If you see at the schematic > you'll see that J990 > > x - 10 9 - uart1_rx > uart1_tx - 8 7 - x > gnd - 6 5 - gnd > x - 4 3 - uart3_tx > uart3_rx - 2 1 -x > > If you use directly a IDC10-to-DB9 without cutting hires from 6 to 10 > note that : > > - pin 6 of IDC10 is forced to gnd which corresponds to pin 6 of DB9 > which is suposed to be used as DSR (Data Set Ready) > - pin 8 of IDC10 is connected to uart1_tx which corresponds to pin > 8 of DB9 which is suposed to be used as CTS (Clear to Send) > - pin 9 of IDC10 is connected to uart1_rx which corresponds to pin > 9 of DB9 which is suposed to be used as RI (Ring Indicator) > > Regards, > Enric Hello, I've booted latest mainline kernel (0b8e74c6) with Thomas provided pre-built X-Loader and U-Boot binaries and the UART is working fine for me. So, probably is a hardware issue as Enric said. Thomas, if want to test latest U-Boot and in case you missed the discussion, there seems to be a a bug on OMAP3 lowlevel_init and latest U-Boot SPL is not working on OMAP3 SoCs. For now, the workaround is to revert commit 63ee53a7 armv7 cpu_init_crit: Simplify code Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
