Posts by fs-support_HK

    NAND flash is no ROM. After many many millions of read cycles, the charge of the NAND cells has decreased considerably and single bits may flip. Typically, the ECC can correct these bit flips, so it does not matter. The code that we are looking at is dealing exactly with this part. There are bit flips in a page, but they can be corrected by ECC. So the function should detect the bit flips, but as long as they are under a certain threshold, it will still report the page as OK (error 0). If it exceeds this threshold, the page read returns a specific error -EUCLEAN. This means the page had bit flips, that could be corrected, but the upper layer should take care of this, for example by refreshing the page. Refreshing means, the page is erased and written again. Then all NAND cells in this page have the full charge again and all bits should be read correctly afterwards.

    Of course real I/O errors should also be reported to the caller. This is the if (ret < 0). If there is a real error, indicated by a negative value, then the loop breaks and returns immediately. Normally, the return code is zero in all other cases. But not here. The read functions return the number of flipped bits. So even a single flipped bit will be returned as one. This is OK if it happens in a page somewhere in the middle of the loop. But if the flipped bit happens to be in the last page handled in the loop, then this value 1 is passed through to the end of the function and is finally returned. But this has the meaning of "one uncorrectable bit flip", which is a wrong information. So the upper UBI layer handles this (correctly) as a real error, which it isn't. So we need to set the ret value to zero after the if comparison.

    So yes, it does affect you, because there are also bit flips in read-only scenarios.

    Your F&S Support Team

    This is really strange. Is the log from the same board as the picture? Because in the picture, block 141 is bad, but in the log file it is block 147.

    The error message from the log shows error 1 in ubi_io_read(). Which means that mtd_read() returned 1. Errors are typically negative values, so a positive value is rather strange. I have followed back the code and if I'm not wrong, then the return value comes from function nand_do_read_ops() in file drivers/mtd/nand/nand_base.c. But when I look at the current code, I can not see how it can ever return a value of 1.

    Which release is your kernel based on? Kernel 3.0.15 is either release fsimx6-V2.0 or fsimx6-V2.1. There was one fix in the NAND driver between these two versions that could actually be an explanation for this error if you are still on fsimx6-V2.0. So can you have a look at function nand_do_read_ops() in file drivers/mtd/nand/nand_base.c. There is a comment line

    /* Transfer not aligned data */

    Please check if the line above this comment shows

    ret = 0;

    If not, then please insert this line before the comment line, recompile the kernel and install it on the board in U-Boot. Maybe this will solve your problem. Just install the kernel, then it should be capable of reading your UBI even with the bad block.

    Your F&S Support Team

    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

    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

    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).…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...…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:

    1. /* CLKREQ optionally on pin 14 */

    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.


    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.


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


    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:

    1.  for rtc in /dev/rtc?
    2.  do
    3.      hwclock --systohc --rtc $rtc
    4.  done

    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