Posts by fs-support_HK

    In theory you can use the newer toolchain. But we expect problems when compiling the rather old buildroot packages. Newer toolchains have more intelligence when finding errors, for example when inlining functions, detecting the use of uninitialized variables, etc. New software packages typically have fixed these issues, but the old packages may still show the problem, resulting in compilation errors. This may be very difficult to fix manually.


    So we actually do not recommend using a very new toolchain. But you may try a slightly newer version, for example the next version or the version after that. Maybe this is already sufficient for your needs.


    Your F&S Support Team

    You have to enter your serial number. The Recovery Tool will then automatically contact our server and determine the BOARD-ID. You do not have to (and even should not) enter the BOARD-ID manually. A wrong BOARD-ID may make things worse.


    Your F&S Support Team

    As far as I know, the Starter Kit for PicoCoreMX93 will be exactly the same as for the other PicoCores. So on our Website, you can go to Products->PicoCore, select PicoCoreMX8MP for example and then go to tab "Documents", then you can view/download the schematics for the BBDSI baseboard used in our Starter Kits.


    Your F&S Support Team

    As a remark, the line


    Code
    1. Invalidating U-BOOT at offset 0x200000 (block 0x1000)... Done


    is not an error message. It shows "Done" which is a successful result. As you can see, the new U-Boot image is immediately written in the next step.


    We do this to reduce the risk of starting partly written images. Imagine the following case. We write the new U-Boot image, but in the middle of writing, the board power fails, the board is switched off or the Reset Button is pressed. Then only the first part of the image is written to eMMC. Unfortunately the beginning of the image holds all magic numbers that are used to detect the image type. So when the system boots again, it may detect this as a valid U-Boot image and will load and start it. But as the code is not fully written, execution will most probably fail and the system will hang.


    To prevent this, we do the replacement in a different way. We first invalidate the old U-Boot image by erasing the first sector of the image. Then we write everything of the new image but the first sector. And as a last step, we also write the first sector. If we are interrupted inbetween, then the whole image is not seen, causing the boot process to switch to the second copy of U-Boot, which should still be valid. Only if we have written the first sector, too, then the image is found by the boot process. But then we can also be sure, that the whole image is written already. So this is a rather failsafe method that should keep the board in a working state in all cases.


    Your F&S Support Team

    I did some more research. It's as I said. The 64MB flash that was used on PicoCOM4 at the beginning was EOL. So we replaced it with a 128MB flash. The problem is that the original flash used 512 bytes pages, and the new flash has 2048 bytes pages. This requires modifications in the bootloaders and also the OS. For Windows, we did these changes (in NBoot, EBoot and Windows itself), but we never did these changes in U-Boot and Linux. So it looks like that the unmodified old Linux will not run correctly on this new PicoCOM4 version with 128MB NAND flash. I'm sorry.


    On the other hand, PicoCOM4 was one of our first Linux attempts where everything was still rather uncomfortable. You might have been disappointed. So maybe it's better to use a more recent system anyway, where everything is running more smoothly. armStoneMX8MP is definitely suited for that.


    Your F&S Support Team

    Not exactly. The PicoCOM4 U-Boot was rather inflexible when changing the NAND flash type. I assume that we use a replacement flash type in the meantime that is not compatible anymore with the old code in U-Boot.The rather new NBoot implies that there were some changes in the past, which are typically caused by such replacements. But Linux for PicoCOM4 was not updated for many many years, so there is no new code for this new flash type.


    What is your goal with all this effort?


    Your F&S Support Team

    If this Fedora 27 machine is an F&S development machine, then the tftp server should be enabled already. If you are trying to set up your own Fedora machine, then there is a Document Advices for Linux on PC.pdf that explains the steps to configure tftp. The document is actually quite outdated, but the basic principles should still be the same. Maybe the dialogs look slightly different. In Fedora 27, The package manager is now dnfdragora, not yum-extender anymore.


    Please note that PicoCOM4 is out of support and that you can not buy any new boards for Linux anymore.


    Your F&S Support Team

    HDMI is currently not supported in our U-Boot. The idea in U-Boot is to have a pre-configured display setup with one resolution. However when using HDMI, things get rather complicated, because an HDMI display typically supports many different resolutions and provides information about it in the so-called EDID information. EDID needs an I2C connection to the display to download this info and then the info needs to be interpreted, resulting in a very dynamic setting of the display resolution, which is not what we intended with our simple approach. In addition the HDMI controller in the CPU needs to be configured and also Hot-Plug-Detect needs to be supported. So this part was rather complex and we postponed it when we implemented display support for U-Boot.


    In the meantime, U-Boot has already grown to a size that it merely fits into the 512KB slot that we have reserved for it. Even small additions are typically too much and we actually need to disable some features in newer U-Boot versions to keep its size below 512KB. Which means adding more code for HDMI would also prove difficult because there is simply no room for it.


    Your F&S Support Team

    I can explain what happened above in the update process from the recovery.txt log.


    The new NBoot and new U-Boot are downloaded via UUU-Tool to RAM and are started. There in U-Boot, the same (new) NBoot and U-Boot are loaded to RAM again and also saved to eMMC. This is successful. So at this moment, the system is in a stable state and should be capable of restarting.


    Please note that in this version, U-Boot is still stored in the User partition of eMMC. This is important because it is the reason why the next step fails.


    Now the update command is started. This loads the emmc-fsimx8mp.sysimg and writes it to the User-Partition of eMMC. This also includes the section in the partition where U-Boot is located. So if sysimg either does not contain an U-Boot at all or if it holds a different version of U-Boot, then U-Boot is now overwritten by zeroes or with the different (old) copy of U-Boot, which does not match the installed NBoot. So when the update command ends, U-Boot is already corrupted in eMMC and restarting the system would already fail. But as you are in a working U-Boot in RAM, you do not see this right now. So booting Linux actually succeeds. But when trying to reboot later, NBoot (SPL) does not find a matching U-Boot version (or any U-Boot image at all) and fails to boot.


    You could do the same restoration procedure again, just NBoot and U-Boot, not Linux! Then the system should be working again, because then the new U-Boot is again saved. But the main problem is that you must use the same U-Boot in your sysimg. Otherwise you will always kill U-Boot when saving the sysimg.


    In the past, we sometimes changed some stuff in the boot process, either in NBoot or in U-Boot, so unfortunately NBoot and U-Boot were rather dependent on each other, so they needed to be more or less in sync. And the idea of storing U-Boot in the User partition also proved as problematic.


    In the meantime, we have optimized the whole NBoot/U-Boot boot process quite considerably. Starting with the release in September 2023, U-Boot is now stored in the Boot partitions of eMMC, too, and is not part of the User-Partition anymore. Thus writing a new sysimg can not corrupt U-Boot anymore. There are also many other improvements in NBoot and the fsimage command in U-Boot, so we strongly recommend switching to the new release. From now on, NBoot and U-Boot are rather independend of each other, and updating NBoot will only be necessary in very rare cases.


    Your F&S Support Team

    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