Posts by BrenkeM

To patch the kernel we can simple follow one of the tutorials online (see [1]).

But for the kernel version 4.9.88 we can not find a matching rt patch. But a older one is working nice for this issue, see [2].

This will patch the kernel ready for compilation, but it is recommended to adjust the realtime priorities, see [3] for this. Otherwise a realtime application can sporadically block your system.

I also attached both patches for every one how wants to use it.

RT_patches.zip

[1]:

https://stackoverflow.com/ques…rt-linux-patch-for-ubuntu

[2]:

https://mirrors.edge.kernel.or…atch-4.9.84-rt62.patch.gz

[3]:

https://stackoverflow.com/ques…td-in-linux-with-rt-patch

Detailed information about PREEMPT RT can be found in the presentation here:

https://chemnitzer.linux-tage.…shortpaper/517-slides.pdf

To handle application in the Linux userspace in hard realtime the current LINUX kernel 4.9.88 must be patched.

This is because LINUX does not include all realtime patches from the PREEMT RT version (which is the preferred realtime implementation from LINUX Kernel developers). Newer kernel will less differ from a fully PREEMPT RT kernel version.

So, how do we have to patch the Kernel from the efusA9X release to gain full realtime support?

To use the ads1118 ADC IC via an SPI interface with the current efusA9X kernel (4.9.88) it is necessarry to add a driver to the kernel space.

After some research I found a kernel driver implementation under [1]. I collected all information (code+docs) and implemented them into the current kernel with the attached patch under [2]. After adding the node to the device tree (convertig spidev to adc node (see [3])), I testing the driver successfully for a half day.

@F+S: I request to implement this patch to your kernel sources.

Best regards.

[1]:

https://lore.kernel.org/patchwork/patch/698694/

[2]:

0001-add-support-for-adc-ads1118.patch.zip

[3]:

I also would like to request that the adc nodes in the device tree will be configurable through macros like other hardware too.

Please patch also the device tree also on your (F+S) side.

P.s.: Sorry but I need to rename the patch file because the website is not accepting a file suffix like "patch":

$ mv 0001-add_adc_node_control.patch.txt 0001-add_adc_node_control.patch

Hello,

I just want to share my investigation regarding the ADCs and how I got it working:

[1] provides a overview about the ADCs numbers, channels and devicefiles. The kernel support can be enabled via [2] and [3] provides a overview about the devicefiles in the filesystem. To calculate the voltage on the pin, see [4]. Furthermore, I contacted F+S to produce efusA9X modules with the missing parts. Until the production will be adjusted please take a look at the attached picture and [5], which provides the information what resistor network IC is missing and where it needs to be placed. Hopefully the efusA9X module will be updated soon.

@F+S: Please check if everything here is correct and please tell us know when the production was adjusted.

[1]:

[2]:

[3]:

[4]:

[5]:

Quote

Hallo Herr Brenke,

unten im Bild habe ich Ihnen rot das zu bestückende Bauteil markiert. Gerne können wir Ihnen dazu passende Widerstandsnetzwerke zukommen lassen. Andernfalls gibt es das Bauteil z.B. bei digikey:

https://www.digikey.de/product…AT10-000J4LFCT-ND/3592947

Das zukünftige Bestücken des Bauteils habe ich mir nochmals notiert und werde dies nächste Woche mit unserem Vertrieb abklären.

Display More

Hello,

I noticed that if I strip down the "fsimx6sx_min_defconfig" I am limited of the filesystem size to 7110656 bytes, when I am using buildroot.

So for example I create a system and load it to check the disk free space: I see that I only use 5.1 MB (see [1]). But the created and loaded ubifs image is bigger than this (~7 MB, see [2]).

Does this have to so with the options:

BR2_TARGET_ROOTFS_UBIFS_LEBSIZE

BR2_TARGET_ROOTFS_UBIFS_MINIOSIZE

BR2_TARGET_ROOTFS_UBIFS_MAXLEBCNT

I also checked the docu under [3], but could not find a suitable answer. For example how can I create a ubifs image that takes only 3 or 4 MB of space?

[1]:

# df -h

Filesystem Size Used Available Use% Mounted on

ubi0:rootfs 214.1M 5.1M 209.1M 2% /

…

[2]:

$ du -b output/images/rootfs.ubifs

7110656 output/images/rootfs.ubifs

[3]:

https://bootlin.com/blog/creating-flashing-ubi-ubifs-images/

Hello,

I would like to test all four ADC channels (ADC_D, ADC_C, ADC_B, ADC_A) of the efusA9X module. So far I checked the adc example and the device tree. According to the example the ADC will be handled via device files (/dev/mvf_adc.?). But I could not find these in the sysfs. [1] and [2] shows some device tree nodes. [2] tells me that the ADCs are already in use for some other functions. But [1] does not create the missing decive files in the sysfs.

What I am missing is a example of a device tree node to inform the kernel about the ADCs. Is there already an example for this or how do I get the device files into the sysfs?

[1]:

[2]:

I was playing around with the sysfs and found in the hardware monitoring class the information under [1]. The defined critical temerature for the "imx_thermal_zone" is set to 85°C, which corresponds with my measurings.

But its not possible to define the critical CPU temperature by my self (see [2]). Who is definig this temperature and how can it be set?

[2]:
# echo 95000 > temp1_crit
-sh: can't create temp1_crit: Permission denied

[1]:
/sys/class/hwmon/hwmon1:

# cat name
imx_thermal_zone

# cat temp1_input
47212

# cat temp1_crit
85000

Hello FuS Support Team,

according the current documentation and example programs does not support a FreeRTOS ethernet communication on the Cortex-M4.
According [1] NXP, ethernet is supported on FreeRTOS (Cortex-M4). FreeRTOS it self includes a TCP/IP stack, see [2].

Is the support for ethernet on the Cortex-M4 planned for the next release or are there any examples so far?

[1]:
https://www.nxp.com/webapp/con…8RW1-16#auvp-overview-tab

[2]:
https://www.freertos.org/FreeR…eRTOS_Plus_TCP/index.html

Hello FuS Support Team,

I performed some thermal measurings on the efusa9x and noticed that the CPU is reducing its clock speed from ~1GHz to ~200MHz at ~85°C.
On the other site I also noticed that the CPU is performing a restart at ~105..110°C.

Can you please conform this measurings and tell us how to define the temperature when the CPU is reducing the clock speed to cool down.

Thanks.

Indeed. That is the solution.

Thanks again for your help. You guys did a great job.

[1] shows the only change from my side regarding on modul nand flash in the F+S uboot sou res. I made a test and yes: If UBootEnv is 'rw' the bootloader is not able to access the nand flash. If I change the mode back to 'ro' my bootloader is working and can access the nand flash.

Can you confirm this behavior on your side to?

[1] in include/configs/fsimx6sx.h:
/* Define MTD partition info */
#if CONFIG_SYS_MAX_NAND_DEVICE > 1
#define MTDIDS_DEFAULT "nand0=gpmi-nand0,nand1=gpmi-nand1"
#define MTDPART_DEFAULT "nand0,0"
#define MTDPARTS_PART1 "fsnand1:256k(NBoot)ro\\\\;fsnand0:768k@256k(UserDef)"
#else
#define MTDIDS_DEFAULT "nand0=gpmi-nand"
#define MTDPART_DEFAULT "nand0,1"
#define MTDPARTS_PART1 "gpmi-nand:256k(NBoot)ro,768k(UserDef)"
#endif
//#define MTDPARTS_PART2 "256k(Refresh)ro,768k(UBoot)ro,256k(UBootEnv)ro"
#define MTDPARTS_PART2 "256k(Refresh)ro,768k(UBoot)ro,256k(UBootEnv)rw"
#define MTDPARTS_PART3 "8m(Kernel)ro,1792k(FDT)ro"
#define MTDPARTS_PART4 "-(TargetFS)"
#define MTDPARTS_STD "setenv mtdparts mtdparts=" MTDPARTS_PART1 "," MTDPARTS_PART2 "," MTDPARTS_PART3 "," MTDPARTS_PART4
#define MTDPARTS_UBIONLY "setenv mtdparts mtdparts=" MTDPARTS_PART1 "," MTDPARTS_PART2 "," MTDPARTS_PART4

Yes. It is only a modified version of the original F+S uboot image. I tried not to change any FLASH related options (only make UBootEnv rw). But my image only access the nand flash when I use the enviroment on the original uboot image from F+S.

As you can see in [1] there is no difference in variable mtdparts. The command "mtdparts" shows the same behavior as you can see in [2].

[1]:
myUBOOT:
mtdparts=mtdparts=gpmi-nand:256k(NBoot)ro,768k(UserDef),256k(Refresh)ro,768k(UBoot)ro,256k(UBootEnv)rw,8m(Kernel)ro,1792k(FDT)ro,-(TargetFS)

F+S UBOOT:
mtdparts=mtdparts=gpmi-nand:256k(NBoot)ro,768k(UserDef),256k(Refresh)ro,768k(UBoot)ro,256k(UBootEnv)ro,8m(Kernel)ro,1792k(FDT)ro,-(TargetFS)

[2]:

Hello gentleman,

I made some changes in uboot. But nothing regarding the flash nand memory (to my way of thinking). But afterwards I can not access the nand flash any more. I also checked the original uboot from F+S and compared the sourced and enviroment variables. My modified UBootEnv can be seen under [1].

I also noticed that some variables are not there anymore (see [2]). But when I set them and try to work with the nand flash they disappear and I get the following error:
unexpected character 'r' at the end of partition

What variables needs to be set to access the nand flash memory?

Thanks so far.

[2]:
mtddevnum=0
partition=nand0,0

[1]:

Finally, the release is out and I am happy.

The documentation provides clear instructions and after building the new image and bootloader with the examples, every things works fine.

Thanks so far.

END.

But coreutils increase disk usage about 1 MB.

better option:
updated busybox to version v1.26.2 (contains fix for stty)

The source of the UART baud rate problem was the stty command of the used busybox- tools (v1.24.2).

A work a round to fix the problem was to install the coreutils including stty that smoothly did the job.
buildroot:
-> Target packages
-> Show packages that are also provided by busybox
-> coreutils

Furthermore, I initiated a bug report @ [1] to get the busybox tools fixed.

[1]:
https://bugs.busybox.net/show_bug.cgi?id=10456

------------------------------------------------------
P.s.: How can I close this issue?

I also checked the supported baud rates in my setting up to 4 Mbps:

Hi,

I also checked the UART CLOCK SPEED for all serial interfaces on the SKIT:

All activated UARTs, from the F+S image, works with 80 MHz.