Posts by WaSt

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:

• imx-gst1.0-plugin (https://github.com/nxp-imx/imx-gst1.0-plugin)
• gstreamer1.0-plugins-imx (https://github.com/Freescale/gstreamer-imx)

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

Stefan

Hello again,

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

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

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

Does the fsimx6ul NBoot expect a MBR partition table or is it also capable of handling GPT?

I am on the fsimx6ul-2024.03 release.

But I was using my own custom machine/wic-file without the u-boot section.

Thank you for the quick response and explanation, I will add the u-boot section!

Best regards,

Stefan

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

Regarding the new kernel 6.6.x:

I think "fsimx8mm_defconfig" is missing the KConfig "PHY_FSL_IMX8M_PCIE".

I was trying out the new kernel and PCIe wasn't working until I enabled this config.

Best regards,

Stefan

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

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

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

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

Alright thank you for the information, good to know!

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

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

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?

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

Hello there,

we use the PicoCoreMX8MM and we use one GPIO to be able to reset another MCU on the board.

Now we have realised that everytime the PicoCore reboots, the MCU also resets, which means the GPIO line triggers the reset.

This is our setup simplified:

So we have an external pull-up resistor pulling to line to 3V3.

According to the datasheet of the i.MX8MM all the GPIOs reset with an internal pull-down enabled.

In the device-tree picocoremx8mm.dtsi the pin is also configured to use the internal pull-down.

So I changed that value to 0x00140 (enable pull-up) in the device-tree files for the kernel and u-boot.

Still no change in behaviour, the MCU still resets whenever the PicoCore reboots.

So I took a look at the signal line at reset:

Here I see that after reset the pull-down is active and the line is at ~2,8V, after some time U-Boot configures the pin to use the pull-up and the line goes up to 3V3.

What I can't explain is the short drop to ~1,5V right at the beginning of the reset.

From a previous post here I know that the SW-Reset is done by resetting the PMIC, which then reset everything.

Could that somehow play a role in our issue?

Is it possible that all the pins are pulled low at reset due to the PMIC reset?

Or does this pin (GPIO_J2_77) have any special behaviour, because in the device-tree there is an option for it to be used for USB-C OTG alert?

Thank you guys in advance!

Best regards,

Stefan

Alright, thanks for the info, very helpful!

Hello,

we are using the PicoCoreMX8MM and I would like know the reset reason of the system in U-Boot.
Mainly I want to distinguish between Power-On-Reset and Software-Reset (reboot/reset).

I would like to use this information for stability monitoring after an update. So SW-Reset would increment the bootcount, but POR won't.

I get the reset-reason from U-Boot with get_reset_cause() or get_imx_reset_cause(), but they always indicate a POR, even after a reset from U-Boot or reboot from Linux.

I have read that a lot of boards implement the SW-Reset by telling the PMIC to reset everything, so from the CPU point of view, this is the same as a "real" POR.

How is the SW-Reset mechanism implemented on F&S boards?
Also via PMIC?

So I guess my main question is:

Is it possible to distinguish between "real" Power-On-Resets and SW-Resets (reset/reboot from U-Boot/Kernel)?

Thanks and best regards,
Stefan

That is everything I wanted to know!

Great answer, thank you for going in so much detail!