| Message ID | 20121004180747.3b342904@skate (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Thomas, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: > Kevin, > > Reviving an old thread. > > On Fri, 04 May 2012 16:46:32 -0700, Kevin Hilman wrote: > >> >> Thomas Petazzoni <thomas.petazzoni@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(m65kxxxxam_sdrc_params, > m65kxxxxam_sdrc_params); > usb_musb_init(NULL); -- 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
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 = 0x0000), 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 = 0x0000), 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
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 <thomas.petazzoni@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Thomas Petazzoni <thomas.petazzoni@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Oct 5, 2012 at 1:08 AM, Kevin Hilman <khilman@deeprootsystems.com> wrote: > Thomas Petazzoni <thomas.petazzoni@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 = 0x0000), 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 = 0x0000), 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 = 0x0000), 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 = 0x0000), 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
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
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. Thanks a lot! 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
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 -- 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
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
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(m65kxxxxam_sdrc_params, m65kxxxxam_sdrc_params); usb_musb_init(NULL);