Posts by WaSt

  • GPIO Pull-Up/Down, input voltage

    Alright thank you for the information on this errata!

    We will only use external pullups/pulldowns for inputs from now on.


    You removed the internal pull resistors in the kernel, but in the U-Boot devicetree from this release, they are still present.

    Do you plan on also removing them there, or is it negligible there because U-Boot usually only runs for a couple of seconds at most.


    Thank you and best regards,

    Stefan

  • GPIO Pull-Up/Down, input voltage

    Hello,


    In the datasheet of the i.MX8M Mini I have found the following table:



    In the PicoCoreMX8MM hardware documentation it says that the GPIOs work on 3V3.

    Does that mean that in the table above that VDD = 3.3V?

    Because that would mean, that it would not support internal pull-up/down resistors?


    Also for the input voltage levels, is it correct to assume:

    High: > 0.7 * 3V3

    Low: < 0.3 * 3V3


    Thank you and best regards,

    Stefan

  • Performance Tweaks i.MX8MM for USB camera via PCIe

    Disabling the memory bus frequency scaler did not change anything...


    But passing cpuidle.off=1 to Linux from U-Boot works!

    I am also able to dynamically enable/disable idle states for each CPU core via sysfs /sys/devices/system/cpu/cpu*/cpuidle/state*/disable.

    I think that this should work now, so I can disable the idle states before I start the camera and enable them afterwards.


    Another question regarding IMX GStreamer plugins:

    There are two imx plugins which kind of handle the same things:

    Do you guys have any experience with them or prefer one over the other?


    Stefan

  • Performance Tweaks i.MX8MM for USB camera via PCIe

    Hello again,


    it actually seems like an issue with the cpu cores frequency scaling.

    Code
    1. dd if=/dev/zero of=/dev/null &

    has the same effect as usbmon...


    As stated in the original post, setting the scaling_governor to "performance" for every core, does not change anything.


    Do you have any other suggestions to keep the cores active?


    Thank you and best regards,

    Stefan

  • Performance Tweaks i.MX8MM for USB camera via PCIe

    Hello,


    we are currently in the process of integrating a USB 3.0 camera (goal = 1920x1080@30fps) into our system, which is powered by a PicoCoreMX8MM.

    As the i.MX8MM does not have native USB 3.0, we use the uDP720202 PCIe to USB 3.0 chip. So far so good, USB 3.0 works with all the right drivers.


    Unfortunately we don't reach 30fps. Everything above 20fps starts to stutter heavily.
    And for some reason only the first stream works, every subsequent stream fails and I see error messages like:

    • "uvcvideo 2-1:1.1: Failed to resubmit video URB (-1)."
    • "uvcvideo 3-2:1.1: Non-zero status (-71) in video completion handler."

    At first I thought that 30fps is just too much data to handle, but in the process of testing/debuging I stumbled upon usbmon.

    Strangely enough while usbmon is actively running in the background, I am able to get a stable 30fps from the camera.

    So I have one session (SSH) dumping the usbmon output and one session (Serial) which starts the GStreamer pipeline to show the camera video on a screen.

    It seems that having usbmon running, the USB performance increases.


    Unfortunately I am not able to replicate that performance without usbmon.

    What I tried so far:

    • Set CPU frequency scaling to performance:
      echo performance > /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
    • Map the IRQs to a isolated core. Unfortunately because the USB 3.0 is connected via PCIe, Message Signaled Interrupts (MSI) are used,
      for which I cannot change the smp_affinity in /proc/irq/<N>/smp_affinity (see NXP-Forum).
      But I see from the output of /proc/interrupts, that CPU0 is handling all the MSIs. And there are a lot of them...


    Is there anything else I can try to improve the USB/PCIe performance?

    Would it be possible to isolate one core to only handle USB/PCIe?


    Thank you and best regards,

    Stefan

  • eMMC Variant: U-Boot stored in User partition?

    Hello,


    i was just getting started with a new PicoCoreMX6ULL100 variant with eMMC storage, when I encountered a problem.

    I was writing the sysimg (emmc output image from Yocto build) to the user partition of the eMMC, like this:

    https://github.com/FSEmbedded/…/images/files/install.txt


    This writes the image into part 0, which I guess is the user partition of the eMMC.

    After the write was done, NBoot was unable to boot U-Boot. Recovery via serial download worked fine.


    I then did a little research and found that on PicoCoreMX6ULL platforms U-Boot is also placed in the user partition (also described in "F&S i.MX6-UltraLite Linux First Steps" chapter 3.4).


    Is this correct?

    If so, why is it not kept in the HW-Partitions boot1 and boot2, like on the PicoCoreMX8MM platform?


    Thank you and best regards,

    Stefan

  • Custom variant for PicoCoreMX6ULL100

    Hello,


    we are developing a product using the PicoCoreMX6ULL100.

    Now it is time to choose a variant, but none of the standard variants V1, V3 or V4 match our requirements perfectly,

    as for example we don't need 2 ethernet interfaces or WLAN/BT.


    What would it mean for F&S if we wanted a custom variant?

    e.g. 4GB eMMC, 1x ETH-PHY, LVDS


    Is it "just" producing the SoM with the required components and NBoot automatically detects the available components?

    Or would that also mean that F&S has to implement a custom variant of NBoot to fit that exact hardware?


    A custom variant obviously will be more expensive than the standard ones.

    At which quantity roughly would the custom variant become cheaper than a standard one?
    For example the one mentioned above versus the PicoCoreMX6UL100-V3I-LIN?


    Thank you in advance!


    Best regards,

    Stefan

  • How far along is Linux v6.6.x for PicoCores?

    Hi,


    on the F&S Github I see that you guys are working on delivering linux-6.6.x for your products.

    As I am eagerly waiting for that version, as it brings a lot more driver functionality for microchip ethernet phys and switches which we need,


    In this topic it was mentioned that the plan was to start releasing v6.6.x support at the end of 2024.

    I was wondering how far along this effort is for the PicoCoreMX6ULL100 and PicoCoreMX8MM especially?

    When can we expect to be using v6.6.x for these products?


    Thank you and best regards,

    Stefan

  • Question: eMMC vs NAND storage

    Hello again,


    I am currently in the process of evaluating different PicoCore modules (MX8MM and MX6ULL100).

    Depending on the variant of each module it either has eMMC or NAND storage.


    I got both types working without any real problem, but I must admit that working with eMMC is a lot nicer than with raw NAND devices, especially in U-Boot.

    I know that these NAND chips use SLC technology which should be more robust than these eMMC chips, but is that really an issue in reality?


    I also noticed that all the new PicoCore modules (MX8ULP, MX91, MX93) only come with eMMC storage.

    Do you plan on using raw NAND storage on new future modules or is eMMC the future on PicoCore devices?


    Also, is there a big difference in cost?

    For same amount of storage, I would assume that eMMC is cheaper.

    But what about, lets say the PicoCoreMX6ULL100 with 512MB NAND vs 4GB eMMC. What would be the difference between those two, if everything else on the SoM is the same?


    Any other main differences I am missing?


    Thank you!


    Best regards,

    Stefan

  • External ethernet PHY or switch connected to RMII/RGMII signals

    Hello again,


    we are currently in the process of evaluating possible ethernet solutions.

    Particularly a small ethernet switch and an external phy.


    As both of these parts have to be on the carrier board of the PicoCore, we would have to route the signals from the SoM pins to the part itself.

    As far as my research goes, RGMII can be a little tricky to route, as it needs exact timings so the trace lengths have to match on all signals and so on.

    So a couple of questions:

    • On Variants without a PHY (e.g. PicoCoreMX8MM-V1), are these signals routed directly to the respective connector pins with matching trace lengths?
    • Is there something important we have to consider when connecting an external switch/phy?
    • Do you have any reference designs or experience for connecting an external phy on the carrier board to a PicoCore?
    • Is it possible to run full speed a.k.a. 1Gbit this way?
    • Regarding the clock delay of 1.5-2ns needed by RGMII, this can either be done by the phy/mac devices itself (RGMII-ID) or in HW via trace lengths.
      I would guess the first method (RGMII-ID) is the simpler and more common one, correct?
    • Is there a big difference in connecting a device via RMII compared to RGMII, apart from the different signals?
      So in terms of trace lengths, delays, etc.


    Thank you again for your support!


    Best regards,
    Stefan

  • Unclear behaviour of ON_OFF pin on PicoCore

    Hello again,


    The PicoCore SoMs have a pin called ON_OFF on J2-48.

    In the Hardware documentation of the PicoCoreMX6UL100 for example, in chapter 8 it says:

    Quote

    CPU On/Off control pin, can be used with an external button
    Active high – 10k pull-down

    I also noticed that in chapter 3.1 "B2B connectors" it says the voltage for this pin is 3.3V, the same entry in the documentation for PicoCoreMX8MM the voltage is 1.8V.
    Are these voltages actually different for MX6UL100 and MX8MM?

    We connected an external button to this pin, which connects the signal to GND when pressed, just like it is done on the PicoCoreBBDSI.

    But pressing the button did nothing.

    We then tried it on the PicoCoreBBDSI. We removed R69 and added R70 as described in the documentation.

    But pressing T12 also did nothing.


    Now to my main question(s):


    What is supposed to happen when the signal ON_OFF (J2-48) is low?


    What is the use-case for this pin? Is it supposed to act like a power button on a laptop?


    Is this signal connected to the i.MX MPU and does it need any configuration in SW (e.g. devicetree)?
    I did not find any references in the device tree files for the picocore boards.


    Unfortunately I didn't find any further documentation on this.


    Thank you and best regards,

    Stefan

  • Reset behaviour of GPIO-Pins

    Hello again,

    we finally got around to work on this issue again and tried it with the recommended pull down resistor on the EN pin of U22.

    Setup: PicoCoreBBDSI Rev 1.40 + PicoCoreMX8MM-V1-LIN



    This is the waveform of the EN pin on U22 while reset.

    The voltage drops from ~2,1V to 1,4V, which is still far off the needed 0,4V the RT8070 needs for a low signal.

    The waveform on GPIO_J1_54 still looks the same as before.


    Can you confirm that this workaround works on your side?


    We are kind of clueless, because we don't have the VDD_3V3 pin of the PicoCore connected, because we generate our own 3V3 on the baseboard.
    VDD_VBAT, VDD_SNVS, VDD_3V3 are all not connected on our design.


    Thank you again for the support!

    Best regards,

    Stefan

  • Reset behaviour of GPIO-Pins

    Ok, good to know.

    But the waveform shown in my last answer comes directly from the SoM Pin J1_54, which shouldn't be affected by +3V3 generated on the baseboard (PicoCoreBBDSI), right?
    It is pin 8 on the feature connector.

    It is directly connected to the SoM and should be purely driven by the SoM.


    There is no external pull-up or anything connected to it.


    Why does it jump to ~2.1V for about 300ms when there is nothing connected to it?

  • Reset behaviour of GPIO-Pins

    So I tried the same setup with an external pull-up with the PicoCoreBBDSI and it behaved the same...

    I then took a look at the behaviour of a GPIO without any external connections and found something interesting:


    Setup:

    PicoCoreBBDSI (v1.4) + PicoCoreMX8MM-V1-LIN

    Monitored Pin: GPIO_J1_54 on the Feature-Connector (Pin 8 )



    So whenever I trigger a reset (e.g. reset command in U-Boot) this is what I see on the Pin GPIO_J1_54 on the feature connector.
    So for about 300ms it jumps to ~2.1V...


    Is that supposed to happen?
    Seems a bit strange to me...


    Best regards,

    Stefan