Posts by fs-support_HK

As far as I know, ethernet and the PHY is only activated in U-Boot, if there is a command that uses ethernet, for example tftp. Normally the PHY should be brought back again to standby mode when U-Boot stops. Again it is only activated if Linux activates the port, e.g. by an ifconfig up. Unfortunately, the regular Yocto configuration always starts Ethernet automatically. Maybe this can be avoided by shutting down the appropriate service with systemctl.

So if no-one starts Ethernet in U-Boot and no-one starts Ethernet in Linux, the PHY should be rather deeply in stand-by.

Your F&S Support Team

Unfortunately, from F&S' side, there is no support for qemu for any of our boards.

Your F&S Support Team

When using writable filesystems, you *must* shut down the device properly. Otherwise, if the device is only switched off, there will definitely be corrupted filesystems after some time.

If you can not guarantee that the device is always shut down correctly, then you can never be 100% sure. You can only try to keep inconsistent times as short as possible to reduce the probability for problems. For example by keeping all filesystems read-only and only remounting them temporary to writable when actually writing data and remounting them again to read-only after that. Or have an extra partition (or UBI volume) where the written data is located and where it does not matter if this partition/volume gets corrupted.

There is a big misunderstanding of filesystems. Yes, UBIFS is a so-called Journaling Filesystem. This means if it is inconsistent when starting up, for example because it was not properly shut down, it can be brought back to a consistent state by simply examining the Journal. So it does not require a full filesystem check for this. But this does *not* mean that you do not lose any data during this process!

Your F&S Support Team

No, we do not support DisplayLink on USB. As far as I understand, this requires support from the hardware, so I believe this is not possible on NXP's on-chip USB ports.

Your F&S Support Team

The default pin settings are defined by our PicoCore "standard". Which means if you use the pins with these signals, then other PicoCores and also future PicoCores will be pin compatible. But of course you are free to use a different function, with the risk of losing compatibility to future modules. Which means we cannot guarantee this functionality on the same pins on other PicoCores.

• HPD is actually rather important, as it detects if a cable is plugged in and a display is connected.
• CEC is only necessary if you want to remote control other devices over HDMI. For example a TV can control a BluRay player (Play, Stop, Pause, Fast Forward, etc.) by sending appropriate commands via CEC.
• SDA and SCL are also important to read the EDID info, i.e. the list of possible resolutions that the display supports. However the NXP driver can use any I2C port, so it is not too important to use exactly those two lines.

If you want to use these HDMI signals, it is possible to use other pins for the original function. For example I2C_A (J1_4/J1_6) is also available on UART_A_RTS/CTS (J1_14/J1_16) or CAN_B (J1_4/J1_6) is also available on UART_D (J1_34/J1_36). So if you need any of the signals that are required for HDMI, send us an E-Mail with all your required signals and we can check if we find a matching pinmux setting for all your signals.

Please note that HDMI/DVI output is a hardware option on PicoCoreMX8MP. You have to purchase the right variant (V3I or V3XI) to have HDMI/DVI at all. Also note that HDMI on this CPU does not support HDCP! However it does support ARC and eARC (also referred to as HEAC) on DSI_B_DATA3_P/N. As we only use the DVI part of HDMI, we may not have proper support for all the additional HDMI signals in our device tree. So you may need some extra work to get this running.

Your F&S Support Team

I have fixed the link above.

Just to be sure that I understand you correctly. You are trying to write the parent process, but the child process is given and cannot be changed. I believe what you want isn't possible, even in Linux.

You can either create a pipe. Then stdout of one program is used as stdin of the piped program. But then stdout of the second program can not be accessed from the first program. Or you can create a sub-process, but then the child inherits stdin and stdout from the parent, so they both access the same streams.

In the latter case you can redirect stdin and stdout of the child process to regular files, which may exactly be done by the freopen() function that I talked earlier from, or with SetStdioPathW() when directly accessing the file handles (not the FILE pointer).

https://learn.microsoft.com/en…n.10)?redirectedfrom=MSDN

Your F&S Support Team

Just some ideas...

Shouldn't it be simply possible to access the stdin, stdout and stderr FILE stream handles in the child process? Where is the problem there?

The bigger problem is the parent process. Maybe here the function freopen() can be useful to re-assign stdin to a file before creating the child process. By writing to the file you might be able to send commands to your child process. I didn't test this, though...

https://learn.microsoft.com/en…edded/ms861288(v=msdn.10)

Your F&S Support Team

The On-Off signal is to use a power button like on a PC. By a short button press, you can trigger a standby mode and by a press longer than 4 seconds, you can trigger a hard shutdown. When in standby or shutdown mode, pressing the button will wake up the system again. This may require additional support by the power infrastructure on your baseboard, for example for VDD_SNVS on Pin J2-38. Please contact our hardware department if you want to use this feature.

The PMIC_ON_REQ signal is active when the system is going to ON state. This can be used to power up all devices on the baseboard.

The PMIC_STBY signal is active when the system is going to shut down. This can be used to do some final clean-up work before the PMIC_ON_REQ will also go inactive.

A more detailed explanation of these signals can be found in the reference manual for i.MX8MP CPU. These signals are directly connected to the according CPU pins.

Your F&S Support Team

Yes, SPI_MOSI was on J1-29 and SPI_CS was on J1-27 on PicoCOMA9X, but it should have been SPI_MOSI on J1-27 and SPI_CS on J1-29 like on all other PicoCOM modules. So this was wrong.

Now Board Revision 1.20 has an optional fix for this. Here we can configure both variants. We can set solder jumpers to the old (wrong) setting and also to the correct setting. However as most customers are already in the field with their products and have arranged with the swapped setting, we assume that shipping modules with the correct setting now might cause some confusion with them. This is why we actually continue to ship the wrong configuration, even with Board Rev 1.20.

If you want to have the "correct" configuration, please contact our sales department to check if this is possible.

Otherwise I simply suggest to also add solder jumpers to your baseboard, so that you can swap pins 27 and 29, too. For PicoCOMA9X, you use the swapped configuration. And if you ever want to use a different PicoCOM module with the correct pinout in the future, then you can use the unswapped configuration there.

Your F&S Support Team

Yes. UART_A can be used without RTS/CTS. The device tree is already prepared for this, just disable the CONFIG_PICOCOREMX8MP_UART_A_RTSCTS at the beginning.

However we don't have a setting for the CLKREQ signal, yet. So you have to add it manually. Add the following lines to the pciegrp node:

Your F&S Support Team

Looks good to me.

Your F&s Support Team

Documentation is available on our Website. Go to "Products" -> "PicoCore" and select the PIcoCoreMX8MP. Then click on the tab "Documents". You can use the serial number to unlock the software section for this board. This will be in "Support" -> "My F&S" then.

For the type of module, I expected that you have a PicoCoreMX8MP if you are posting in this subsection. The type of board will also be output on the serial debug port if you start U-Boot.

If you are completely new to this type of environment with Linux on an embedded board, then you might consider booking our Linux Workshop. There you will be shown everything to get started with your system.

Your F&S Support Team

The device tree is correct.

Here is some background information.

On previous PicoCOM boards based on Samsung CPUs, the I2C and CAN signals were always available on the same CPU pads. So the alternative function was directly available from the pinmux of the CPU. As many customers got used to this "double feature" of these connector pins, we wanted to keep this on the PIcoCOMA9X as well. However there is no such pinmux on any of the NXP CPU pads. So we needed to use *two* CPU pads, one that provides the I2C signal and one that provides the CAN signal. And by making sure that never both functions are active at the same time, we could simply connect the two signals on the B2B-Connector pin.

So when the CAN_A function is active on pins 30/31, the connector pins are driven by CPU pads SD3_DATA4 and SD3_DATA6 that carry signals for CAN2 of the CPU. But when the I2C_B function is active on pins 30/31, the connector pins are driven by CPU pads GPIO1_IO00 and GPIO1_IO01. And these pins carry signals for I2C1 of the CPU.

So the hardware manual does not fully reflect the complexity of the situation. But the device tree does, as it supports CAN_A as well as I2C_B. Just disable CONFIG_PICOCOMA9X_CAN_A and enable CONFIG_PICOCOMA9X_I2C_B at the beginning of the device tree, and everything should work as expected. There are some sanity checks later in the device tree that make sure that at most one of these functions is actually active.

Edit:

In the past there was also some confusion because the PicoCOM port names as well as the internal CPU ports used numbers. So it was difficult to know if we mean board-standard names or CPU names. In newer specifications like efus and PicoCore, we therefore use letters instead of numbers on our board-standard port names. This was already done in the PicoCOMA9X device tree, so there it is more clear. So CAN_A of the board-standard is implemented by CAN2 of the CPU, I2C_B of the board standard is implemented by I2C1 of the CPU. Unfortunately, the Hardware Manual still uses the numbers, i.e. I2C0 instead of I2C_B and I2C1 instead of I2C_A, which is apparently still confusing, because these are *not* the CPU port names. Actually the old I2C0 board-standard port is implemented by I2C1 of the CPU and the old I2C1 board-standard-port is implemented by I2C4 of the CPU.

Your F&S Support Team

J1_46/52/54 on MM:

It is not important if you don't need LVDS, it is important if the board is built for LVDS. On MM, we are rather short on GPIOs. Some GPIOs are needed to support internal chips, for example the MIPI to LVDS converter for LVDS output. In this case, these GPIOs are not available on the B2B connector at all. Only on those board variants without LVDS converter, these GPIOs are routed to the B2B connector instead. This means this is a hardware option and depends on the board variant that you order.

J1_63

I believe this should be J2_63 because on J1_63 there is GND.

J2_65/67/69/73/75/77/79

Please note the different voltages on MM (3.3V) and MP (1.8V). You may need to add a level shifter to be prepared for both variants. Again on MM, these pins are only available on those board variants where no Security Chip and no CAN is equipped.

I'm not sure if you are aware of this, but you can also use most of the dedicated pins as GPIOs if you do not need that dedicated function. For example if you do not need two SPI ports or even none at all, then you can use the free SPI pins as GPIOs, too. The same for I2C, UART and SD. In fact this may even be more compatible between boards. Because when we design a new PicoCore variant, we try to fill the dedicated functions first and all remaining GPIO pins on the connector are filled with all the remaining GPIOs. Which means there are the most variations from board to board, depending on "what is left over" in each case.

Your F&S Support Team

You just use the device behind it. All I2C handling is done automatically.

For example the RTC is available as /dev/rtc and you'll access it as always with the hwclock command line tool. The RTC value is automatically read when Linux boots, so the time will be loaded without having to do anything. You just have to set the RTC once. Maybe there is more than one rtc device visible in /dev (e.g. the CPU-internal RTC). So the best way to set the time is:

EEPROM is a hardware option. So it may not be available on your device. But if it is, then it is using the regular way of Linux. As far as I remember, this is some sysfs file for reading/writing the data.

Your F&S Support Team

There is a whole set of devices available with the PCA953x driver in Linux. If you look at drivers/gpio/gpio-pca953x.c, you'll find a whole list of devices that are supported by this driver, from additional 4 GPIOs to 40 GPIOs.

Your F&S Support Team

Actually it is the answer, but maybe it was too short.

The i.MX8MP CPU provides six hardware I2C devices. So we use four of them for the external ports, and the fifth and sixth are used as internal I2C buses. So yes, there are such I2C devices like RTC and EEPROM on the module, but you do not see them on any I2C bus that is available and visible from the outside. All four external buses are completely empty. So if you use I2C_C and I2C_D, you will only have those devices that you connect yourself.

This is different to the PicoCoreMX8MM and PicoCoreMX8MN. There the CPU only provides four hardware I2C devices. We need two ports internally, but for slow devices we can use a bit-banging I2C. This leaves three dedicated I2C ports for the outside. And to be able to provide a fourth I2C port, we make one of the internal buses (the bit-banging one) also available as I2C_D. This is why you will see internal devices on I2C_D there. But this is not the case with PicoCoreMX8MP. There you will see no internal devices from the outside as they are on two additional, completely separate I2C buses.

Your F&S Support Team

When you take a look at the GPIO Reference Card, you will see that Pins 95 (PERST) and 97 (WAKE) have a GPIO number, which means these pins can in fact be used as GPIOs. And you will see that the other pins have no GPIO number, which means they cannot be used as GPIOs. This is generally true for all differential signals, they are typically dedicated.

The PicoCore family has not defined any ADC pins. I would recommend using an I2C chip or, if speed is an issue, an SPI based ADC.

Your F&S Support Team

The i.MX8MP CPU offers enough dedicated I2C ports that we could use an own port for all internal I2C handling. This means all four I2C ports that are available on the B2B connector can be used freely and are not shared with other I2C devices.

Your F&S Support Team

Apart from differential signals like USB, MIPI or LVDS, almost all signals of the CPU are multiplexed. So they can serve different purposes. And one of these purposes is GPIO. Other functions depend on the pin. In most cases we use a dedicated function as default. But if you do not need this function, you can use these pins as GPIOs. So for example if you do not need the third or fourth UART port, then you can use these pins as GPIOs instead. Or if you do not need SPI or I2C, then these pins can suit as GPIOs. So the number of GPIOs depends on what other functions you actually need.

Some pins are already defined as GPIOs by us. For example we always provide one or two additional signals in addition to the basic I2C or SPI signals to serve as reset or interrupt. These pins can of course be used as GPIOs, too. Pins 44, 46, 52, 54 are examples for such pins. They are probably the best candidates for your own GPIOs to start with.

Configuration is basically done in the Device Tree. The device tree tells Linux, what devices there are and which pins to use for them. Our default device tree defines all the interfaces that you can see in the hardware documentation. If you do not need some interface or device, then the basic idea is to simply remove those entries from the device tree and configure those pins for GPIOs. For most devices we have already prepared a CONFIG macro that does exactly this. All these macros are defined at the beginning of the device tree. If you don't need a device, simply add two slashes in front of the #define to comment it out. This will disable the device and in most cases, the pins will then automatically fall back to the GPIO setting, which is the default at reset time of the CPU.

Let's do a specific example.

I2C_C provides two signals on pins 40 and 42 of the PicoCore-Connector. You do not need I2C_C and want to use these pins as GPIOs instead. So you edit the device tree file, which is

arch/arm64/boot/dts/F+S/picocoremx8mp.dts

You'll find the following macros near the beginning of the file

Change the line for I2C_C to:

Then save the file, rebuild the device tree and store the new device tree on the board. How this is done is shown in the document "Linux on F&S Boards". Now you can use these two pins as GPIOs. The GPIO Reference Card shows, that they are GPIOs number 136 and 137.

Your F&S Support Team