Re: ttyO2 broken on IGEPv2 on 3.3, 3.4-rc5 or arm-soc/for-next, working on 3.2
2012/10/5 Javier Martinez Canillas martinez.jav...@gmail.com: On Fri, Oct 5, 2012 at 10:10 AM, Thomas Petazzoni thomas.petazz...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ttyO2 broken on IGEPv2 on 3.3, 3.4-rc5 or arm-soc/for-next, working on 3.2
On Fri, Oct 5, 2012 at 1:08 AM, Kevin Hilman khil...@deeprootsystems.com wrote: Thomas Petazzoni thomas.petazz...@free-electrons.com writes: On Thu, 4 Oct 2012 22:30:58 +0200, Enric Balletbò i Serra wrote: I recently tested kernel 3.6-rc5 and worked for me. Let me check tomorrow kernel 3.6. Which u-boot version are you using? 2011.12 + a few patches to make the NAND of the IGEPv2 rev6 work. Let me try to build a recent U-Boot (which now includes the SPL for the IGEP) and see if it improves the situation. However, I believe that the rule is that the kernel shouldn't depend too much on initialization done by the bootloader, so it still seems like an issue to me. Correct, if the kernel is relying on any bootloader assumptions, it should be considered a kernel bug. We'd really like to remove any bootloader assumptions from the kernel. This will allow the kernel to be bootloader independent, and make it easier to support reboot via kexec. Kevin Hi Thomas, 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. 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? Thanks a lot and best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ttyO2 broken on IGEPv2 on 3.3, 3.4-rc5 or arm-soc/for-next, working on 3.2
Kevin, On Thu, 04 Oct 2012 16:06:27 -0700, Kevin Hilman wrote: It seems they are exactly the same, unless my eyes missed something, of course. The example I gave was only for the UART3 RX, you should dump the UART3 TX pins as. Using the omap_mux debugfs, you can see all of the potential pins where uart3_tx can be routed: Well, UART3 TX seems to be working fine. Do RX and TX have mutual influence in terms of pin muxing? Yes, that tells me where UART3 is expected to be mux'd on the board. So you can ignore the dss_data* and husb_data* files above and focus on uart3* So to summarize, in /sys/kernel/debug/omap_mux, just do a 'cat uart3*' on a working and non-working board and see if there are any differences. 3.2 (working) name: uart3_cts_rctx.uart3_cts_rctx (0x4800219a/0x16a = 0x0108), b h18, t NA mode: OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE0 signals: uart3_cts_rctx | NA | NA | NA | gpio_163 | NA | NA | safe_mode name: uart3_rts_sd.uart3_rts_sd (0x4800219c/0x16c = 0x), b h19, t NA mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE0 signals: uart3_rts_sd | NA | NA | NA | gpio_164 | NA | NA | safe_mode name: uart3_rx_irrx.uart3_rx_irrx (0x4800219e/0x16e = 0x0100), b h20, t NA mode: OMAP_PIN_INPUT | OMAP_MUX_MODE0 signals: uart3_rx_irrx | NA | NA | NA | gpio_165 | NA | NA | safe_mode name: uart3_tx_irtx.uart3_tx_irtx (0x480021a0/0x170 = 0x), b h21, t NA mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE0 signals: uart3_tx_irtx | NA | NA | NA | gpio_166 | NA | NA | safe_mode 3.6 (not working) name: uart3_cts_rctx.uart3_cts_rctx (0x4800219a/0x16a = 0x0108), b h18, t NA mode: OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE0 signals: uart3_cts_rctx | NA | NA | NA | gpio_163 | NA | NA | safe_mode name: uart3_rts_sd.uart3_rts_sd (0x4800219c/0x16c = 0x), b h19, t NA mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE0 signals: uart3_rts_sd | NA | NA | NA | gpio_164 | NA | NA | safe_mode name: uart3_rx_irrx.uart3_rx_irrx (0x4800219e/0x16e = 0x0100), b h20, t NA mode: OMAP_PIN_INPUT | OMAP_MUX_MODE0 signals: uart3_rx_irrx | NA | NA | NA | gpio_165 | NA | NA | safe_mode name: uart3_tx_irtx.uart3_tx_irtx (0x480021a0/0x170 = 0x), b h21, t NA mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE0 signals: uart3_tx_irtx | NA | NA | NA | gpio_166 | NA | NA | safe_mode Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ttyO2 broken on IGEPv2 on 3.3, 3.4-rc5 or arm-soc/for-next, working on 3.2
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 -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ttyO2 broken on IGEPv2 on 3.3, 3.4-rc5 or arm-soc/for-next, working on 3.2
On Fri, Oct 5, 2012 at 10:10 AM, Thomas Petazzoni thomas.petazz...@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. Thanks a lot! Javier -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ttyO2 broken on IGEPv2 on 3.3, 3.4-rc5 or arm-soc/for-next, working on 3.2
Kevin,
Reviving an old thread.
On Fri, 04 May 2012 16:46:32 -0700, Kevin Hilman wrote:
Thomas Petazzoni thomas.petazz...@free-electrons.com writes:
I have an IGEPv2 revision 6 board, which uses the DM3730 OMAP3.
With 3.2 omap2plus_defconfig, the system boots fine and have a
working shell on ttyO2. On either 3.3, 3.4-rc5 or
arm-soc/for-next from Arnd, the system boots all the way up to
showing the shell prompt, but I can't type any character, as if
UART RX was broken.
On v3.4-rc, can you see if reverting
bce492c04ba8fc66a4ea0a52b181ba255daaaf54 has any effect?
That patch had some unfortunate side effects, but I haven't seen
the problem you see, so I'm not sure if it's related.
Reverting bce492c04ba8fc66a4ea0a52b181ba255daaaf54 is a broken
solution like you mentioned. But if it helps, then the proper fix
is to add muxing to board-*.c files for the uart pins and use
omap_serial_init_port for each uart instead of omap_serial_init.
That should fix the wake-up issues too.
I agree on the final solution, but just wanted to see if the missing
mux (and thus disabled runtime PM) is what's causing the problem.
FWIW, I tried the recently released 3.6 kernel on this platform
(IGEPv2, OMAP3-based), and I still see the same problem. Upon Tony's
suggestion, I tried to add some code in board-igep0020.c similar to the
one in board-n8x0.c to do the appropriate UART2 muxing, but it doesn't
seem to improve the situation. I did the following change (note that I
tried with both .name = uart2_rx_irrx.uart2_rx_irrx and .name =
uart3_rx_irrx.uart3_rx_irrx). On this board, the console is on ttyO2.
This is with the plain omap2plus_defconfig, so CONFIG_OMAP_MUX is
enabled.
Any idea of things to try? This board has been broken since 3.2, so I'd
like to get it fixed at some point :-)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 2821448..568f13e 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -558,6 +558,43 @@ static struct omap_board_mux board_mux[] __initdata = {
OMAP3_MUX(MCSPI1_CS2, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
+
+static struct omap_device_pad serial2_pads[] __initdata = {
+ {
+ .name = uart2_rx_irrx.uart2_rx_irrx,
+ .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
+ .enable = OMAP_MUX_MODE0,
+ .idle = OMAP_MUX_MODE3/* Mux as GPIO for idle */
+ },
+};
+
+static inline void board_serial_init(void)
+{
+ struct omap_board_data bdata;
+
+ bdata.flags = 0;
+ bdata.pads = NULL;
+ bdata.pads_cnt = 0;
+
+ bdata.id = 0;
+ omap_serial_init_port(bdata, NULL);
+
+ bdata.id = 1;
+ omap_serial_init_port(bdata, NULL);
+
+ bdata.id = 2;
+ bdata.pads = serial2_pads;
+ bdata.pads_cnt = ARRAY_SIZE(serial2_pads);
+ omap_serial_init_port(bdata, NULL);
+}
+
+#else
+
+static inline void board_serial_init(void)
+{
+ omap_serial_init();
+}
+
#endif
#if defined(CONFIG_LIBERTAS_SDIO) || defined(CONFIG_LIBERTAS_SDIO_MODULE)
@@ -621,7 +658,7 @@ static void __init igep_init(void)
/* Register I2C busses and drivers */
igep_i2c_init();
platform_add_devices(igep_devices, ARRAY_SIZE(igep_devices));
- omap_serial_init();
+ board_serial_init();
omap_sdrc_init(m65kam_sdrc_params,
m65kam_sdrc_params);
usb_musb_init(NULL);
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ttyO2 broken on IGEPv2 on 3.3, 3.4-rc5 or arm-soc/for-next, working on 3.2
Hi Thomas,
Thomas Petazzoni thomas.petazz...@free-electrons.com writes:
Kevin,
Reviving an old thread.
On Fri, 04 May 2012 16:46:32 -0700, Kevin Hilman wrote:
Thomas Petazzoni thomas.petazz...@free-electrons.com writes:
I have an IGEPv2 revision 6 board, which uses the DM3730 OMAP3.
With 3.2 omap2plus_defconfig, the system boots fine and have a
working shell on ttyO2. On either 3.3, 3.4-rc5 or
arm-soc/for-next from Arnd, the system boots all the way up to
showing the shell prompt, but I can't type any character, as if
UART RX was broken.
On v3.4-rc, can you see if reverting
bce492c04ba8fc66a4ea0a52b181ba255daaaf54 has any effect?
That patch had some unfortunate side effects, but I haven't seen
the problem you see, so I'm not sure if it's related.
Reverting bce492c04ba8fc66a4ea0a52b181ba255daaaf54 is a broken
solution like you mentioned. But if it helps, then the proper fix
is to add muxing to board-*.c files for the uart pins and use
omap_serial_init_port for each uart instead of omap_serial_init.
That should fix the wake-up issues too.
I agree on the final solution, but just wanted to see if the missing
mux (and thus disabled runtime PM) is what's causing the problem.
FWIW, I tried the recently released 3.6 kernel on this platform
(IGEPv2, OMAP3-based), and I still see the same problem. Upon Tony's
suggestion, I tried to add some code in board-igep0020.c similar to the
one in board-n8x0.c to do the appropriate UART2 muxing, but it doesn't
seem to improve the situation. I did the following change (note that I
tried with both .name = uart2_rx_irrx.uart2_rx_irrx and .name =
uart3_rx_irrx.uart3_rx_irrx). On this board, the console is on ttyO2.
This is with the plain omap2plus_defconfig, so CONFIG_OMAP_MUX is
enabled.
Any idea of things to try? This board has been broken since 3.2, so I'd
like to get it fixed at some point :-)
Can you dump the UART mux registers on a working kernel and compare them
to the broken one? (Table 7-4 in the 34xx public TRM[1] will list all
the mux registers.) Maybe the bootloader code for that board will shed
some light as well since it will be setting the muxing too.
If the console uart is ttyO2 (UART3 in TI docs), then the interesting
registers will be any of the padconf registers in that table that
contain 'uart3'. e.g. for UART3 RX:
CONTROL_PADCONF_DSS_DATA4 (mode 2)
CONTROL_PADCONF_UART3_RTS_SD (mode 0)
CONTROL_PADCONF_HSUSB0_DATA1 (mode 2)
omap_mux has some useful debugfs output under debugfs/omap_mux. For
example:
# cd /sys/kernel/debug/omap_mux
# cat dss_data4
# cat uart3_rx_irrx
# cat hsusb0_data1
would provide a very useful comparison between a working kernel and a
non-working one.
Kevin
[1] http://www.ti.com/pdfs/wtbu/OMAP34xx_ES3.1.x_PUBLIC_TRM_vZV.zip
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 2821448..568f13e 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -558,6 +558,43 @@ static struct omap_board_mux board_mux[] __initdata = {
OMAP3_MUX(MCSPI1_CS2, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
+
+static struct omap_device_pad serial2_pads[] __initdata = {
+ {
+ .name = uart2_rx_irrx.uart2_rx_irrx,
+ .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
+ .enable = OMAP_MUX_MODE0,
+ .idle = OMAP_MUX_MODE3/* Mux as GPIO for idle */
+ },
+};
+
+static inline void board_serial_init(void)
+{
+ struct omap_board_data bdata;
+
+ bdata.flags = 0;
+ bdata.pads = NULL;
+ bdata.pads_cnt = 0;
+
+ bdata.id = 0;
+ omap_serial_init_port(bdata, NULL);
+
+ bdata.id = 1;
+ omap_serial_init_port(bdata, NULL);
+
+ bdata.id = 2;
+ bdata.pads = serial2_pads;
+ bdata.pads_cnt = ARRAY_SIZE(serial2_pads);
+ omap_serial_init_port(bdata, NULL);
+}
+
+#else
+
+static inline void board_serial_init(void)
+{
+ omap_serial_init();
+}
+
#endif
#if defined(CONFIG_LIBERTAS_SDIO) || defined(CONFIG_LIBERTAS_SDIO_MODULE)
@@ -621,7 +658,7 @@ static void __init igep_init(void)
/* Register I2C busses and drivers */
igep_i2c_init();
platform_add_devices(igep_devices, ARRAY_SIZE(igep_devices));
- omap_serial_init();
+ board_serial_init();
omap_sdrc_init(m65kam_sdrc_params,
m65kam_sdrc_params);
usb_musb_init(NULL);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ttyO2 broken on IGEPv2 on 3.3, 3.4-rc5 or arm-soc/for-next, working on 3.2
Kevin, On Thu, 04 Oct 2012 10:18:04 -0700, Kevin Hilman wrote: Can you dump the UART mux registers on a working kernel and compare them to the broken one? (Table 7-4 in the 34xx public TRM[1] will list all the mux registers.) Maybe the bootloader code for that board will shed some light as well since it will be setting the muxing too. If the console uart is ttyO2 (UART3 in TI docs), then the interesting registers will be any of the padconf registers in that table that contain 'uart3'. e.g. for UART3 RX: CONTROL_PADCONF_DSS_DATA4 (mode 2) CONTROL_PADCONF_UART3_RTS_SD (mode 0) CONTROL_PADCONF_HSUSB0_DATA1 (mode 2) omap_mux has some useful debugfs output under debugfs/omap_mux. For example: # cd /sys/kernel/debug/omap_mux # cat dss_data4 # cat uart3_rx_irrx # cat hsusb0_data1 would provide a very useful comparison between a working kernel and a non-working one. It seems they are exactly the same, unless my eyes missed something, of course. Note: the 3.6 kernel is booted with the patch I posted earlier, but it doesn't make it work any better. Here is what I have : 3.6 (not working) = name: dss_data4.dss_data4 (0x480020e4/0x0b4 = 0x), b ag24, t NA mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE0 signals: dss_data4 | NA | uart3_rx_irrx | NA | gpio_74 | NA | NA | safe_mode name: uart3_rx_irrx.uart3_rx_irrx (0x4800219e/0x16e = 0x0100), b h20, t NA mode: OMAP_PIN_INPUT | OMAP_MUX_MODE0 signals: uart3_rx_irrx | NA | NA | NA | gpio_165 | NA | NA | safe_mode name: hsusb0_data1.hsusb0_data1 (0x480021ac/0x17c = 0x0100), b u28, t NA mode: OMAP_PIN_INPUT | OMAP_MUX_MODE0 signals: hsusb0_data1 | NA | uart3_rx_irrx | NA | gpio_130 | NA | NA | safe_mode Complete boot log: http://code.bulix.org/76m2kn-82254?raw 3.2 (working) = name: dss_data4.dss_data4 (0x480020e4/0x0b4 = 0x), b ag24, t NA mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE0 signals: dss_data4 | NA | uart3_rx_irrx | NA | gpio_74 | NA | NA | safe_mode name: uart3_rx_irrx.uart3_rx_irrx (0x4800219e/0x16e = 0x0100), b h20, t NA mode: OMAP_PIN_INPUT | OMAP_MUX_MODE0 signals: uart3_rx_irrx | NA | NA | NA | gpio_165 | NA | NA | safe_mode name: hsusb0_data1.hsusb0_data1 (0x480021ac/0x17c = 0x0100), b u28, t NA mode: OMAP_PIN_INPUT | OMAP_MUX_MODE0 signals: hsusb0_data1 | NA | uart3_rx_irrx | NA | gpio_130 | NA | NA | safe_mode Complete boot log: http://code.bulix.org/kh0v71-82255?raw Regarding the bootloader, I am not 100% sure what are the relevant bits, but the UART3 related muxing for this board, done in U-Boot seems to be: MUX_VAL(CP(UART3_TX_IRTX), (IDIS | PTD | DIS | M0)) /* UART3_TX */\ MUX_VAL(CP(UART3_RX_IRRX), (IEN | PTD | DIS | M0)) /* UART3_RX */\ Does this helps? Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ttyO2 broken on IGEPv2 on 3.3, 3.4-rc5 or arm-soc/for-next, working on 3.2
On Thu, 4 Oct 2012 22:30:58 +0200, Enric Balletbò i Serra wrote: I recently tested kernel 3.6-rc5 and worked for me. Let me check tomorrow kernel 3.6. Which u-boot version are you using? 2011.12 + a few patches to make the NAND of the IGEPv2 rev6 work. Let me try to build a recent U-Boot (which now includes the SPL for the IGEP) and see if it improves the situation. However, I believe that the rule is that the kernel shouldn't depend too much on initialization done by the bootloader, so it still seems like an issue to me. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ttyO2 broken on IGEPv2 on 3.3, 3.4-rc5 or arm-soc/for-next, working on 3.2
Thomas Petazzoni thomas.petazz...@free-electrons.com writes: Kevin, On Thu, 04 Oct 2012 10:18:04 -0700, Kevin Hilman wrote: Can you dump the UART mux registers on a working kernel and compare them to the broken one? (Table 7-4 in the 34xx public TRM[1] will list all the mux registers.) Maybe the bootloader code for that board will shed some light as well since it will be setting the muxing too. If the console uart is ttyO2 (UART3 in TI docs), then the interesting registers will be any of the padconf registers in that table that contain 'uart3'. e.g. for UART3 RX: CONTROL_PADCONF_DSS_DATA4 (mode 2) CONTROL_PADCONF_UART3_RTS_SD (mode 0) CONTROL_PADCONF_HSUSB0_DATA1 (mode 2) omap_mux has some useful debugfs output under debugfs/omap_mux. For example: # cd /sys/kernel/debug/omap_mux # cat dss_data4 # cat uart3_rx_irrx # cat hsusb0_data1 would provide a very useful comparison between a working kernel and a non-working one. It seems they are exactly the same, unless my eyes missed something, of course. The example I gave was only for the UART3 RX, you should dump the UART3 TX pins as. Using the omap_mux debugfs, you can see all of the potential pins where uart3_tx can be routed: # cd /sys/kernel/debug/omap_mux # grep -H uart3_tx * |grep signal dss_data5:signals: dss_data5 | NA | uart3_tx_irtx | NA | gpio_75 | NA | NA | safe_mode hsusb0_data0:signals: hsusb0_data0 | NA | uart3_tx_irtx | NA | gpio_125 | NA | NA | safe_mode uart3_tx_irtx:signals: uart3_tx_irtx | NA | NA | NA | gpio_166 | NA | NA | safe_mode So a 'cat' on dss_data, hsusb0_data0 and uart3_tx_irtx on a working an non-working kernel should point us in the right direction (assuming of course, that it's acutally a muxing problem that we're after.) [...] Regarding the bootloader, I am not 100% sure what are the relevant bits, but the UART3 related muxing for this board, done in U-Boot seems to be: MUX_VAL(CP(UART3_TX_IRTX), (IDIS | PTD | DIS | M0)) /* UART3_TX */\ MUX_VAL(CP(UART3_RX_IRRX), (IEN | PTD | DIS | M0)) /* UART3_RX */\ Does this helps? Yes, that tells me where UART3 is expected to be mux'd on the board. So you can ignore the dss_data* and husb_data* files above and focus on uart3* So to summarize, in /sys/kernel/debug/omap_mux, just do a 'cat uart3*' on a working and non-working board and see if there are any differences. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ttyO2 broken on IGEPv2 on 3.3, 3.4-rc5 or arm-soc/for-next, working on 3.2
Thomas Petazzoni thomas.petazz...@free-electrons.com writes: On Thu, 4 Oct 2012 22:30:58 +0200, Enric Balletbò i Serra wrote: I recently tested kernel 3.6-rc5 and worked for me. Let me check tomorrow kernel 3.6. Which u-boot version are you using? 2011.12 + a few patches to make the NAND of the IGEPv2 rev6 work. Let me try to build a recent U-Boot (which now includes the SPL for the IGEP) and see if it improves the situation. However, I believe that the rule is that the kernel shouldn't depend too much on initialization done by the bootloader, so it still seems like an issue to me. Correct, if the kernel is relying on any bootloader assumptions, it should be considered a kernel bug. We'd really like to remove any bootloader assumptions from the kernel. This will allow the kernel to be bootloader independent, and make it easier to support reboot via kexec. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
ttyO2 broken on IGEPv2 on 3.3, 3.4-rc5 or arm-soc/for-next, working on 3.2
Hello, I have an IGEPv2 revision 6 board, which uses the DM3730 OMAP3. With 3.2 omap2plus_defconfig, the system boots fine and have a working shell on ttyO2. On either 3.3, 3.4-rc5 or arm-soc/for-next from Arnd, the system boots all the way up to showing the shell prompt, but I can't type any character, as if UART RX was broken. All the kernel versions have been tested with identical bootloaders and identical setup, so there is apparently no misconfiguration of my serial terminal program regarding flow control or things like that. I have seen that there has been multiple changes to the OMAP UART code between 3.2 and 3.3, but a git bisect attempt has failed miserably due to numerous build issues in the OMAP code at various points of the bisection. I am attaching the boot logs for 3.2 (working), 3.3 (not working) and 3.4-rc5 (not working) in case this is of any help. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0 [0.00] Linux version 3.2.0-2-g7892880 (thomas@skate) (gcc version 4.5.2 (Sourcery G++ Lite 2011.03-41) ) #4 SMP Fri May 4 14:24:20 CEST 2012 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: IGEP v2 board [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] OMAP3630 ES1.2 (l2cache iva sgx neon isp 192mhz_clk ) [0.00] Clocking rate (Crystal/Core/MPU): 26.0/200/600 MHz [0.00] PERCPU: Embedded 8 pages/cpu @c103d000 s10112 r8192 d14464 u32768 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048 [0.00] Kernel command line: init=/bin/sh mtdparts=omap2-nand.0:6m(boot),6m(rootfs) rootfstype=jffs2 root=/dev/mtdblock1 console=ttyO2,115200 [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes) [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Memory: 512MB = 512MB total [0.00] Memory: 507236k/507236k available, 17052k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xe080 - 0xf800 ( 376 MB) [0.00] lowmem : 0xc000 - 0xe000 ( 512 MB) [0.00] modules : 0xbf00 - 0xc000 ( 16 MB) [0.00] .text : 0xc0008000 - 0xc060b388 (6157 kB) [0.00] .init : 0xc060c000 - 0xc0658780 ( 306 kB) [0.00] .data : 0xc065a000 - 0xc06e0970 ( 539 kB) [0.00].bss : 0xc06e0994 - 0xc0c34f20 (5458 kB) [0.00] Hierarchical RCU implementation. [0.00] NR_IRQS:410 [0.00] IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts [0.00] Total of 96 interrupts on 1 active controller [0.00] OMAP clockevent source: GPTIMER1 at 32768 Hz [0.00] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms [0.00] Console: colour dummy device 80x30 [0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.00] ... MAX_LOCKDEP_SUBCLASSES: 8 [0.00] ... MAX_LOCK_DEPTH: 48 [0.00] ... MAX_LOCKDEP_KEYS:8191 [0.00] ... CLASSHASH_SIZE: 4096 [0.00] ... MAX_LOCKDEP_ENTRIES: 16384 [0.00] ... MAX_LOCKDEP_CHAINS: 32768 [0.00] ... CHAINHASH_SIZE: 16384 [0.00] memory used by lock dependency info: 3695 kB [0.00] per task-struct memory footprint: 1152 bytes [0.001068] Calibrating delay loop... 597.64 BogoMIPS (lpj=2334720) [0.085876] pid_max: default: 32768 minimum: 301 [0.086822] Security Framework initialized [0.087188] Mount-cache hash table entries: 512 [0.092681] CPU: Testing write buffer coherency: ok [0.093994] CPU0: thread -1, cpu 0, socket -1, mpidr 0 [0.096527] Brought up 1 CPUs [0.096527] SMP: Total of 1 processors activated (597.64 BogoMIPS). [0.101379] devtmpfs: initialized [0.125549] print_constraints: dummy: [0.128540] NET: Registered protocol family 16 [0.130126] GPMC revision 5.0 [0.148162] OMAP GPIO hardware version 2.5 [0.171112] omap_mux_init: Add partition: #1: core, flags: 0 [0.174163] IGEP2: Hardware Revision C (B-NON compatible) [0.188110] Reprogramming SDRC clock to 2 Hz [0.188140] dpll3_m2_clk rate change failed: -22 [0.189605] IGEP: initializing NAND memory device [0.208648] hw-breakpoint: debug architecture 0x4 unsupported. [
Re: ttyO2 broken on IGEPv2 on 3.3, 3.4-rc5 or arm-soc/for-next, working on 3.2
Hi Thomas, Thomas Petazzoni thomas.petazz...@free-electrons.com writes: I have an IGEPv2 revision 6 board, which uses the DM3730 OMAP3. With 3.2 omap2plus_defconfig, the system boots fine and have a working shell on ttyO2. On either 3.3, 3.4-rc5 or arm-soc/for-next from Arnd, the system boots all the way up to showing the shell prompt, but I can't type any character, as if UART RX was broken. On v3.4-rc, can you see if reverting bce492c04ba8fc66a4ea0a52b181ba255daaaf54 has any effect? That patch had some unfortunate side effects, but I haven't seen the problem you see, so I'm not sure if it's related. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ttyO2 broken on IGEPv2 on 3.3, 3.4-rc5 or arm-soc/for-next, working on 3.2
* Kevin Hilman khil...@ti.com [120504 09:31]: Hi Thomas, Thomas Petazzoni thomas.petazz...@free-electrons.com writes: I have an IGEPv2 revision 6 board, which uses the DM3730 OMAP3. With 3.2 omap2plus_defconfig, the system boots fine and have a working shell on ttyO2. On either 3.3, 3.4-rc5 or arm-soc/for-next from Arnd, the system boots all the way up to showing the shell prompt, but I can't type any character, as if UART RX was broken. On v3.4-rc, can you see if reverting bce492c04ba8fc66a4ea0a52b181ba255daaaf54 has any effect? That patch had some unfortunate side effects, but I haven't seen the problem you see, so I'm not sure if it's related. Reverting bce492c04ba8fc66a4ea0a52b181ba255daaaf54 is a broken solution like you mentioned. But if it helps, then the proper fix is to add muxing to board-*.c files for the uart pins and use omap_serial_init_port for each uart instead of omap_serial_init. That should fix the wake-up issues too. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ttyO2 broken on IGEPv2 on 3.3, 3.4-rc5 or arm-soc/for-next, working on 3.2
Tony Lindgren t...@atomide.com writes: * Kevin Hilman khil...@ti.com [120504 09:31]: Hi Thomas, Thomas Petazzoni thomas.petazz...@free-electrons.com writes: I have an IGEPv2 revision 6 board, which uses the DM3730 OMAP3. With 3.2 omap2plus_defconfig, the system boots fine and have a working shell on ttyO2. On either 3.3, 3.4-rc5 or arm-soc/for-next from Arnd, the system boots all the way up to showing the shell prompt, but I can't type any character, as if UART RX was broken. On v3.4-rc, can you see if reverting bce492c04ba8fc66a4ea0a52b181ba255daaaf54 has any effect? That patch had some unfortunate side effects, but I haven't seen the problem you see, so I'm not sure if it's related. Reverting bce492c04ba8fc66a4ea0a52b181ba255daaaf54 is a broken solution like you mentioned. But if it helps, then the proper fix is to add muxing to board-*.c files for the uart pins and use omap_serial_init_port for each uart instead of omap_serial_init. That should fix the wake-up issues too. I agree on the final solution, but just wanted to see if the missing mux (and thus disabled runtime PM) is what's causing the problem. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
