Hi there. Got your PM..
Regarding the defconfig changes to enable the OMAP.
You're going to need to tune the defconfig, and the re-build and deploy the kernel until you see /dev/ttyO*. And then you'll need to check that the serial device of interest is enabled. You can go into /sys/class/tty/ttyO* directory and start looking at things like irq #'s to make sure they're non-0. Not sure how this changes if DMA is enabled.
One interesting thing. If you want to enable UARTs (beyond #6), I found that with the OMAP driver, all you need to do is enable it in the device tree fragement. But with the 8250 driver, you need to change another defconfig define to increase the total # of UARTs..
Regarding updating/building the kernel on the BBB (?? /opt/scripts/tools/update_kernel.sh??), I'm afraid I still haven't done this or used Robert's image Builder on target. I hope to get some practice with that next-week. Then I can hopefully speak more intelligently on that.
And then, inintially I call root_kernel_build_dir/build_kernel.sh,
allow makemenuconfig to run.
Set the defconfig options I need.
Then every subsequent build, I think you can call root_kernel_build_dir/tools/rebuild.sh which will leave your defconfig/.config file in tact.
I promise I won't tell anyone if you modify, KERNEL/.config directly, but I think this is not the recommended procedure.
Regarding and updated OS for 485, I'm not aware of any. If you compile in the OMAP serial driver, then the driver has a 485 interface, so you can add lines to the respective UART's fragment such as the following and the referenced gpio line in the fragement below will toggle when you do setRTS(True/False) in python-serial.
This won't work with the 8250 serial driver. However, what will work with the 8250 driver is if you allocate a dedicated uart5_rtsn line and then tie that to your DE input on a 485 chip, you will be able to call setRTS(True/False) from Python (and I assume C/C++/C#), and the line will actually change state. But I don't think the 8250 driver will handle the automatic flow control with intercharacter timeouts needed for full hardware flow control. I haven't tried this.
Also another question you need to ask is for 485, are you using 2-wire or 4-wire RS485 chips. If 4-wire, then, depending on your application, you maybe able to tie the DE signal high and allow the 485 chip to operate in full-duplex mode. If 2 wire, then presumably, someone will need to toggle the DE line to multiplex internally the BBB UART's Rxd vs Txd onto the differential signal end of the 485 chip. For our purposes, since our application knows when its transmitting vs receiving, the application can toggle the RTS line around transmit and receive sentences/packets.
Another thing I don't yet know. Say that your application program refuses to add toggling of the RTS line between transmit and receive packets and s/he wants you to handle this at the driver level (which is understandable given application software portability requirements). What all do you need to implement for the OMAP serial driver and the UART to handle automatic toggling of the RTS line so that the driver "senses" when the transmitter is done transmitting and can then toggle RTS/CTS to allow the other party to speak on the half-duplex line? Do you need to wire up DE to UARTn_RTS and DE_INV to UARTn_CTS or can you leave CTS floating (or tie it to a known state if your mux mode permits)? If someone has tried this (granted hardware flow control is probably an anachronism), please chime in. But the test data probably exists somewhere in this thread or a related thread on this forum.
&uart5 {
pinctrl-names = "default";
pinctrl-0 = <&uart5_pins>;
status = "okay";
rts-gpio = <&gpio5 8 GPIO_ACTIVE_HIGH>;
rs485-rts-active-high;
rs485-rts-delay = <0 0>;
linux,rs485-enabled-at-boot-time;
};