Posts by fs-support_HK

    NBoot ist not meant to be built by customers. Which is why there is no mannula how to do this. Nboot releases are done by F&S and all the NBoot version can always beo found in the F&S download sections. Each board is already shipped with a matching NBoot.


    The reason is this: NBoot contains information about the board variants and parts that are mounted. If for example a DRAM chip goes end of life, then we can prepare a new variant with a replacement DRAM chip. So when you get the next shipment, there will be an NBoot installed on the board that can handle the new DRAM chip and you will notice no difference. But if you install your own NBoot version, then this is most probably not aware of the new DRAM chip yet. So the boot process may fail or the board will be instable due to wrong DRAM timings.


    Of course the next regular Linux release will again hold all NBoot code to support the new DRAM chip. But this release may come out significantly later. NBoot releases are basically independent from Linux releases and may also happen between regular releases.


    And here is another important rule: never downgrade NBoot to a version before the one that was shipped with the board. This may cause the same problem as above, tand the board may fail to boot are may behave strangely.


    Your F&S Support Team

    Maybe it is a good idea to reset the environment with env default -a when updating U-Boot and then set your own variables again after that. Then you have all variables that were added (or removed) in the new version. However you have to take care of two things in this case:

    1. The network addresses (eth*addr) have to be preserved in this case, for example by exporting them to RAM first with env export, then resetting the environment, and then importing them again from RAM with env import.
    2. Some variables have the value "undef" after resetting. They will only get their board-specific values at the next start.

    Your F&S Support Team

    Thanks for the information. We have also seen this strange behavior ourselves not long ago. We then analyzed this problem and found a solution.


    This is actually a regression that NXP introduced in a recent modification of the ARM Trusted Firmware (ATF). In the shutdown function, which is part of ATF, NXP unconditionally enables the alarm clock before shutting down the power. This is meant for cases, where the system should start up at a specific time, i.e. the alarm time.


    Activating the alarm clock in such a way obviously assumes that the chip-internal SNVS Real Time Clock (RTC) is used and the alarm is configured correctly. However on F&S boards and modules, there is an external RTC chip and the internal SNVS RTC is not used at all. Therefore the alarm is also not initialized. And right from the start, there always seems to be a pending alarm latched in a register. We assume that this happens when the system is powered on and the internal RTC time value as well as the alarm time value are both reset to zero. In this one second, before the RTC begins to count, there is a match between time value and alarm value, causing the alarm pending bit to be set.


    When the regular SNVS RTC driver initialized the internal RTC including the alarm value, it will also clear this pending bit. But as this driver is not started on F&S boards, this does not happen. So when the system is switched off, the alarm pending bit from the beginning is still active and immediately wakes up the system again. This is the behavior that you experience. Even after a reboot, this pending flag remains set, because it is part of the SNVS-powered domain that keeps its contents also across reboots. So the alarm is triggerd each and every time the system is shut down.


    In the meantime, we have improved the shutdown procedure in ATF, so that the power-off sequence should work again. On fsimx8mp, ATF is actually part of our NBoot, so you basically need a newer NBoot. There will be a new fsimx8mp release in a few days. At that time, we will also upload a new NBoot version that should fix this issue.


    Please note that the armStoneMX8MP is not designed for a real standby mode because the ONOFF-pin of the CPU is not connected to a button. This signal would be needed to switch on the device again after a poweroff command. Also pressing Reset will not work. So you really need a full power cycle of the external +5V supply to restart the board.


    Your F&S Support Team

    Yes, the position is exactly the place where the CRC would be located. Did you do a clean rebuild after installing the crc32 program? Maybe some intermediate file from an earlier build was not rebuilt after the crc32 tool was installed.


    Your F&S Support Team

    By default only a Parallel-RGB display is active. You have to change a few device tree macros to switch to HDMI. In arch/arm/boot/dts/armstonea9r3q.dts (quad core) or armstonea9r3dl.dts (single/dual core) there are some comments with instructions of how to configure the displays. In the easiest way you simply need to change CONFIG_ARMSTONEA9R3_MXCFB0 from DISPLAY_LCD to DISPLAY_HDMI (and of course recompile and reinstall the device tree).


    Most customers only need one display. If we activated several displays in parallel, the framebuffers would also be set up and the display data would be transferred to the (non-existent) displays nonetheless, causing quite a lot of load on the system bus and increasing the power usage. And most users would not even be aware of this.


    Your F&S Support Team

    In our current flash layout, U-Boot is located in the BOOT partitions of the eMMC. So no U-Boot image is required in the sysimg with the root filesystem. This was different in the past but we think it is easier to handle this way.


    Please note that if you want to update from an earlier version where U-Boot was still located in the User-Area of the eMMC (pre 2023.09), you have to follow a specific update procedure. Our update script as provided with the current releases should take care of this. The basic idea is to first update U-Boot with fsimage save, because only the newer U-Boot is capable of handling old and new variants of NBoot/U-Boot combinations. Then restart the board so that this new U-Boot is actually active. Then update NBoot with fsimage save. In this final step, U-Boot is automatically relocated to the BOOT partition.


    Your F&S Support Team

    There was no device tree back then. So you cannot extract the data from it. The resolution and timings were given as C-code in some struct in the board support file and is now hidden somehwere deep inside the large kernel image (which is gzipped, too, so no chance to find it). You need the source code from back then. Or try to create new timings from the data sheet of the display.


    Your F&S Support Team

    In the past, Linux did not use device trees. There used to be a board support file directly in the kernel that defined the devices that were available on that board. So there was one board support file for each board. This was very inflexible and required recompilation of the whole kernel if some device parameters like display resolution or timings changed.


    In later kernels, the hardware description of a board was moved to the device tree. So now the device tree defines what hardware is available on the board and we only need a board-specific device tree file. The kernel can remain unchanged all the time. The switch to device trees on the fsimx6 architecture was done with the V3.0 release, hence the new major version number.


    If you look at the device tree file armstonea9q.dts, you can see at the beginning some settings that you can change. Specifically the display configuration can be defined/modified there. You can define what displays (up to four) you actually use (CONFIG_ARMSTONEA9_MXCFB<n>) and what display parameters should be used for each of the displays (for example CONFIG_ARMSTONEA9_LVDS0_*). There are quite some long comments that should explain what you need to set. Then you have to recompile the device tree and install the new dtb file on the board.


    However NXP was not very consistent when doing the switch to device trees. So the settings for LVDS and HDMI are completely done in the device tree, but the settings for the RGB-Interface are given in the device driver in file drivers/video/fbdev/mxc/mxc_lcdif.c. There are several settings provided (see the array lcdif_modedb at the beginning of the file) and you simply select one of the predefined settings by giving the Mode String, for example:


    CONFIG_ARMSTONEA9_LCD_MODE_STR "LCD-ET070080"


    Usually you can use one of the given timings. Only if your display has completely different settings, then you need to add a new entry to this table using a new Mode String, and then you have to recompile and reinstall the kernel, too. Of course you have to use this new Mode String in your device tree then.


    Your F&S Support Team

    The board name is available in variable $platform in U-Boot. See chapter 5.6.2 in the Linux-on-F&S-Boards documentation:


    https://www.fs-net.de/filelice…fileid=11938&locale=en_US


    There is even the variable $bootfdt that typically holds the name oft the right device tree to load.


    Unfortunately the board revision is not available in U-Boot as a variable. It is known internally, but we do not set a variable with it. In Linux, it is available under /sys/bdinfo/board_revision. So either you can try to stay with one device tree and make the differences later in Linux, or you have to manually set an according variable in U-Boot when you install the board. For example directly set variable boardfdt to the right device tree name, depending on which board revision you are on.


    Your F&S Support Team

    On LInux-Boards, NBoot can only be updated within NBoot itself. You can either use NetDCU-USB-Loader to download NBoot via USB, or you can use command 'd' to download NBoot via the serial line.


    NBoot is already pre-installed on the board and can typically stay in the installed version. Why do you think you need to update it? Please note that you only should upgrade NBoot to a newer version, never downgrade to a version before the one that was shipped with the board. Otherwise the board may fail to boot.


    You can also update U-Boot in the same way within NBoot, but U-Boot can also be written from U-Boot. In fact the main update process is typically done in U-Boot. We have added an install/update/recover mechanism to U-Boot that can be used for this. So the common way of doing an update is to put all the files, including an update-script, on a USB device, insert the device on the board an call the update command in U-Boot. Then the script is loaded an executed, which in turn installs the software. If you did not change the U-Boot configuration, this is even done automatically when you boot the board, so the software can be installed/updated without any interaction.


    For detials please see see chapter 6.4 in the Linux-on-F&S-Boards document:


    https://www.fs-net.de/filelice…fileid=11938&locale=en_US


    Your F&S Support Team

    The i.MX8M-Mini does not provide an internal CAN-Controller. So we have added a separate CAN-Controller that is connected via SPI to the i.MX8M-Mini. So on all those board variants, where the CAN-Controller is available, SPI_C is internally used for the CAN controller and the pins J2_83/85/87/89 are not connected. On PCoreMX8MM-V5-LIN and also PCoreMX8MM-V6-LIN, the CAN-Controller is present, which means that the pins on the connector are not available.


    Your F&S Support Team

    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