Re: [beagleboard] BBB Wireless - uart0 serial debug console failed after upgrade from default Debian 8.6 to Debian 9.4

[Boh Lim Sim]

Hi,

Sorry I am new to this. I could not find my question in the forum
Where can I find it?
Do I need to resend again?

Thanks in advance
Boh Lim

On Wed, Aug 1, 2018 at 6:48 PM,  wrote:

>
> Hi,
>
> I just bought two BBB Wireless boards.
> The default image, Debian version is 8.6 - I am able to use PUTTY for
> serial debug console.
>
> But after I have upgraded to latest Debian version 9.4, my Windows
> Computer Device manager can still detect the serial port, BUT PUTTY for
> serial debug console is NOT responding anymore.
> I use remote SSH to login, and see that ttyO is still enabled
> # dmesg | grep ttyO
> [0.00] Kernel command line: console=ttyO0,115200n8
> bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk1p1 ro
> rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet
> [0.001991] WARNING: Your 'console=ttyO0' has been replaced by 'ttyS0'
> # cat /etc/os-release
> PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
> NAME="Debian GNU/Linux"
> VERSION_ID="9"
> VERSION="9 (stretch)"
> ID=debian
> HOME_URL="https://www.debian.org/;
> SUPPORT_URL="https://www.debian.org/support;
> BUG_REPORT_URL="https://bugs.debian.org/;
>
> What should I do to enable putty back for serial debug console use?
>
> Note: the original image Debian info in the new BBB wireless board:
> # cat /etc/os-release
> PRETTY_NAME="Debian GNU/Linux 8 (jessie)"
> NAME="Debian GNU/Linux"
> VERSION_ID="8"
> VERSION="8 (jessie)"
> ID=debian
> HOME_URL="http://www.debian.org/;
> SUPPORT_URL="http://www.debian.org/support;
> BUG_REPORT_URL="https://bugs.debian.org/;
>
>
> Thanks
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/beagleboard/dYqvv6RyJlQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/b92811c8-38f9-4fe8-857f-49bbc958f8c3%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAFBMFju2cT_KeatMOa9pzpm_d5Gm-7R%2B5-iRSnSeO4W-QiDr-Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: BBB: after power down, reboots automatically

[mikeprice . 1285]

UPDATE: the pull-up resistor didn't help.

I tried a new BBB. It exhibited the same behavior, powered by USB or the DC 
jack.

Since I'm running headless, I set multi-user.target and then apt-get remove 
-y x11-common.

This freed 370MB.

It also had the side effect of changing the power off behavior. It now 
stays off.

Is there some auto-start configuration associated with the graphical 
environment?

In any case, it appears to be working. For the moment. Thanks  for the 
suggestions from all.

Regards,
Mike

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/d956a9af-d1b5-46da-9b29-962c11ca07d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Setting SPI0 as slave and read buffer data.

[Robert Nelson]

On Thu, Aug 2, 2018 at 5:24 PM,   wrote:
> Even I have the same problem, did you figure out why?

You need v4.13.x+

https://elinux.org/Tests:MSIOF-SPI-Slave

https://fosdem.org/2018/schedule/event/hwenablement_linux_as_spi_slave/attachments/slides/2355/export/events/attachments/hwenablement_linux_as_spi_slave/slides/2355/Linux_as_an_SPI_Slave_Handouts.pdf

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYiGozDcPHcEm5axYyP0fpo7RZEuib_0dXQhZtY75_XTwA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BeagleBone Debian boot time (IPV6, ethernet..)

[richfdietzjr]

My ISP in the US runs IP4 and releases every 2 mins,  and IPv6 runs fine 
with out issue.  
At first the printer did not work and other things but it is all good now.

Except for the Beagle Board Blue. I load the SD, and the light shows up,  
and repeats it self in the middle of the blue led array for ever.

Is there a way to fix this.  or hard code an IP4 and  IP6 at once. 



On Friday, January 23, 2015 at 10:00:08 AM UTC-5, Frank Agius wrote:
>
>
>
> On Thursday, January 22, 2015 at 5:18:09 PM UTC-5, Boris Ostrovskiy wrote:
>>
>> It takes my beaglebone ~70seconds to fully boot. Looking at "dmesg" it 
>> seems like most of that time is spent setting up / loading network 
>> functionality. I do need the ethernet connection but is there a way to 
>> speed up the process...?
>>
> For numbers I list below, I define boot time as the time from when power 
> is applied to when I get to a login prompt on a serial console.  I'm 
> running 3.8.13-bone69 on a beaglebone black rev c.   With eth0 setup for 
> auto and dhcp in the interfaces file, it takes my board about 77 seconds to 
> boot.  I can reduce that time to 11 seconds by making the following changes:
>
> 1) disable auto for eth0. ie change in /etc/network/interfaces "auto eth0" 
> to "#auto eth0"
> 2) add the line "ifup eth0;"  to /etc/rc.local.  
>  
> With these changes, I consistently get boot times in the 10 to 11 second 
> range and eth0 gets its ip address from a dhcp server.  
>
> frank agius
>  
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/8501eb26-539d-48a2-a1ca-2525fd50ad80%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Setting SPI0 as slave and read buffer data.

[mazbeenpalsetia]

Even I have the same problem, did you figure out why?


On Monday, November 6, 2017 at 9:57:17 AM UTC-6, simo zz wrote:
>
>
> Hello,
>
> I am developing a C application to read from the SPI0 from the Beaglebone 
> Black.
>
> The test I am doing is with two Beaglebones, one configured as a slave 
> which transmits data, and the other I want to act as slave.
>
> Both run a kernel *4.4.20-ti-r43*. The master it's working fine, but the 
> slave it doesn't. The connection diagram I planned is attached as an image.
>
> The device-tree for the slave Beaglebone Black is the following:
>
> */dts-v1/;*
>
> */ {*
> * compatible = "ti,beaglebone", "ti,beaglebone-black", 
> "ti,beaglebone-green";*
> * part-number = "BB-SPIDEV0";*
> * version = "00A0";*
> * exclusive-use = "P9.17", "P9.18", "P9.21", "P9.22", "spi0";*
>
> * fragment@0 {*
> * target = <0xdeadbeef>;*
>
> * __overlay__ {*
>
> * pinmux_bb_spi0_pins {*
> * pinctrl-single,pins = <*
> * 0x150 0x30  /* CLK INPUT */*
> * 0x154 0x30  /* DSO INPUT */ *
> * 0x158 0x10  /* DS1 OUTPUT */*
> * 0x15c 0x30  /* CS0 INPUT */*
> * >;*
> * linux,phandle = <0x1>;*
> * phandle = <0x1>;*
> * };*
> * };*
> * };*
>
> * fragment@1 {*
> * target = <0xdeadbeef>;*
>
> * __overlay__ {*
> * #address-cells = <0x1>;*
> * #size-cells = <0x0>;*
> * status = "okay";*
> * pinctrl-names = "default";*
> * pinctrl-0 = <0x1>;*
> * ti,pio-mode;*
>
> * channel@0 {*
> * #address-cells = <0x1>;*
> * #size-cells = <0x0>;*
> * compatible = "spidev";*
> * reg = <0x0>;*
> * spi-max-frequency = <0xf42400>;*
> * spi-cpha;*
> * };*
>
> * channel@1 {*
> * #address-cells = <0x1>;*
> * #size-cells = <0x0>;*
> * compatible = "spidev";*
> * reg = <0x1>;*
> * spi-max-frequency = <0xf42400>;*
> * };*
> * };*
> * };*
>
> * __symbols__ {*
> * bb_spi0_pins = "/fragment@0/__overlay__/pinmux_bb_spi0_pins";*
> * };*
>
> * __local_fixups__ {*
>
> * fragment@1 {*
>
> * __overlay__ {*
> * pinctrl-0 = <0x0>;*
> * };*
> * };*
> * };*
>
> * __fixups__ {*
> * am33xx_pinmux = "/fragment@0:target:0";*
> * spi0 = "/fragment@1:target:0";*
> * };*
> *};*
>
> and the C code used to read from the SPI is the following 
>
> *#include *
> *#include *
> *#include *
> *#include *
> *#include *
> *#include *
> *#include *
> *#include *
> *#include *
> *#include *
> *#include *
> *#include *
>
> *void pabort(char *string)*
> *{*
> *perror(string);*
> *abort();*
> *}*
>
> *void usage(char *progname)*
> *{*
> *printf("usage: %s  \n", progname);*
> *}*
>
> *void spiRead(int fd, uint32_t *rxbuffer, uint8_t bits, size_t txlen, 
> uint32_t spiSpeed)*
> *{*
> **rxbuffer = 0;*
>
> *struct spi_ioc_transfer tr =*
> *{*
> *.tx_buf = (uint32_t) 0,*
> *.rx_buf = (uint32_t) rxbuffer,*
> *.len = txlen,*
> *.delay_usecs = 1,*
> *.speed_hz = spiSpeed,*
> *.bits_per_word = bits,*
> *};*
>
> *if(ioctl(fd, SPI_IOC_MESSAGE(1), ) == -1)*
> *{*
> *perror("can't read SPI message");*
> *return;*
> *}*
> *else*
> *printf("SPI read: %x\n", *rxbuffer);*
>
> *}*
>
> *int main(int argc, char **argv)*
> *{*
> *int spifd = 0;*
> *uint8_t mode = 3;*
> *uint8_t bits = 32;*
> *uint32_t speed = 50;*
> *uint32_t rxVal = 0;*
>
> *close(spifd);*
> *spifd = open("/dev/spidev1.0", O_RDWR);*
> *if(spifd == -1)*
> *{*
> *close(spifd);*
> *pabort("open: ");*
> *}*
>
> *if(ioctl(spifd, SPI_IOC_WR_MODE, ) == -1)*
> *pabort("ioctl SPI_IOC_WR_MODE: ");*
>
> *if(ioctl(spifd, SPI_IOC_WR_BITS_PER_WORD, ))*
> *pabort("ioctl SPI_IOC_WR_BITS_PER_WORD: ");*
>
> *if(ioctl(spifd, SPI_IOC_WR_MAX_SPEED_HZ, ))*
> *pabort("ioctl SPI_IOC_WR_MAX_SPEED_HZ: ");*
>
> *while(1)*
> *{*
> *// printf("Sending message to %s\n", argv[1]);*
>
> *spiRead(spifd, , bits, sizeof(rxVal), speed);*
> *// usleep(50);*
> *}*
>
> *close(spifd);*
>
> *return 0;*
> *}*
>
> However, the value read into rxBuffer is always *0x* and from the 
> SPI0_SCLK pin I can see the clock signal (through my oscilloscope) so the 
> CLK pin is not set as input as device-tree source should configure.
>
> From AM335x Technical Reference Manual, the SPI0 can be configured as 
> Master and as Slave.
> What's wrong in my setup or what is the additional setting I have to do to 
> have the SPI working as slave ?
>
> Thank you in advance.
> Regards,
> Simon
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/dc411d48-3095-421b-b6db-e3a034ffc8e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Reading over SPI with Beaglebone Black as Slave

[mazbeenpalsetia]

Hello,
Any luck on this? I have the same issue.

On Saturday, April 12, 2014 at 3:39:58 AM UTC-5, Babak Rezai wrote:
>
> Im trying to use the Beaglebone Black as a slave device and read from the 
> arduino over SPI.
>
> Im confused as to why I am just getting 255 repeated over and over on the 
> terminal as an output.
> My thought is that there is some kind of a memory leak or buffer overflow. 
> I just can not figure out what
> I'm doing wrong. Is one supposed to set cs as input? even with it set to 
> output I have the same issue.
>
> I have my dts file set as:
>
> /dts-v1/;
> /plugin/;
>
> / {
> compatible = "ti,beaglebone", "ti,beaglebone-black";
>
> /* identification */
> part-number = "spi0pinmux";
>
> fragment@0 {
> target = <_pinmux>;
> __overlay__ {
> spi0_pins_s0: spi0_pins_s0 {
> pinctrl-single,pins = <
>   0x150 0x30  /* spi0_sclk, INPUT_PULLUP | MODE0 */
>   0x154 0x30  /* spi0_d0, INPUT_PULLUP | MODE0 */
>   0x158 0x10  /* spi0_d1, OUTPUT_PULLUP | MODE0 */
>   0x15c 0x30  /* spi0_cs0, INPUT_PULLUP | MODE0 */
> >;
> };
> };
> };
>
> fragment@1 {
> target = <>;
> __overlay__ {
>  #address-cells = <1>;
>  #size-cells = <0>;
>
>  status = "okay";
>  pinctrl-names = "default";
>  pinctrl-0 = <_pins_s0>;
>
>  spidev@0 {
>  spi-max-frequency = <2400>;
>  reg = <0>;
>  compatible = "linux,spidev";
> };
> };
> };
> };
>
> My Arduino is wired up like so:
> P9.22 SPI0_CLK - Orange - 0x150 0x30 --> Arduino Due 110 SCLK
> P9.21 SPI0_D0 - Green - 0x154 0x30 --> Arduino Due 109 MOSI
> P9.18 SPI0_D1 - White - 0x158 0x10 --> 108 MISO
> P9.17 SP0_CS0 - Black - 0x15C 0x30 ---> Pin 10 Set as Slave Select
>
> Python File:
> import spidev
> import time
> spi = spidev.SpiDev()
> spi.open(1,0)
> while True:
>resp = spi.readbytes(1)
>print resp[0]
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/939f4db1-bbc8-4e62-bb43-b634bcdab3b0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] CircuitCo WL1835MOD Wifi_BT cap not detected

[UJ]

Hello There,
I need some help on connecting BeagleBone WL1835MOD w/ Chip Antenna Cape 
rev A1 on BeagleBone white A6. 
Here is the log from dmesg;

debian@beaglebone:~$ sudo dmesg | grep cap 
[sudo] password for debian:  
[0.806505] Linux video capture interface: v2.00 
[1.699523] gpio-of-helper ocp:cape-universal: ready 
[2.009144] bone_capemgr bone_capemgr: Baseboard: 
'A335BONE,00A6,1813BB000150' 
[2.009178] bone_capemgr bone_capemgr: 
compatible-baseboard=ti,beaglebone - #slots=4 
[2.054855] bone_capemgr bone_capemgr: Invalid signature '' at 
slot 0 
[2.062131] bone_capemgr bone_capemgr: slot #0: No cape found 
[2.095277] bone_capemgr bone_capemgr: slot #1: No cape found 
[2.128387] bone_capemgr bone_capemgr: slot #2: No cape found 
[2.159789] bone_capemgr bone_capemgr: slot #3: No cape found 
[2.165722] bone_capemgr bone_capemgr: initialized OK. 
debian@beaglebone:~$ uname -a 
Linux beaglebone 4.9.78-ti-r94 #1 SMP PREEMPT Fri Jan 26 21:26:24 UTC 2018 
armv7l GNU/Linux

My understanding is that beaglebone reads the I2C EEPROM data at boot time 
and detects the CAP model and loads the correct dtbo file. Why is it not 
happening in this case?
Also, I searched the /boot/dtbs/ for the proper devicetree overlay but only 
found files for Beagle Bone black.

am335x-boneblack-wl1835mod.dtb

When I tried to use this dtb file, it crashed the boot process and reported 
MMC read/write error. It is obvious that it is meant for Beaglebone black 
and not for the board I am using.

Any input will be highly appreciated.

Thank you

UJ

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/4be92d5b-8d53-4a54-add1-fbf2ce80cf0c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Ongoing Support for OMAP Serial Driver in Future Kernel Versions

[Jeff Andich]

Thanks Robert!!

Would really like to test the 485 mode in the 8250 driver, but before that, 
we're going to try to get 485 mode enabled on the FTDI FT4232 USB<->serial 
hub.   We've ordered some FT4232 Mini Module evaluation boards for FT4232  
(FT4232H chip + EEPROM + breakout pins + mini USB port).   

The biggest what if at the moment is how to write to the onboard EEPROM 
from Linux.  The FT4232 data sheet indicates that an external EEPROM needs 
to be attached to the FT4232H, and the RI/TXDEN flag in the EEPROM needs to 
be re-configured from the default state to enable 485 mode for each of the 
4 serial channels.  Thus far,  
https://www.acmesystems.it/CM3-HOME_ft4232_setup 

 looks 
promising, as the EEPROM tools appear to be talking to our EEPROM-less 
FT4232H chip on our custom board. .   

Plan to post up on our findings/stumbling blocks here.  If we can get this 
working, then this MAY be of interest to those looking for a quick RS 485 
solution.   

Regards,

Jeff


On Thursday, August 2, 2018 at 8:37:26 AM UTC-5, RobertCNelson wrote:
>
> On Thu, Aug 2, 2018 at 8:22 AM Jeff Andich  > wrote: 
> > 
> > Hi, 
> > 
> > What's the best way to find out how long a legacy driver like the 
> omap-serial driver will be supported in the kernel going forward? 
>
> It's not going anywhere till they are feature matching.. 
>
> > 
> > We've swapped out the 8250 driver for the OMAP serial driver via the 
> .config file, since the omap serial driver implements a 485 mode which, 
> thus far, appears to be functioning correctly for our application.  On the 
> next spin of our board, we plan to realize more 485 channels using the 
> omap-serial driver and GPIO lines. 
> > 
> > We're currently "baselined" on kernel 4.4.110, but if we need to upgrade 
> to a newer kernel version at some point, this could be an issue if the 
> OMAP-serial driver is obsoleted in a later kernel. 
> > 
> > As of yet, we haven't tested the RS485 mode which has been implemented 
> in the 8250 serial driver in kernel 4.6 and later, but if there are known 
> plans for dropping support for the omap-serial driver, then we will 
> definitely test the  8250/RS485 implementation. 
> > 
> > Thus far have looked at the following, and didn't SEE any plans for 
> obsolescence: 
> > 
> > 
> https://github.com/torvalds/linux/commits/master/drivers/tty/serial/omap-serial.c
>  
> > 
> > Also, comments like the following lead me to believe that the 
> omap-serial driver will be around as long as the omap platform 
> > is still supported.  It SOUNDS almost like the 8250 driver is generic 
> for other platforms (e.g. other than OMAP) which 
> > don't support DMA. 
> > 
> > 
> > * Note: This driver is made separate from 8250 driver as we cannot 
> > * over load 8250 driver with omap platform specific configuration for 
> > * features like DMA, it makes easier to implement features like DMA and 
> > * hardware flow control and software flow control configuration with 
> > * this driver as required for the omap-platform 
>
> Yeah, that "was" pretty much the state of the 8250 driver circa 2.6.32 
>
> 485 mode is really the only thing the omap driver does better at this 
> point in today's kernel.. 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/0f603514-231c-4a17-a2cb-210a8ad351f8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Ongoing Support for OMAP Serial Driver in Future Kernel Versions

[Jeff Andich]

Thanks Robert!!

Would really like to test the 485 mode in the 8250 driver, but before that, 
we're going to try to get 485 mode enabled on the FTDI FT4232 USB<->serial 
hub.   We've ordered some FT4232 Mini Module evaluation boards for FT4232  
(FT4232H chip + EEPROM + breakout pins + mini USB port).   The biggest what 
if at the moment is how to write to the onboard EEPROM from Linux.  Thus 
far,  https://www.acmesystems.it/CM3-HOME_ft4232_setup looks promising, as 
the EEPROM tools appear to be talking to our EEPROM-less FT4232H chip on 
our custom board. .   

Plan to post up on our findings/stumbling blocks here.  If we can get this 
working, then this MAY be of interest to those looking for a quick RS 485 
solution.   

Regards,

Jeff


On Thursday, August 2, 2018 at 8:37:26 AM UTC-5, RobertCNelson wrote:
>
> On Thu, Aug 2, 2018 at 8:22 AM Jeff Andich  > wrote: 
> > 
> > Hi, 
> > 
> > What's the best way to find out how long a legacy driver like the 
> omap-serial driver will be supported in the kernel going forward? 
>
> It's not going anywhere till they are feature matching.. 
>
> > 
> > We've swapped out the 8250 driver for the OMAP serial driver via the 
> .config file, since the omap serial driver implements a 485 mode which, 
> thus far, appears to be functioning correctly for our application.  On the 
> next spin of our board, we plan to realize more 485 channels using the 
> omap-serial driver and GPIO lines. 
> > 
> > We're currently "baselined" on kernel 4.4.110, but if we need to upgrade 
> to a newer kernel version at some point, this could be an issue if the 
> OMAP-serial driver is obsoleted in a later kernel. 
> > 
> > As of yet, we haven't tested the RS485 mode which has been implemented 
> in the 8250 serial driver in kernel 4.6 and later, but if there are known 
> plans for dropping support for the omap-serial driver, then we will 
> definitely test the  8250/RS485 implementation. 
> > 
> > Thus far have looked at the following, and didn't SEE any plans for 
> obsolescence: 
> > 
> > 
> https://github.com/torvalds/linux/commits/master/drivers/tty/serial/omap-serial.c
>  
> > 
> > Also, comments like the following lead me to believe that the 
> omap-serial driver will be around as long as the omap platform 
> > is still supported.  It SOUNDS almost like the 8250 driver is generic 
> for other platforms (e.g. other than OMAP) which 
> > don't support DMA. 
> > 
> > 
> > * Note: This driver is made separate from 8250 driver as we cannot 
> > * over load 8250 driver with omap platform specific configuration for 
> > * features like DMA, it makes easier to implement features like DMA and 
> > * hardware flow control and software flow control configuration with 
> > * this driver as required for the omap-platform 
>
> Yeah, that "was" pretty much the state of the 8250 driver circa 2.6.32 
>
> 485 mode is really the only thing the omap driver does better at this 
> point in today's kernel.. 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/e0a04cdd-4745-4a23-9ad8-9442df864a1a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Amazon Launch Its Free Contact Number For Free To get in touch with its customers

[apextm Technical Multi-support]

http://bit.ly/AMAZONSupport

Amazon Launch Its New Contact #Number Toll-free To Connect With Their 
Customer Easily So If You Have Any Query Now You Can tell it Directly To 
Amazon or If You Are Trouble With any #problem Then Get It Instant 
Sollution By #Amazon Certifired Technicians For Free 

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/a601e93d-ab05-4b91-b4bc-b2f55b00fcee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Ongoing Support for OMAP Serial Driver in Future Kernel Versions

[Robert Nelson]

On Thu, Aug 2, 2018 at 8:22 AM Jeff Andich  wrote:
>
> Hi,
>
> What's the best way to find out how long a legacy driver like the omap-serial 
> driver will be supported in the kernel going forward?

It's not going anywhere till they are feature matching..

>
> We've swapped out the 8250 driver for the OMAP serial driver via the .config 
> file, since the omap serial driver implements a 485 mode which, thus far, 
> appears to be functioning correctly for our application.  On the next spin of 
> our board, we plan to realize more 485 channels using the omap-serial driver 
> and GPIO lines.
>
> We're currently "baselined" on kernel 4.4.110, but if we need to upgrade to a 
> newer kernel version at some point, this could be an issue if the OMAP-serial 
> driver is obsoleted in a later kernel.
>
> As of yet, we haven't tested the RS485 mode which has been implemented in the 
> 8250 serial driver in kernel 4.6 and later, but if there are known plans for 
> dropping support for the omap-serial driver, then we will definitely test the 
>  8250/RS485 implementation.
>
> Thus far have looked at the following, and didn't SEE any plans for 
> obsolescence:
>
> https://github.com/torvalds/linux/commits/master/drivers/tty/serial/omap-serial.c
>
> Also, comments like the following lead me to believe that the omap-serial 
> driver will be around as long as the omap platform
> is still supported.  It SOUNDS almost like the 8250 driver is generic for 
> other platforms (e.g. other than OMAP) which
> don't support DMA.
>
>
> * Note: This driver is made separate from 8250 driver as we cannot
> * over load 8250 driver with omap platform specific configuration for
> * features like DMA, it makes easier to implement features like DMA and
> * hardware flow control and software flow control configuration with
> * this driver as required for the omap-platform

Yeah, that "was" pretty much the state of the 8250 driver circa 2.6.32

485 mode is really the only thing the omap driver does better at this
point in today's kernel..

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYhQ1M2ve0RkZ%3DkyrthmDp%2B-bun5WBa_88RCE07Ao%2BLAAQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Ongoing Support for OMAP Serial Driver in Future Kernel Versions

[Jeff Andich]

Hi,

What's the best way to find out how long a legacy driver like the 
omap-serial driver will be supported in the kernel going forward?

We've swapped out the 8250 driver for the OMAP serial driver via the 
.config file, since the omap serial driver implements a 485 mode which, 
thus far, appears to be functioning correctly for our application.  On the 
next spin of our board, we plan to realize more 485 channels using the 
omap-serial driver and GPIO lines.

We're currently "baselined" on kernel 4.4.110, but if we need to upgrade to 
a newer kernel version at some point, this could be an issue if the 
OMAP-serial driver is obsoleted in a later kernel. 

As of yet, we haven't tested the RS485 mode which has been implemented in 
the 8250 serial driver in kernel 4.6 and later, but if there are known 
plans for dropping support for the omap-serial driver, then we will 
definitely test the  8250/RS485 implementation.

Thus far have looked at the following, and didn't SEE any plans for 
obsolescence:

https://github.com/torvalds/linux/commits/master/drivers/tty/serial/omap-serial.c

Also, comments like the following lead me to believe that the omap-serial 
driver will be around as long as the omap platform 
is still supported.  It SOUNDS almost like the 8250 driver is generic for 
other platforms (e.g. other than OMAP) which 
don't support DMA.
 

* Note: This driver is made separate from 8250 driver as we cannot
* over load 8250 driver with omap platform specific configuration for
* features like DMA, it makes easier to implement features like DMA and
* hardware flow control and software flow control configuration with
* this driver as required for the omap-platform


Any insight here would be greatly appreciated..

Thanks!

Jeff

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/5e1d1509-3c73-4e8d-859b-d61a77c103ef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: standby mode in new kernel 4.14.56-ti-r64

[Philippe Fouquet]

Hi

I find my mistake : I forget the driver "AMx3 Power management" into soc 
section.

Now I can pass my bord into standby mode.

But now, I have a probleme if I switch the board in to standby mode with 
usb otg connected to a PC it fail with a kernel panic into the usb core 
driver.



Philippe FOUQUET

Le mercredi 25 juillet 2018 13:38:43 UTC+2, Philippe Fouquet a écrit :
>
> Hi
>
> I am done a board update and I pass the kernel 4.4.x to 4.14.56 and now I 
> can't pass the board in standby mode I have just the mem mode and the wake 
> up don't work (rtc, ttyS0, gpio...).
> I reinstall a kernel 4.4.113-ti-r149 (with the script update_kernel.sh) and 
> all work well
>
> Some thing was change in the command fore the power management ?
>
> thank
> Philippe FOUQUET
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/5cc5f736-9da8-4e79-b2c9-6d9597262ecd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.