Posts by fs-support_HK

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

To keep you updated, we are working on it, but strangely enough, it is working here, as far as we can see up to now. Unfortunately it is difficult to test some pins on our baseboard, so it takes a little bit longer to check all your chip selects.

Just one more test. If you move the <&gpio3 1 GPIO_ACTIVE_LOW> to the first position in the CS-Sequence, so that it becomes CS0, does it work then? Of course you have to move the sub-node accordingly to position 0 then. This would show if there is a general problem with the other GPIOs or if only entry 0 will work.

I know we had some modifications in the SPI driver in the past to make this work with more than 1 CS signal, maybe there were some changes when updating to the newer kernel so that there is again something wrong. We have to check this, but the above test would help us in locating the problem.

Your F&S Support Team

Quote from andreas.paulun@i-graphx.com

Perhaps I'm missing a kernel module?

That is also possible. For our boards, we use a rather minimized set of drivers. If you are adding own hardware, you typically also have to activate the driver for it. So in Linux menuconfig, go to "Device Drivers" -> "Industrial I/O support" -> "Digital to analog converters" and activate "Linear Technology LTC2632-12/10/8 DAC spi driver". You can either do this by "Y", then the driver is included in the kernel image, or you can set it to "M", then the driver is built as a kernel module. Then the kernel must be rebuilt and reinstalled. In the latter case, you also have to rebuild your Buildroot/Yocto rootfs to have the new kernel module included.

If you are telling the driver with num-cs = <5> that you use 5 devices, then you also have to define 5 sub-nodes for these devices. If you do not need all devices right now, you can use compatible = "linux,spidev" for the others. We have more than one CS on our efusa9, so see

arch/arm/boot/dts/efusa9qdl.dts

in node &ecspi1 for an example with three CS signals.

Your F&S Support Team

As far as I know, pixels are counted from zero, i.e. starting with an even pixel. Even pixels should be on LVDS channel 0 then, odd pixels on LVDS channel 1. If the result is still showing swapped channels at the end, I believe you can fix this by using LVDS1 as display device instead of LVDS0. Then the even and odd pixels should be swapped, too.

Your F&S Support Team

Yes, this is possible. In the device tree, e.g. armstonea9q.dts, you have the following setting:

So just uncomment the define and then set the full resolution in your LVDS0 timings entry. That's it.

Your F&S Support Team

How is the reboot done? Do you really execute the "reboot" command or do you just switch the board off and on again?

You have to be aware that if you have writable filesystems, you cannot switch the board simply off. Never! You *always* have to shut it down correctly. This is the reason why our default images on our Starterkits typically have a read-only root filesystem. Then switching off the power is possible.

If you switch off filesystems that are in use, then the metadata may not be written back to the real media. Which means if you delete a file, then this is stored in the buffer cache in RAM, but it is not yet written to flash memory. If you simply switch off and on again, then the system had never written this information to the flash and so the file reappears the next time, because the metadata in flash still has the file valid.

A good procedure is to keep filesystems in read-only state and only switch to write mode for the short period of time when you actually write data. After that, switch back to read-only mode immediately again. This is the safest method. Or at least use some form of sync after writing data.

Normally, using reboot should unmount all filesystems before the restart, so all meta data should be correctly saved.

Yes, the conclusion is correct, the i.MX6-Solo-X, which is the CPU on the efusA9X, does not have a VPU and thus there is no hardware acceleration for video decoding available.

Your F&S Support Team

The customer who received the board in the first place got a fully functioning board with functioning software. With the serial number, he also had access to all the necessary source code, even newer versions. By deleting the software and removing all identification features, he wilfully destroyed the board. I find it somewhat unfair that you now draw the conclusion that we, the company F&S, have done something wrong so that you no longer want to recommend us. If someone wilfully deletes the BIOS on a PC and then passes the PC on, it can also no longer be used without further ado. Would this also be the fault of the manufacturer in your eyes?

In addition we have replaced these modules with a newer board revision because there were hardware issues with these 1.00 revisions that are fixed in the new revision. This is a rather common way of doing things. And that a company does not support old revisions, that should not be in the field anyway, is also a completely normal process. So why do you blame us for this non-functioning board? This board is not supposed to exist anymore. A deliberately destroyed board of an unsupported old revision that was not directly bought from the manufacturer cannot be taken as a measure of the quality of this company.

I understand that this is disappointing for your, but what do you expect from us?

All our boards based on i.MX8 need a board configuration that tells the board what variant it actually is, i.e. whether it boots from NAND or eMMC, what size and type of RAM it has, whether WLAN is equipped or not, and so on. This board configuration is stored in flash (eMMC or NAND) and is supposed to always stay on the board and the boot process depends on it. Without this, the board does not know its own identity and hardware settings.

If this configuration is lost somehow, it can be restored, but only if we know exactly what kind of board it is. In such a case, the customer will typically give us the serial number, which is also the MAC address of the board, either by looking at ethaddr in U-Boot, or by looking at the barcode sticker on the module. Then we can determine the right variant. Or he will look at his order, where he has given the specific variant he wants. However as you tell us, all software and all stickers are removed and there is also no other means of identification. So we do not see any option of how we can determine the correct variant of the module. For example if you see eMMC memory, it is not a V3. The V3 would have only NAND and no eMMC.

In addition, the board revision 1.10 is not supported anymore, also the baseboard revision 1.00. They were only temporarily supported in a pre-release software that was available back in 2019. Both, this hardware and this software were only sent to very early adopters of the i.MX8MM platform and they typically received newer variants of both in the meantime.

We also never release schematics of our modules, only from our carrier boards. So here I cannot help you anyway.

You are missing the Root Filesystem. The kernel is complaining that it does not find a valid filesystem, and from the list of your files, the rootfs is also missing.

Your F&S Support Team

The IP address can be saved in an U-Boot environment variable. If you set ipaddr in U-Boot, then you can pass this to the Linux command line so that it is correctly set from the beginning if you do not call DHCP functions. So you can use the same image for all boards and just have to set this variable differently.

Your F&S Support Team

Just to make sure, you actually measure the voltage on the pin, you do not simply read back the value by software? Because in your configuration, you will *not* see the real pin value when reading the value-file in sysfs. To be possible to do this, you have to add 0x40000000 to your hex value, i.e. 0x400030b0. This enables the so-called SION flag which loops back the general purpose output signal to the general purpose input signal. Then you will also see your own output value as input value. By default this is not the case on any i.MX6 CPU.

Also be careful if you actually have the sound Codec still included in your circuit. The default function of this pin is I2S_SYNC. We configure the sound Codec chip to be the clock master, So this signal is an output on the external Codec and an input on the CPU. If the Codec is not properly reset by a power cycle, then the Codec might still drive this line actively. A warm start like calling reboot might not be enough to bring back the Codec to a passive state. So make sure that the line is not driven by some other device.

Your F&S Support Team

Can't you simply create different build directories with different setups? The fact that you have many layers included in your source tree does not automatically mean that you need to include these packages in your configuration.

Or how about this approach: Configure Yocto to build the sum of all packages that you need on any of your targets. Then create recipes for separate rootfs images, one for each of your targets. Each rootfs image only pulls in those (binary) packages of the generic build that are needed on this specific target.

I think this approach has the advantage that most basic packages are actually exactly the same on all targets, reducing the support requirements. For example if one of the packages needs a security fix, you change it once in the source tree and then you can update all targets with one simple rebuild. This will update all rootfs images in one go. Or when moving to newer package versions (e.g. a newer Yocto), you also get an update for all of your platforms in one go.

I only see problems with this approach if the configuration requirements for two targets actually contradict each other. For example if two targets need gstreamer, but one target must support media format X and the other is not allowed to show even the slightest sign of format X. But even then it might be easier to build two different versions of this single package instead of building completely different setup environments.

Your F&S Support Team

Have you enabled the entry "General setup" -> "Initial RAM filesystem and RAM disk (initramfs/initrd) support" in the Linux kernel? For example by calling make linux-menuconfig in Buildroot. It looks like it is not enabled in our default fsimx6sx_defconfig.

Your F&S Support Team

You have to measure the battery voltage while the system is shut off. Only then the battery is actually under load and then the voltage may drop.

Your F&S Support Team

Vybrid Linux Releases V2.2.1 and V2.1.1

We have uploaded two new Linux versions for all boards and modules based on the Vybrid CPU to our server, i.e. the fsvybrid architecture: armStoneA5, PicoCOMA5 and NetDCUA5. These releases are running on all platforms of this architecture at the same time. So you can download the same binaries for NBoot, U-Boot, Linux kernel and Buildroot root filesystem to any of the Vybrid boards and it will run.

Each release consists of two files:

fsvybrid-V2.2.1.tar.bz2 (or fsvybrid-V2.1.1.tar.bz2)

This is the main release itself containing all sources, the binary images, the documentation, examples and the toolchain.

sdcard-fsvybrid-V2.2.1.tar.bz2 (or sdcard-fsvybrid-V2.1.1.tar.bz2)

If you copy the contents of this archive to an SD card, you can install our precompiled standard system in a very straightforward and comfortable way on the board. The SD card archive is meant for people who just want to try a release first without having to download the quite large main archive. Its content is also contained in the main release archive, so if you want to download the main archive anyway, you don't need to bother with the SD card archive.

These tar archives are compressed with bzip2. So to see the files, you first have to unpack the archives

This will create a directory fsvybrid-V2.2.1 that contains all the files of the release.

Please read the file doc/Vybrid_FirstSteps_eng.pdf. It lists the meaning of all files and shows how to install and use everything.

Release Notes

This is a patch release with minor changes.

The 4-wire touch controller that was used on armStoneA5, PicoCOMA5 and NetDCUA5 is end of life and is not available anymore. F&S has therefore replaced it with a newer controller. This results in new board revisions that are now called armStoneA5.2, PicoCOMA5.2 and NetDCUA5.2.

This release adds the new touch driver to the Linux package and modifies the board support code so that the new driver is activated on the new board revisions.

Please note that you only need to take action if you use the on-board 4-wire touch controller. In that case you just have to replace the Linux kernel (uImage), that's all. Everything else can stay as before. However you most probably need a new set of touch calibration data for the new controller.

Please note that compared to the previous release fsvybrid-V2.2 (or fsvybrid-V2.1), just the Linux source package, the uImage binary, install-sources.sh and of course the Readme.txt are updated. And we have included a newer NBoot version. All other files remain unchanged. This means that also all the documents are still the original ones. Please visit http://www.fs-net.de to download the newest documents.

As there were no changes in U-Boot and Buildroot, the new board revisions will still show up as "armStoneA5", "PicoCOMA5" and "NetDCUA5". (without ".2" appended). This makes sure that no existing software will break just because of different names.

-----------------------------------------------------------------------------------

The following list shows the most noticable changes in this release in more detail since our last Vybrid release fsvybrid-V2.2 (or fsvybrid-V2.1). Please note that the source code is partly also used for other platforms. This is why you will also find references to other CPU types and F&S boards here in the changelog. Some of these changes have already been part of other releases for other boards.

nbootvyb115_15.bin (VN15)

Supported Boards: PicoCOMA5, armStoneA5, NetDCUA5, CUBEA5, PicoMODA5, PicoMOD1.2

NBootVybrid - V10 (Released 2014-07-11)

- 0002342: Change UART debug port for PicoMOD1.2

NBootVybrid - V11 (Released 2014-09-01)

- 0002342: Add external clock detection for enet phy's

NBootVybrid - V12 (Released 2014-12-05)

- Change to new compiler

- Reorder structure for less warnings

- Add support for new F&S MfgTool

- Add support for some customer specific boards

NBootVybrid - V13 (Released 2015-08-12)

- 0002715: Remove non working serial number string descriptor

- 0002716: Change stack layout

- 0002717: Add customer specific power LED init

- 0002718: Enable spread spectrum for all boards

- 0002719: Change memstest stepsize for better test coverage

- 0002720: Add customer specific serial number fuse settings

- 0002721: Add serial number invalidation check

- 0002722: Change customer specific IOMUX init

- 0002723: Add customer specific LED functions

NBootVybrid - V14 (Released 2017-04-03)

- 0003188: Move printf() to from uart.c separate file

- 0003189: Longer delay for 'x' and 'r'

- 0003190: Use nand debug menu from iMX6

- 0003191: Add USB MSD flash down-/upload for debug purpose

- 0003192: Initialize g_cCommand to 0

- 0003193: Change USBD init routines

- 0003194: Use blx instead of bx for printf call in abort handlers

- 0003195: Change memtest to check all memory locations

- 0003196: Remove unused DCACHE code

- 0003197: Add check for MMU tabele corruption in USBD DMAdescriptor setup

NBootVybrid - V15 (Released 2019-07-26)

- 0003995: Add password protection option

- 0003996: Add ECC check after startup

- 0003997: Improve bootdevice detection

- 0003994: Improve DDR initialization sequence

u-boot

- No changes

linux-3.0.15-fsvybrid-V2.1.1 (15.10.2021) (relative to fsvybrid-V2.1)

Supported Boards: armStoneA5 (incl. armStoneA5.2), PicoCOMA5 (incl. armStoneA5.2), NetDCUA5 (including NetDCUA5.2)

- Add support for 4-wire-touch controller TSC2004

- Add support for PicoCOMA5.2, NetDCUA5.2, armStoneA5.2

- On armStoneA5, fix pendown state on local SX8655 touch

linux-3.0.15-fsvybrid-V2.2.1 (21.10.2021) (relative to fsvybrid-V2.2)

Supported Boards: armStoneA5 (incl. armStoneA5.2), PicoCOMA5 (incl. armStoneA5.2), NetDCUA5 (including NetDCUA5.2)

- Revert uevent helper to /sbin/hotplug on cubea5_defconfig

- On armStoneA5, fix pendown state on local SX8655 touch

- Add support for 4-wire-touch controller TSC2004

- Add support for PicoCOMA5.2, NetDCUA5.2, armStoneA5.2

buildroot

- No changes

Examples

- No changes

Toolchain

- No changes

Documentation

- No changes

Your F&S Support Team

The basic idea is to go to NBoot, erase everything with 'E', download the Linux bootloader U-Boot and save it to the board. Then start U-Boot and install the remaining Linux images. You can download precompiled images from our website, this is the sdcard tar archive. If you unpack the archive and save the contained files to the top directory of a USB stick or SD card, U-Boot can install them automatically. Finally you have to set the MAC address by saving it to environment variable ethaddr, and if you have two ethernet ports, the next higher address to eth1addr. The MAC address is on the barcode sticker on the module.

The whole process of installing Linux is explained in detail in the documentation NetDCUA5 Linux First Steps. For working with Linux in general, there is a documentation Linux on F&S Boards. But please note that the Linux on NetDCUA5 (Vybrid) is quite old and some features mentioned in the latter documentation may not be available there. So this is not really representative for a current Linux system on a current F&S board (i.MX6, i.MX8). So maybe evaluation of Linux for a new project should better be done on a more up-to-date board.

To actually work with Linux, you have to use a Linux PC or at least a Linux virtual machine. We have a document Advices for Linux on PC that tells how the Linux machine can be configured. We also have predefined development VMs for Virtual Box that make this step rather simple. Again you need a rather old machine for the old Linux, so I would take the Fedora 21 machine. Then you have to download the main release tar archive, that is also available on our website next to the sdcard archive. The newest release at the moment is fsvybrid-V2.2, but there will be a version fsvybrid-V2.2.1 soon with some fixes for newer board revisions. This archive contains the Linux source code, documentation, toolchain, examples and also the precompiled images. This is needed to build your own applications and system environment.

Going from a Windows board to Linux and back to Windows is possible. Just go again to NBoot, erase everything with 'E', download EBoot, save it and then you are back again in the Windows environment. However buying a Linux board and converting it to Windows is not legally possible because Linux boards have no Windows license.

Your F&S Support Team