Hi,
i rechecked the BBDSI and without the HW fix there is no luck to get the pcie bus running. With the fix the pcie bus can get up the link and work successfully.
Thanks for the support.
CASE CLOSED.
Hi,
i rechecked the BBDSI and without the HW fix there is no luck to get the pcie bus running. With the fix the pcie bus can get up the link and work successfully.
Thanks for the support.
CASE CLOSED.
Thanks for the response and indeed:
The asmedia AMS1061 chip is not even detected on the PCIe bus (see #9; but we currently only have the modified PCoreBBDSSI REV1.40 (2021) with the manually placed 100nF capacitors in the TX line).
What step would you recommend next:
1. Get the DELOCK 95265 Gigabit LAN Mini PCIe Card and test with the existing (but old) PCoreBBDSSI (REV1.40)?
or
2. Try to link the existing PCIe card (asmedia AMS1061) with the latest version of the PCoreBBDSSI?
Hello ladies and gentleman,
can you please tell us, which other PCIe cards where working on your side? Just to verify the bus on our side.
QuoteOther PCIE cards seem to work.
Hello,
there is definitely a difference. As seen in [0] the kernel 6.6.69-F+S is loaded and even with an empty PCI slot (no externel hardware) the bus came up (see [1]) and is showing the DWC_usb3/PCIe bridge from Synopsys, Inc. (see [2]).
But no SATA adapter can be detected. We will now try to detect the development PCI board we need for your project.
Will there be a update of your buildroot repo with this kernel (no matter if pre-release or release)?
Best reagrds.
[0]:
[1]:
[2]:
Hello gentleman,
regarding the used adapter board I can provide the following link: Syba Mini PCI-Express SATA 3 Expansion Controller Card FG-MST02A
This board is equipped with the following chip: asmedia AMS1061
The needed kernel driver is called: SATA_SIL24
Hello gentleman,
your hardware service had a hard time to insert two Cs into the lines mentioned. But is was achieved.
Nevertheless, we get the same error. No change.
Will the latest PicoCoreBBDSI board fix this issue and successfully rise the link up (which version do you recommend)?
Correct,
The PicoCoreBBDSI is what I mean by SKit (StarterKit) : see https://fs-net.de/de/embedded-…rkit-picocoremx8mp-linux/
In my case its a PCoreBBDSSI REV1.40 (2021).
This issue seems to be related but does not provide a solution: https://community.toradex.com/…ed-on-imx8mp-verdin/24332
The same error here: Solved be a hardware fix (see https://community.nxp.com/t5/i…VDD-PCIE-DIG/td-p/1611728).
Hi,
based on the latest release (fsimx8mp-Y2024.07.tar.bz2) : I was building the firmware via yocto with the core-image-minimal option for the PicoCoreMX8MPr2 (see [0] and [1]).
I was successfully able to start and run the firmware. But I am not able to successfully use the PCI bus of the SKIT (see [2]). I connected a PCI/SATA adapter which is working fine on the efusA9Xr2 module (one lane per PCI bus). But with the PicoCore I am not able to see the ID on the bus (see [3]). I also checked the DeviceTree to enable the PCI bus.
What needs to be done/configured to successfully link the module PCI bus to external devices? Thanks.
[0]:
[1]:
[2]:
[2]:
Thanks for the reply.
I checked the options and decided to go for the buildroot toolchain. With the simple changes unter [1] the image was build with buildroot 2023.02.6 with the Linux kernel version 4.9.88.
Before the F+S toolchain version 8.3 was needed (11.2 was available), but buildroot was able to build the image with 11.4.
Thanks. CASE CLOSED.
[1]:
$ git show configs/fsimx6sx_min_efus_defconfig
commit bd2cebbf2fd03b439aae5836434b40ef0e7cb627 (HEAD -> STACC-LoadMuxer, origin/STACC-LoadMuxer)
Author: Maik Brenke <maik.brenke@continental-corporation.com>
Date: Mon Dec 9 16:43:03 2024 +0100
adjust kernel config to old version; set toolchain from ext. to int.; add note to README
diff --git a/configs/fsimx6sx_min_efus_defconfig b/configs/fsimx6sx_min_efus_defconfig
index 1da90b69..6d59e5eb 100644
--- a/configs/fsimx6sx_min_efus_defconfig
+++ b/configs/fsimx6sx_min_efus_defconfig
@@ -3,15 +3,7 @@ BR2_cortex_a9=y
BR2_ARM_ENABLE_NEON=y
BR2_ARM_ENABLE_VFP=y
BR2_ARM_FPU_NEON=y
-BR2_TOOLCHAIN_EXTERNAL=y
-BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y
-BR2_TOOLCHAIN_EXTERNAL_PATH="/usr/local/arm/toolchain-armv7ahf"
-BR2_TOOLCHAIN_EXTERNAL_CUSTOM_PREFIX="arm-linux"
-BR2_TOOLCHAIN_EXTERNAL_GCC_11=y
-BR2_TOOLCHAIN_EXTERNAL_HEADERS_5_15=y
-BR2_TOOLCHAIN_EXTERNAL_CUSTOM_GLIBC=y
-# BR2_TOOLCHAIN_EXTERNAL_INET_RPC is not set
-BR2_TOOLCHAIN_EXTERNAL_CXX=y
+BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_9=y
BR2_TARGET_OPTIMIZATION="-pipe"
BR2_CCACHE=y
BR2_OPTIMIZE_3=y
@@ -26,7 +18,7 @@ BR2_ROOTFS_OVERLAY="rootfs_overlay"
BR2_ROOTFS_POST_BUILD_SCRIPT="board/f+s/fsimx6/finalscript_min-fsimx6sx"
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
-BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="5.15.131"
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.9.88"
BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="Kconfig"
BR2_LINUX_KERNEL_DTS_SUPPORT=y
Hello again,
can you please update the status regarding:
QuoteWhat we are already planning, is hosting a git repository with the defconfig files of the toolchains and adding the binarie files as github releases, hosted on our SFTP servers.
On the otherside I noticed that the provided F+S toolchains are a combination of release and kernel (header files).
For some special projects we need to pair new projects with older kernels, e.g. toolchain 11.2 with the kernel 4.9 (all from the F+S universe).
Can you please provide the steps to compile the toolchains that are delivered with the F+S releases. Please include also the sources (links).
I would like to finish this in CW49. So please give me a fast feedback.
Thanks for your help.
Hi. I checked the CPU load, but as you can see in [1]: There is no average increase. Maybe its just a momentary high load, while running the example.
But thanks for the commit research. I will check the kernel code and tell the results.
[1]:
# uptime
01:55:12 up 1:55, load average: 0.06, 0.04, 0.00
# ./serial_gateway
imx-sdma 20ec000.sdma: All bds consumed,restart now.
ADR: 0x02; LEN: 0x1C; DATA: 0x02 0x1C 0x00 0x01 0x0A 0x04 0x04 0x00 0xB7 0x6A 0x61 0x6E 0x2E 0x20 0x32 0x33 0x20 0x32 0x30 0x32 0x30 0x31 0x33 0x3A 0x30 0x35 0x3A 0x35 0x35 0x5D
# uptime
01:55:16 up 1:55, load average: 0.05, 0.04, 0.00
Hi,
I noticed that with the latest release from F+S (2024.01) the imx tty handling changed. I now get a (maybe) kernel message very often when I run a special UART communication (9 Bit (Mark/Space Parity)) (see also [0]:
All bds consumed,restart now.
In my case the UART communication is fine and I can send and receive data. But the kernel log is flooded with the message (see [1]).
I already found a post about the issue under [3]. I then checked the F+S Kernel sources and noticed that the changes from [3] are already applied to the kernel of F+S (5.15).
But because [3] advise changes for kernel version "6.1" I compiled and run the upstream linux kernel 6.11 and where able to run the uart example program without any kernel message (see [2]).
Is this a serious issue or is it easy to fix?
Best regards.
Maik
[0]:
# ./serial_gateway
imx-sdma 20ec000.sdma: All bds consumed,restart now.
ADR: 0x02
LEN: 0x1C
DATA: 0x02 0x1C 0x00 0x01 0x0A 0x04 0x04 0x00 0xB7 0x6A 0x61 0x6E 0x2E 0x20 0x32 0x33 0x20 0x32 0x30 0x32 0x30 0x31 0x33 0x3A 0x30 0x35 0x3A 0x35 0x35 0x5D
[1]:
# uname -r
5.15.131-F+S
# dmesg | grep -i sdma
imx-sdma 20ec000.sdma: alloc bd from iram.
imx-sdma 20ec000.sdma: firmware found.
imx-sdma 20ec000.sdma: loaded firmware 3.6
imx-sdma 20ec000.sdma: All bds consumed,restart now.
imx-sdma 20ec000.sdma: All bds consumed,restart now.
imx-sdma 20ec000.sdma: All bds consumed,restart now.
imx-sdma 20ec000.sdma: All bds consumed,restart now.
imx-sdma 20ec000.sdma: All bds consumed,restart now.
imx-sdma 20ec000.sdma: All bds consumed,restart now.
imx-sdma 20ec000.sdma: All bds consumed,restart now.
…
[2]:
# uname -r
6.11.0-rc4-F+S+
# dmesg | grep -i sdma
imx-sdma 20ec000.sdma: alloc bd from iram.
imx-sdma 20ec000.sdma: loaded firmware 3.6
[3]:
Hello,
thanks for the question about details. I have carried out a reboot test on our prototype with a new base board and with the SKIT.
Prototype with new base board:
I ran a test to reboot the system per command in a loop and after 30 loops every thing went fine. The module every time rebooted.
SUCCESS
SKIT:
Than I ran the reboot loop test with the SKIT and after 11 loops the SKIT freezes and did not reboot. I than checked vie USB if my system recognize the board: see [1].
FAIL
[1]:
$ lsusb
…
Bus 001 Device 019: ID 1fc9:0146 NXP Semiconductors
…
$ dmesg -w
…
[1296107.274894] usb 1-4.2.1: new high-speed USB device number 19 using xhci_hcd
[1296107.403837] usb 1-4.2.1: New USB device found, idVendor=1fc9, idProduct=0146, bcdDevice= 0.02
[1296107.403869] usb 1-4.2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[1296107.403886] usb 1-4.2.1: Product: SE Blank 865
[1296107.403899] usb 1-4.2.1: Manufacturer: NXP SemiConductor Inc
[1296107.409724] hid-generic 0003:1FC9:0146.0046: hiddev2,hidraw4: USB HID v1.10 Device [NXP SemiConductor Inc SE Blank 865 ] on usb-0000:00:14.0-4.2.1/input0
…
I updateed NBOOT from NBoot: 2023.09 to NBoot: 2024.06. I still get the freeze while running "reboot". But the command "poweroff" now successfully halts the system (see [1]).
Thanks.
[1]:
# poweroff
# fec 30be0000.ethernet testernetwork: Link is Down
EXT4-fs (mmcblk2p2): re-mounted. Opts: (null). Quota mode: none.
The system is going down NOW!
Sent SIGTERM to all processes
Sent SIGKILL to all processes
kvm: exiting hardware virtualization
reboot: Power down
------------- freeze ------------
Unserstand.
Thanks for the info. I was able to download and update the current version (nboot-fsimx8mp-2024.06.fs) of NBOOT from [1].
[1]:
Thanks for ter response,
we use the SKTIT from F+S with the revision 1.40 (2021). I will also try to update the NBOOT in between to check for improvements.
Best regards.
I noticed that the commands reboot and poweroff seems to be switch on the current fsimx8mp version.
When I try to reboot the system on the command line interface via "reboot" the system stops and halts, but mainly never somes up (see [1]). Sporadically I noticed a reboot.
On the other side when I try to perform a poweroff to shut down the system, its starting again right away.
I am the only one with this issue? What can be done to fix this behavior?
[1]:
------------ freeze ------------------
[2]:
Hello Ladies and Gentleman,
I am able to build and adjust the bootloader UBOOT from [GITHUB]. Because I we use BUILDROOT for the picocore MX8MP platform. Which means we want to build NBOOT and UBOOT directly from the repo.
But building NBOOT is failing, see [1]. So how are we able to build NBOOT standalone without using the yocto project?
[GITHUB]:
https://github.com/FSEmbedded/…58b1bd2602ea70764313ba110
[1]:
Currently I use the following script to update a gzipped version of the sysimg (see attached file).
Hi,
I can confirm the fix, where the file /etc/fw_env.config should contain the following content:
With this I was able to read the ENV. But writing failed:
Regarding [1], I was able to verify the fix above, but only until the next boot.
Where you able to write the uboot env out of the box?
Or where do we need to enable writing permanently?
[1]: