Re: ttyO2 broken on IGEPv2 on 3.3, 3.4-rc5 or arm-soc/for-next, working on 3.2

[Javier Martinez Canillas <martinez.javier@gmail.com>]

On Sat, Oct 6, 2012 at 11:04 AM, Enric Balletbò i Serra
<eballetbo@gmail.com> wrote:
> 2012/10/5 Javier Martinez Canillas <martinez.javier@gmail.com>:
>> On Fri, Oct 5, 2012 at 10:10 AM, Thomas Petazzoni
>> <thomas.petazzoni@free-electrons.com> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html