Re: [OpenWrt-Devel] LANTIQ- EASY5072- UART0 problem
> Hi we solved the problem thanks to your suggestion. However setting of > this reg. has to happen timely!!! > We found that it works if it is written in (backfire r27450): > -- > linux-2.6.30.10/arch/mips/ifxmips/setup.c - OpenWrt Backfire (r27450) > in function plat_time_init > printk("Enabling UART_0 via PWDCR\n"); > ifxmips_pmu_enable(IFXMIPS_PMU_PWDCR_UART_0); > > > linux-2.6.30.10/arch/mips/include/asm/mach-ifxmips/ifxmips_pmu.h > #define IFXMIPS_PMU_PWDCR_UART_0 0x0080 > - > > You need also to do in linux-2.6.30.10/drivers/leds/leds-ifxmips.c: > -- > ifxmips_port_set_altsel0(IFXMIPS_LED_GPIO_PORT, 11); > ifxmips_port_clear_altsel1(IFXMIPS_LED_GPIO_PORT, 11); > ifxmips_port_set_dir_in(IFXMIPS_LED_GPIO_PORT, 11); > ifxmips_port_clear_open_drain(IFXMIPS_LED_GPIO_PORT, 11); > ifxmips_port_set_puden(IFXMIPS_LED_GPIO_PORT, 11); > ifxmips_port_set_pudsel(IFXMIPS_LED_GPIO_PORT, 11); > ifxmips_port_set_altsel0(IFXMIPS_LED_GPIO_PORT, 12); > ifxmips_port_clear_altsel1(IFXMIPS_LED_GPIO_PORT, 12); > ifxmips_port_set_dir_out(IFXMIPS_LED_GPIO_PORT, 12); > ifxmips_port_set_open_drain(IFXMIPS_LED_GPIO_PORT, 12); > ifxmips_port_clear_puden(IFXMIPS_LED_GPIO_PORT, 12); > - > Spyros thanks i will rebase this and merge it in the upstream queue ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] LANTIQ- EASY5072- UART0 problem
On 24/3/2012 7:01 μμ, Conor O'Gorman wrote: On Thu, 2012-03-22 at 18:44 +0100, John Crispin wrote: On 22/03/12 17:48, Spyridon Tompros wrote: As a workaround We've tried to implement another USB port by using an external Vinculum VNC1L Chip. It works connected to a serial port. The problem we encounter now is that the UART0 port of the Danube seems dead We discovered that even if we write the respective register (MCON), it remains incactive. Moreover we've tried to include the UART0 as console from the make menuconfig util and the result was the same. Has anybody activated the second serial port of Danube? Hi, It has worked in the past, but i have not tried it in a while, i have a twinpass baord with 2 serial ports and will add this on my todo list for tomorrow Might be a problem in (not) setting the PMU_PWDSR (Power Down Register). UART0 appears to default to off. Might be some CGU actions needed also. Conor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel Hi we solved the problem thanks to your suggestion. However setting of this reg. has to happen timely!!! We found that it works if it is written in (backfire r27450): -- linux-2.6.30.10/arch/mips/ifxmips/setup.c - OpenWrt Backfire (r27450) in function plat_time_init printk("Enabling UART_0 via PWDCR\n"); ifxmips_pmu_enable(IFXMIPS_PMU_PWDCR_UART_0); linux-2.6.30.10/arch/mips/include/asm/mach-ifxmips/ifxmips_pmu.h #define IFXMIPS_PMU_PWDCR_UART_0 0x0080 - You need also to do in linux-2.6.30.10/drivers/leds/leds-ifxmips.c: -- ifxmips_port_set_altsel0(IFXMIPS_LED_GPIO_PORT, 11); ifxmips_port_clear_altsel1(IFXMIPS_LED_GPIO_PORT, 11); ifxmips_port_set_dir_in(IFXMIPS_LED_GPIO_PORT, 11); ifxmips_port_clear_open_drain(IFXMIPS_LED_GPIO_PORT, 11); ifxmips_port_set_puden(IFXMIPS_LED_GPIO_PORT, 11); ifxmips_port_set_pudsel(IFXMIPS_LED_GPIO_PORT, 11); ifxmips_port_set_altsel0(IFXMIPS_LED_GPIO_PORT, 12); ifxmips_port_clear_altsel1(IFXMIPS_LED_GPIO_PORT, 12); ifxmips_port_set_dir_out(IFXMIPS_LED_GPIO_PORT, 12); ifxmips_port_set_open_drain(IFXMIPS_LED_GPIO_PORT, 12); ifxmips_port_clear_puden(IFXMIPS_LED_GPIO_PORT, 12); - Spyros ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] LANTIQ- EASY5072- UART0 problem
Also as bluetooth i/f. It is correct according to the evaliuation board schematics, but it must be used also as spare general purpose UART. We've initiated the blutooth support from the menuconfig hoping that this would wake up UART0, but finally it did not work. Spyros On 24/3/2012 7:04 μμ, simon h wrote: The BT Homehub V2B uses the second port by default. The first port appears to be used for DECT communication. On Sat, Mar 24, 2012 at 6:01 PM, Conor O'Gorman wrote: On Thu, 2012-03-22 at 18:44 +0100, John Crispin wrote: On 22/03/12 17:48, Spyridon Tompros wrote: As a workaround We've tried to implement another USB port by using an external Vinculum VNC1L Chip. It works connected to a serial port. The problem we encounter now is that the UART0 port of the Danube seems dead We discovered that even if we write the respective register (MCON), it remains incactive. Moreover we've tried to include the UART0 as console from the make menuconfig util and the result was the same. Has anybody activated the second serial port of Danube? Hi, It has worked in the past, but i have not tried it in a while, i have a twinpass baord with 2 serial ports and will add this on my todo list for tomorrow Might be a problem in (not) setting the PMU_PWDSR (Power Down Register). UART0 appears to default to off. Might be some CGU actions needed also. Conor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Best Regards, Spyridon Tompros Dr. Ing. Spyridon Tompros 36 GE Lebon, 1160 Brussels tel:+322.5133076 www.qualtek.eu ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] LANTIQ- EASY5072- UART0 problem
The BT Homehub V2B uses the second port by default. The first port appears to be used for DECT communication. On Sat, Mar 24, 2012 at 6:01 PM, Conor O'Gorman wrote: > On Thu, 2012-03-22 at 18:44 +0100, John Crispin wrote: >> On 22/03/12 17:48, Spyridon Tompros wrote: >> > As a workaround We've tried to implement another USB port by using an >> > external Vinculum VNC1L Chip. It works connected to a serial port. The >> > problem we encounter now is that the UART0 port of the Danube seems >> > dead We discovered that even if we write the respective register >> > (MCON), it remains incactive. Moreover we've tried to include the UART0 >> > as console from the make menuconfig util and the result was the same. >> > >> > Has anybody activated the second serial port of Danube? >> >> >> Hi, >> >> It has worked in the past, but i have not tried it in a while, i have a >> twinpass baord with 2 serial ports and will add this on my todo list for >> tomorrow >> > > Might be a problem in (not) setting the PMU_PWDSR (Power Down Register). > UART0 appears to default to off. Might be some CGU actions needed also. > > Conor > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] LANTIQ- EASY5072- UART0 problem
On Thu, 2012-03-22 at 18:44 +0100, John Crispin wrote: > On 22/03/12 17:48, Spyridon Tompros wrote: > > As a workaround We've tried to implement another USB port by using an > > external Vinculum VNC1L Chip. It works connected to a serial port. The > > problem we encounter now is that the UART0 port of the Danube seems > > dead We discovered that even if we write the respective register > > (MCON), it remains incactive. Moreover we've tried to include the UART0 > > as console from the make menuconfig util and the result was the same. > > > > Has anybody activated the second serial port of Danube? > > > Hi, > > It has worked in the past, but i have not tried it in a while, i have a > twinpass baord with 2 serial ports and will add this on my todo list for > tomorrow > Might be a problem in (not) setting the PMU_PWDSR (Power Down Register). UART0 appears to default to off. Might be some CGU actions needed also. Conor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] LANTIQ- EASY5072- UART0 problem
Hi, On Fri, Mar 23, 2012 at 07:39:19PM +0100, openwrt-devel-requ...@lists.openwrt.org wrote: > Message: 2 > Date: Fri, 23 Mar 2012 18:00:18 +0100 > From: Spyridon Tompros > To: openwrt-devel@lists.openwrt.org > Subject: Re: [OpenWrt-Devel] LANTIQ- EASY5072- UART0 problem > Message-ID: <4f6cac22.6030...@qualtek.eu> > Content-Type: text/plain; charset=UTF-8; format=flowed > > If the problem is HW it cannot become better anymore. Extra dumb question: perhaps it would be doable to have some playful experiments with some ferrite:ish cover layers near affected traces? (not sure whether there would be any effect at such scale, but without trying there's no knowledge...) Given that the PCB's layout is completely broken already, matters probably cannot get worse :) Disclaimer: _not_ an experienced EDA engineer here :) Andreas Mohr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] LANTIQ- EASY5072- UART0 problem
If the problem is HW it cannot become better anymore. In case you plan to do a new board, find below some rules for your HW design (not fully respected by us in our board). The evaluation board respects them: -Differential signals length less than 1inch -Same trace length and width -Ground planes on solder and component screen around the traces -Avoid vias -don't route under oscillators Spyros On 23/3/2012 5:33 μμ, Conor O'Gorman wrote: On Fri, 2012-03-23 at 17:24 +0100, Spyridon Tompros wrote: Some additional info: Do you have a proprietary board or an EASY50712 evaluation board? We have both and on the EASY board we do not see any errors any more. On the proprietary board we encounter some at high rates, that's why I believe it is a matter of traces routing. Eventually the USB I/F is the most high bit rate of all, therefore routing of its differential signals must be done very carefully. Proprietary board also. If you build the driver in debug mode I think it reports these error stats. The error reported for us, is Transaction Error (XactErr). Of all the errors this looks like a bit/data/crc type error. I intended to do an eye-diagram test, but it hasn't been done yet. As you say, high speed usb is the highest speed signal. I did turn on the option to operate at 12 Mbps. But after the fix, I didn't see much difference, and we need the higher speed for newest 3G modems. Conor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Best Regards, Spyridon Tompros Dr. Ing. Spyridon Tompros 36 GE Lebon, 1160 Brussels tel:+322.5133076 www.qualtek.eu ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] LANTIQ- EASY5072- UART0 problem
On Fri, 2012-03-23 at 17:24 +0100, Spyridon Tompros wrote: > Some additional info: > Do you have a proprietary board or an EASY50712 evaluation board? > We have both and on the EASY board we do not see any errors any more. On > the proprietary board we encounter some at high rates, that's why I > believe it is a matter of traces routing. > Eventually the USB I/F is the most high bit rate of all, therefore > routing of its differential signals must be done very carefully. Proprietary board also. If you build the driver in debug mode I think it reports these error stats. The error reported for us, is Transaction Error (XactErr). Of all the errors this looks like a bit/data/crc type error. I intended to do an eye-diagram test, but it hasn't been done yet. As you say, high speed usb is the highest speed signal. I did turn on the option to operate at 12 Mbps. But after the fix, I didn't see much difference, and we need the higher speed for newest 3G modems. Conor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] LANTIQ- EASY5072- UART0 problem
Some additional info: Do you have a proprietary board or an EASY50712 evaluation board? We have both and on the EASY board we do not see any errors any more. On the proprietary board we encounter some at high rates, that's why I believe it is a matter of traces routing. Eventually the USB I/F is the most high bit rate of all, therefore routing of its differential signals must be done very carefully. Spyros On 23/3/2012 5:11 μμ, Spyridon Tompros wrote: Yes, I have the same impression about the errors. We need to test again in detail all speed modes to get a better overview, but the system works fine. If there is a higher layer protocol that supports flow control then this bit error rate is practically nothing. Spyros On 23/3/2012 4:07 μμ, Conor O'Gorman wrote: On Fri, 2012-03-23 at 15:41 +0100, Spyridon Tompros wrote: Hi, We tested the code on our board. Now the USB host controller functionality works almost perfect, with some losses at very high rates (921600), while it does not crash any more nor with use-to-serial USB or other media devices. Thanks a lot, Spyros Good to hear, I spent a couple of days tracing the behaviour, and was happy to find it to be a one line fix. That in-appropriate halt_channel() call was causing cross-connecting references as I recall. I also still see some errors, but it seems to recover from them. I assumed they are due to random glitches/errors on the hardware lines. Conor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Best Regards, Spyridon Tompros Dr. Ing. Spyridon Tompros 36 GE Lebon, 1160 Brussels tel:+322.5133076 www.qualtek.eu ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] LANTIQ- EASY5072- UART0 problem
Yes, I have the same impression about the errors. We need to test again in detail all speed modes to get a better overview, but the system works fine. If there is a higher layer protocol that supports flow control then this bit error rate is practically nothing. Spyros On 23/3/2012 4:07 μμ, Conor O'Gorman wrote: On Fri, 2012-03-23 at 15:41 +0100, Spyridon Tompros wrote: Hi, We tested the code on our board. Now the USB host controller functionality works almost perfect, with some losses at very high rates (921600), while it does not crash any more nor with use-to-serial USB or other media devices. Thanks a lot, Spyros Good to hear, I spent a couple of days tracing the behaviour, and was happy to find it to be a one line fix. That in-appropriate halt_channel() call was causing cross-connecting references as I recall. I also still see some errors, but it seems to recover from them. I assumed they are due to random glitches/errors on the hardware lines. Conor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Best Regards, Spyridon Tompros Dr. Ing. Spyridon Tompros 36 GE Lebon, 1160 Brussels tel:+322.5133076 www.qualtek.eu ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] LANTIQ- EASY5072- UART0 problem
On Fri, 2012-03-23 at 15:41 +0100, Spyridon Tompros wrote: > Hi, > > We tested the code on our board. Now the USB host controller > functionality works almost perfect, with some losses at very high rates > (921600), while it does not crash any more nor with use-to-serial USB or > other media devices. > > Thanks a lot, > Spyros > Good to hear, I spent a couple of days tracing the behaviour, and was happy to find it to be a one line fix. That in-appropriate halt_channel() call was causing cross-connecting references as I recall. I also still see some errors, but it seems to recover from them. I assumed they are due to random glitches/errors on the hardware lines. Conor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] LANTIQ- EASY5072- UART0 problem
On 23/03/12 15:50, Spyridon Tompros wrote: > Thanks, > > we are also missing UART0, which does not work despite following the > right programming sequense documented in the Users' Manual. We are still > working on it. I do not know if there is any code available. > > Spyros > still looking into it myself ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] LANTIQ- EASY5072- UART0 problem
Thanks, we are also missing UART0, which does not work despite following the right programming sequense documented in the Users' Manual. We are still working on it. I do not know if there is any code available. Spyros On 23/3/2012 3:45 μμ, John Crispin wrote: Hi, Ok, i will add this patch to the upcoming kernel update John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Best Regards, Spyridon Tompros Dr. Ing. Spyridon Tompros 36 GE Lebon, 1160 Brussels tel:+322.5133076 www.qualtek.eu ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] LANTIQ- EASY5072- UART0 problem
Hi, Ok, i will add this patch to the upcoming kernel update John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] LANTIQ- EASY5072- UART0 problem
Hi, We tested the code on our board. Now the USB host controller functionality works almost perfect, with some losses at very high rates (921600), while it does not crash any more nor with use-to-serial USB or other media devices. Thanks a lot, Spyros On 22/3/2012 9:12 μμ, Conor O'Gorman wrote: On Thu, 2012-03-22 at 17:48 +0100, Spyridon Tompros wrote: We have tested the following the following USB drivers provided with the latest openwrt/trunk version (downloaded yesterday): -Kmod-usb-core -Kmod-usb2 -Kmod-serial-to-usb In all cases we observe lost packets when sending files to a PC and receiving them back. Some times the kernel crashes, while crashes happen always when we try to physically connect a USB HUB or a media USB device. I saw improvements in native danube usb behaviour with this change: +++ b/drivers/usb/dwc_otg/dwc_otg_hcd_intr.c -@@ -0,0 +1,1841 @@ +@@ -0,0 +1,1839 @@ +/* == + * $File: //dwh/usb_iip/dev/software/otg_ipmate/linux/drivers/dwc_otg_hcd_intr.c $ + * $Revision: 1.1.1.1 $ @@ -11891,8 +11891,6 @@ + * automatically executes the PING, then the transfer. + */ + halt_channel(_hcd, _hc, _qtd, DWC_OTG_HC_XFER_ACK, must_free); -+ } else { -+ halt_channel(_hcd, _hc, _qtd, _hc->halt_status, must_free); + } + } + ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Best Regards, Spyridon Tompros Dr. Ing. Spyridon Tompros 36 GE Lebon, 1160 Brussels tel:+322.5133076 www.qualtek.eu ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] LANTIQ- EASY5072- UART0 problem
On Thu, 2012-03-22 at 17:48 +0100, Spyridon Tompros wrote: > We have tested the following the following USB drivers provided with the > latest openwrt/trunk version (downloaded yesterday): > -Kmod-usb-core > -Kmod-usb2 > -Kmod-serial-to-usb > > In all cases we observe lost packets when sending files to a PC and > receiving them back. Some times the kernel crashes, while crashes happen > always when we try to physically connect a USB HUB or a media USB device. > I saw improvements in native danube usb behaviour with this change: +++ b/drivers/usb/dwc_otg/dwc_otg_hcd_intr.c -@@ -0,0 +1,1841 @@ +@@ -0,0 +1,1839 @@ +/* == + * $File: //dwh/usb_iip/dev/software/otg_ipmate/linux/drivers/dwc_otg_hcd_intr.c $ + * $Revision: 1.1.1.1 $ @@ -11891,8 +11891,6 @@ + * automatically executes the PING, then the transfer. + */ + halt_channel(_hcd, _hc, _qtd, DWC_OTG_HC_XFER_ACK, must_free); -+ } else { -+ halt_channel(_hcd, _hc, _qtd, _hc->halt_status, must_free); + } + } + ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] LANTIQ- EASY5072- UART0 problem
Hi, thanks a lot for the support. Spyros On 22/3/2012 6:44 μμ, John Crispin wrote: On 22/03/12 17:48, Spyridon Tompros wrote: Dear all, we have been using OpenWRT on Lantiq's evaluation board with the following details. Target Lantiq GPON/XWAY Subtarget Danube Target Profile (EASY50712) We have tested the following the following USB drivers provided with the latest openwrt/trunk version (downloaded yesterday): -Kmod-usb-core -Kmod-usb2 -Kmod-serial-to-usb In all cases we observe lost packets when sending files to a PC and receiving them back. Some times the kernel crashes, while crashes happen always when we try to physically connect a USB HUB or a media USB device. As a workaround We've tried to implement another USB port by using an external Vinculum VNC1L Chip. It works connected to a serial port. The problem we encounter now is that the UART0 port of the Danube seems dead We discovered that even if we write the respective register (MCON), it remains incactive. Moreover we've tried to include the UART0 as console from the make menuconfig util and the result was the same. Has anybody activated the second serial port of Danube? Hi, It has worked in the past, but i have not tried it in a while, i have a twinpass baord with 2 serial ports and will add this on my todo list for tomorrow John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Best Regards, Spyridon Tompros Dr. Ing. Spyridon Tompros 36 GE Lebon, 1160 Brussels tel:+322.5133076 www.qualtek.eu ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] LANTIQ- EASY5072- UART0 problem
On 22/03/12 17:48, Spyridon Tompros wrote: > Dear all, > > we have been using OpenWRT on Lantiq's evaluation board with the > following details. > Target Lantiq GPON/XWAY > Subtarget Danube > Target Profile (EASY50712) > > We have tested the following the following USB drivers provided with the > latest openwrt/trunk version (downloaded yesterday): > -Kmod-usb-core > -Kmod-usb2 > -Kmod-serial-to-usb > > In all cases we observe lost packets when sending files to a PC and > receiving them back. Some times the kernel crashes, while crashes happen > always when we try to physically connect a USB HUB or a media USB device. > > > As a workaround We've tried to implement another USB port by using an > external Vinculum VNC1L Chip. It works connected to a serial port. The > problem we encounter now is that the UART0 port of the Danube seems > dead We discovered that even if we write the respective register > (MCON), it remains incactive. Moreover we've tried to include the UART0 > as console from the make menuconfig util and the result was the same. > > Has anybody activated the second serial port of Danube? Hi, It has worked in the past, but i have not tried it in a while, i have a twinpass baord with 2 serial ports and will add this on my todo list for tomorrow John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] LANTIQ- EASY5072- UART0 problem
Dear all, we have been using OpenWRT on Lantiq's evaluation board with the following details. Target Lantiq GPON/XWAY Subtarget Danube Target Profile (EASY50712) We have tested the following the following USB drivers provided with the latest openwrt/trunk version (downloaded yesterday): -Kmod-usb-core -Kmod-usb2 -Kmod-serial-to-usb In all cases we observe lost packets when sending files to a PC and receiving them back. Some times the kernel crashes, while crashes happen always when we try to physically connect a USB HUB or a media USB device. As a workaround We've tried to implement another USB port by using an external Vinculum VNC1L Chip. It works connected to a serial port. The problem we encounter now is that the UART0 port of the Danube seems dead We discovered that even if we write the respective register (MCON), it remains incactive. Moreover we've tried to include the UART0 as console from the make menuconfig util and the result was the same. Has anybody activated the second serial port of Danube? Thanks, ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel