Posts by WaSt

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!

Hello everyone,

I was trying to figure out the kernel development strategy of F&S based on the github repo but I couldn't really figure it out.

Basically I wanted to know on which version of linux-imx my current tag (e.g. fsimx8mm-2023.11) is based on.

I see the master branch uses kernel version 5.15.160 and I guess this is always the most current version of all kernels available by F&S
and this branch is also the source for all tags/releases.

I also see some other branches based on newer LTS kernel versions (6.1.x and 6.6.x).

But as far as I can see even the newest tag (fsimx8mp-2024.07.1) uses 5.15.160.

I also see that there is a history file (History-F+S-Kernel.txt) which, I suppose, should document changes made by F&S.

But its last modification was last year and the most recent entry in that file references linux-5.4.70...

So I can't really follow the path of adaption/patches.

Could someone maybe elaborate the development strategy of F&S when it comes to kernel work please.

Are there any plans to support newer LTS versions like 6.6.x?

One other question on that topic:
I know this comes with quite some work, but are there any efforts or plans to upstream the changes and board configs to mainline (or linux-imx) someday?

Thank you in advance!

Best regards,
Stefan

I am currently using the heat sink that came with the evaluation package, which is a combination of the Heat Spreader PicoCore100 and Heat Sink PicoCore100.

Alright, thank you for the information!

Hello again,

I am working with the PicoCoreMX8MM + FS-BaseBoard.

Currently I am taking a look at the temperature while running an UI-Application.

Setup:

• Qt-Application with simple animation (3 simultaneously moving arrows)
• Resolution: Full-HD 1920x1080
• Cooling: PicoCore heat sink from F&S
• Temperature reading from: /sys/class/thermal/thermal_zone0/temp

Testcase 1: Software-Rendering (linuxfb backend)

• Result without cooling
  • CPU usage: 65%
  • Temp: 74°C
• Result with cooling
  • CPU usage: 65%
  • Temp: 60°C

Testcase 2: GPU-Rendering (eglfs backend)

• Result without cooling
  • CPU usage: 5%
  • Temp: 73°C
• Result with cooling
  • CPU usage: 5%
  • Temp: 58°C

Regarding the CPU usage, the big drop is expected, as the GPU does the heavy lifting now with the animation.

But I was expecting a more significant drop in temperature, as it basically stayed the same.

Are these measurements ok?
What are "normal" or expected temperatures when running an UI-Application with animations on full-hd panel?

The objective of those tests is to decide whether we need a heat sink or not.

Is it safe to run the PicoCoreMX8MM without heat sink in those temperatures (70-80°C)?

Thank you and best regards,

Stefan

Perfect, thanks for the info!

Hello again,

I am currently working on an A/B update scheme on an PicoCoreMX8MM using SWUpdate.

The SWUpdate side of things in the userspace works fine.

The next step for me is the coordination with u-boot, so it knows where to boot from and which rootfs to take (A or B).

I took a look at the u-boot configuration for the fsimx8mm (include/configs/fsimx8mm.h) and saw that F&S already provides this mechanism,

which is enabled with CONFIG_FS_UPDATE_SUPPORT.

The corresponding Kconfig description ("Provides the U-Boot support for the buildroot package") indicates that this feature is used in combination

with some update utility.

This update utility, just like SWUpdate, will probably also communicate with u-boot via its environment variables, to signal it what slot to boot from.

Now I would like to use this u-boot feature with my current SWUpdate setup, so I don't have to hack around in/with u-boot.

Unfortunately I didn't find any documentation for it.

Is there any documentation available on how to use this feature?

Which U-Boot variables have to be manipulated to switch boot slot? ("BOOT_ORDER"?)

Thank you!

Best regards,

Stefan

Hello,

I'm currently working on an A-B update schema with the PicoCoreMX8MM (eMMC only).

After creating 5 partitions with a MBR partition table I got introduced to the limitation of MBR and the W95 Ext'd (LBA) Partition.

Everything is working fine, but I noticed all the .wks files in meta-fus and in "Linux on F&S Boards.pdf" use a MBR partition table.

For testing I switch to a GPT partition table and everything seems to still work.

So I'm curious, why not use "new" GPT instead of "old" MBR?

Are there any pitfalls or drawbacks when using GPT on such embedded boards?

U-Boot seems to handle both equally.

Thanks!