Posts by fs-support_HK

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

Our U-Boot already does support showing a display. You do not need to enable anything. See this thread for more information. It is for fsimx6ul, but this works completely the same on fsimx6sx. (Since fsimx6sx-B2019.11).

U-boot Display

Your F&S Support Team

I have moved this thread to the Windows section as it seems to belong there (see WinCE start screen).

Your F&S Support Team

We can not reproduce the hanging boot process with our current software here. Can you tell us exactly what release version you are using? Thanks.

Your F&S Support Team

M.2 SSDs are available as SATA or PCIe (NVME) devices. The PicoCoreMX8MP does not provide a SATA port, so only PCIe would be possible. But it has only one PCIe Gen 3 lane. Typically M.2 SSDs use 2 or even 4 lanes, and nowadays even Gen 4, so one lane will be rather slow. An alternative would be to use eMMC on port SD_A (this port provides an 8-bit interface) or connecting the SSD via USB 3 (up to 5 MBit/s, i.e. USB3.2 Gen 1, a.k.a. USB 3.0).

Your F&S Support Team

Do you have the right settings? 115200 bd, no flow control. Do you use a Null-Modem Cable? Do you use the right UART port on the board. There are some ports that use TTL levels, not RS232 levels, but the debug output is on a port with RS232. If you are using a Serial-to-USB adapter, this also might cause problems.

When using Linux, you should better use a terminal program like Putty or TeraTerm. DCUTerm does not support the terminal emulation commands that are sent by Linux devices to switch text color or bold, italics, etc. Then you see regular output mixed with Escape sequences.

Your F&S Support Team

Of course we take the needs of our customers seriously and we have immediately started working on the Buildroot release. It will take a few days until all builds are done, all the tests are done and the release packages are assembled.

Because of the worldwide shortage of electronic parts, we had to do new revisions of quite a lot of our boards and modules and we are struggling with the amount of release updates that are required as a result. We try to do those releases first that we think are used by the most customers, but this is always just a rough guess. So it is actually very important that the customers tell us their immediate needs so that we can give those releases higher priority. So thanks for telling us. We try to do the release as quickly as possible.

Your F&S Support Team

Ok, I see you are using git in your Linux kernel directory. This has the effect that the kernel version now has a "-dirty" attached. This means that the kernel does not find its modules (on the board) because they use a different path in /lib/modules/<version>. So one dirty trick would be to create a symbolic link there that redirects the new version to the old path ...

If you can not log in, you probably have to reinstall the previous kernel, create the link and then go back again to the new kernel.

Or you also have to rebuild the rootfs with all the modules, so that the module names match again the kernel version. A clean build should be done anyway after you are done with your development, when you have committed all your changes to git and when you build your own final version to be released to your customers. Then all "-dirty" settings should be gone.

Your F&S Support Team

Ok, here is the explanation what happens.

When starting up, the spi-imx.c driver calls a function to register the SPI controller. This function parses the device tree and collects all GPIO chip select numbers in an array. Then when the function returns, the driver calls gpio_request() for each entry in the array so that all these GPIOs can be used as chip selects afterwards.

However the above function does much more than just collecting GPIO numbers. It also parses all sub-nodes in the SPI device tree node and creates a device for each of them. This actually leads to a call of function spi_imx_setup() for each device which is used to set the GPIO direction of the appropriate chip select to output. But as you can see, this happens *before* the original function returns to the probe function, where the GPIOs are requested. So the sequence, that a GPIO must be requested first before it can be used, is violated.

On GPIO1, where other drivers already requested some GPIOs, this nonetheless works because the clock to this GPIO block is already active from the other GPIOs. But on GPIO3, where no other GPIOs are requested by other drivers, this fails because the clock is still off when the output direction should be set. The clock is only activated later by the gpio_request() call.

This made it quite difficult to locate the problem. Of course I immediately thought of the clocks, but after the probe function, when the system is running, the clock to GPIO3 was active, too. So at first I did not understand at all why only the accesses to GPIO3 fail. It needed quite a lot of debug output and many many tries to understand that the clock is still off at the point of time when the GPIO direction is set.

The attached patch will move the gpio_request() from the probe function to function spi_imx_setup(). This fixes the call sequence.

Go to the Linux kernel source directory and call

Please note the less-than character '<' to redirect the input.

Then recompile and reinstall the kernel. Now everything should work as expected. Sorry for the inconvenience.

Your F&S Support Team

Maybe no one in the forum is aware of this problem because they all use our predefined Development Machine where this problem does not exist.

Choosing the right distribution release and setting up the build machine is not as easy as it may look like. First of all, the compilers and other tools must neither be too old, nor too young. They must more or less match the time of the software that is to be compiled. For example the buildroot-2021.02 stuff may be targeted for at most GCC-9.x. So having GCC-10 or even GCC-11 may cause unexpected warnings and errors. Ubuntu 22.04 is rather new and may cause exactly such problems. And yes, I'm also talking of x86-tools on the build machine. The build process also builds some x86 tools and intermediate steps that are needed for the final cross-compilation process.

The next thing is that the build process may need some additional packages installed on the build machine. For example you typically need some devel-packages, i.e. packages that provide the header files for the main package. And you also need additional packages for some tools (e.g. bison, ncurses, etc). This often depends on the configuration that you want to build. On our development machine, we have already installed all the tools and packages that we know are needed for our given configurations. Of course when using your own development machine, you are responsible for installing all these packages.

Unfortunately, the screenshot does not give enough information to locate the problem. The compiler complains about a stray backslash, and we see that the backslash is at the beginning of a line with an #include command. This is strange. Is this already part of the original code or is this the result of some pre-processing, like the C-preprocessor inserting all macros or some code generation step that was run earlier? If this is really in the code, maybe this part of the code is not supposed to be compiled, e.g. because an earlier #if condition should not be true. This could be again the result of some different behavior of newer development tools. Or it is only the result of an earlier error that is the main reason for the build failure.

Your F&S Support Team

We have located the problem. It is a driver thing, rather complicated. Now we are looking for the easiest way to fix it. The patch should be available soon.

Your F&S Support Team

One more thing that is worth a try. In all i.MX8M device trees, NXP is using the value 0x40000 for the SPI chip select pad setting. We simply copied that without thinking too much about it. However when looking at it now, this value is rather strange. It does not match what we know about these pad settings. Typically, this value is the bit combination that should be written to the appropriate PAD settings register in the iomuxc register file. In addition, there are two special bits. If bit 31 is set, then the value should not be modified. This is for signals that are already set earlier, by the bootloader for example, and should not be changed in Linux. And if bit 30 is set, then the SION flag should be set. This bit activates the input branch of the pad, so that the value can be read back. This is necessary for signals that need to read the real pad value for loop-back purposes. This SION bit is actually in a different register, but to avoid having an additional value just for this bit, NXP uses this trick. If bit 30 is set, then the driver will set the SION bit in the other register.

On i.MX8M CPUs, only a few bits in the PAD settings register are actually valid. No bit higher than bit 8 is ever used, so the value can always be represented by at most three hex digits. So the value 0x40000 does not make sense. It does not refer to a valid bit in the PAD settings register, but it is also not one of the two bits 30 and 31, that are handled specially by the driver.

So it might actually be a mistake by NXP. Maybe they copied a value with SION enabled from somewhere else (0x40000xxx), removed the last three digits of the original number (these are the valid bits of the register), but forgot to append three new digits for the new bits. If this assumption is correct, then the PAD settings bits would actually be set to all zero and the unimplemented bit that was set by the 4 has no effect. This would result in a rather weak driver strength of the signal.

So in our point of view, it makes more sense to define an own value here that actually represents the PAD settings register bits. So try to use 0x40000156 instead of 0x40000 in all the pad settings in the pinctrl_ecspi3_cs: ecspi3cs subnode. This will use maximum driver strength, a fast Slew Rate and a weak Pull-up. Maybe this modification does the trick for you.

Your F&S Support Team