Mr.Current

Forum Replies Created

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • in reply to: CPU behavior at high UART baud rates. #9278
    Jarek GlazowskiMr.Current
    Participant

      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

      in reply to: Migration from Beaglebone to OSD3358 #7977
      Jarek GlazowskiMr.Current
      Participant

        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.

        in reply to: Migration from Beaglebone to OSD3358 #7974
        Jarek GlazowskiMr.Current
        Participant

          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

          Attachments:
          in reply to: Migration from Beaglebone to OSD3358 #7972
          Jarek GlazowskiMr.Current
          Participant

            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

            • This reply was modified 5 years, 6 months ago by Jarek GlazowskiMr.Current.
            in reply to: Migration from Beaglebone to OSD3358 #7939
            Jarek GlazowskiMr.Current
            Participant

              I almost got it, cat /proc/device-tree/ocp/serial@58022000/status shows me that OS is ignoring my device tree.

            Viewing 5 posts - 1 through 5 (of 5 total)