Posts by fs-support_HK

    From my point of view when looking at the log, buildroot is using a self-compiled version output/host/bin/fakeroot. Maybe there were some problems when building this host package. Can you try to rebuild this package? For example by removing output/build/host-fakeroot directory (the name may have an additional version number appended) and then doing make again.

    Back then, we always built the fsvybrid versions on a rather old Fedora 14 machine. Trying to build the original fsvybrid-V2.2 release on a Fedora 27 machine right now failed rather early. But I see that you are using a buildroot-2022.11.1, which seems to behave better. Which arm-toolchain do you use? One of ours?

    Your F&S Support Team

    The idea of NBoot is to hide all the low-level stuff from users so that they can concentrate on U-Boot and Linux and do not have to bother about DRAM settings, board configurations and firmwares. So NBoot is basically meant to be compiled by F&S, not by customers. But I can understand the reason for your need to do this. Maybe you can do your modifications in a rather generic way. Then when you are done, and if it's OK for you, we can add your improvements to our regular NBoot. This would save you some work in the future (see below).

    To compile NBoot, you just have to rename bl31.bin from the ATF build to bl31-imx8mp.bin and store it to board/F+S/NXP-Firmware. Please note that we have a slightly modified version of ATF, so start with our github version, not the original one from NXP.

    Then copy the DRAM-FW/Training data to this directory, too. They are part of the firmware-imx package. from NXP.

    For a regular NBoot, you won't need TEE. A Trusted Execution Environment without Secure Boot does not make much sense.

    Of course U-Boot must be configured for fsimx8mp, i.e. make fsimx8mp_defconfig. Then simply call make nboot. This will compile most of U-Boot, then SPL, then all the other sub-images (configurations, DRAM timings, etc:) and finally assembles the NBoot image. Please change NBOOT_VERSION in board/F+S/fsimx8mp/nboot/Makefile to make it different to our releases, e.g. add a prefix or suffix or similar.

    Then install NBoot with fsimage save in U-Boot. Also be aware that if your modifications cause a failure of ATF, so that U-Boot is not started, you have to re-install the software using the UUU tool or our Recovery Tool.

    We are currently in the process of writing a documentation for NBoot that will show all the internal details. But this takes a few more days until it is finished. It will only be availbale on request, so leave me a message if you want it.

    Please note that using your own NBoot has some severe disadvantages. NBoot always handles DRAM and flash initialization. So for example, if a DRAM chip goes end-of-life and we replace it with a different one, we will most probably need new DRAM timings and therefore a new board configuration to support this. So all new boards that are shipped from then on, have the new NBoot preinstalled. But if you replace this version with your own old version, then booting will most probably fail, because your version does not know about the new DRAM timings and board-config yet. In other words, for every change that we do in NBoot, you also have to rebuild your own version of NBoot. This will result in quite a lot more work that you have to do. If you also change stuff in NBoot other than ATF, things may get even more complicated.

    Your F&S Support Team

    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

    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