Hello Neeraj,
No problem, right now I’m fighting with another circuit.
Yes, indeed, the DMA is working, however while browsing the web for potential solution, I encountered mentions of some interrupt problems in am3358’s UART, which are beyond my current state of knowledge.
When it comes to speed tests, I had to roll down the baud rate significantly to stop the issue from showing (way below 900k, cant remember exact number, but it was beyond the point of usability for my application).
Additionally, I made some fiddling with PocketBeagle (I needed USB slot for these tests). First I ran the same test as in original post (FTDI to UART0, BAUD 3M, resulting %idle=71-77%), and then modified it with a connection like this:
PC (hterm) <—usb—> FTDI#1 <—uart—> FTDI#2 <—usb—> PocketBeagle
The second test results are following:
accuracy: 1944100/1968000 bytes (98,7%)
%idle:91-94
Additionally, time it took to send the data through FTDI#1-FTDI#2 was in match with timing requested from hterm application (UART0 communication on the same PocketBeagle took 2-3 times longer than requested).
Best regards,
MC
Hello,
thanks for the tips, I will look into it as soon as I can (especially menuconfig setup, I didnt look there for a long time, something might have affected my setup), however for the time being I will stick to omap-serial drivers.
Best regards and thanks for help.
Hello,
the zip contains the device tree I’m using and dmesg output in .txt format. The dmesg output was made after I fixed the issue with wrong .dts location mentioned in my previous post.
Note that within .dts my pinmux starts at line 717 (just below pinmux@800) and UART1 configuration starts at line 1083 (serial@48022000).
Regards,
MC
Hello Neeraj,
sorry for messup, I forgot to give an update in this thread: my uEnv.txt points to /boot file in my mmcblk1p2 partition (eMMC OS partition), not the mmcblk1p1 which I anticipated, after putting the device tree file in the right location Linux boots with correct dts. The main issue still persists: during booting 8250 drivers dont find any UART devices, however omap-serial.c drivers do. It’s not a big deal since the omap-serial drivers also seem to use DMA, but I’d like to know why the system is behaving this way.
I will provide the neccessary files you mentioned as soon as I will be able to boot my Linux workstation.
Thanks for the heads up about the eeprom. If I change the last 4 bytes (from BBB default value value to ‘OS00’ bytes) can I expect any change in behavior? I dont think there is enough difference in both boards.
Thans for input and best regards,
MC
I almost got it, cat /proc/device-tree/ocp/serial@58022000/status shows me that OS is ignoring my device tree.
Octavo Systems LLC all rights reserved
OCTAVO is registered in the U.S. Patent and Trademark Office. OSD, C-SiP, and the Octavo Logo are trademarks of Octavo Systems LLC.
"*" indicates required fields
"*" indicates required fields
"*" indicates required fields
"*" indicates required fields