Posts by BrenkeM

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]:

https://community.nxp.com/t5/i…T-lost-bytes/td-p/1696008

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]:

https://fs-net.de/en/support/my-f-and-s

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]:

https://www.kernel.org/doc/Doc…ion/mmc/mmc-dev-parts.txt

Hi.

Indeed. Binaries in repos are not a good thing. A download page with a list of all (and the latest) toolchains would be great and sufficient.

But please povide a link specially to the latest toolchain with every update (just like in github releases)

Thanks.

Hi. Sorry. My fault. I was thinking the bootloader is limited to use only 38 MB. But yes. The System image is ~233 MB and the update works and the image works fine.

Thanks. Now every details seems to be discussed.

Hi.

Unter [1] you can find the system variant.

So I updated the following file. Does this mean the file did not fit into DRAM before I wrote it to eMMC?

$ du -h emmc-fsimx8mp.sysimg

68M emmc-fsimx8mp.sysimg

$ ll emmc-fsimx8mp.sysimg -h

-rw-r--r-- 1 brenkem domain_users 233M Apr 29 14:09 emmc-fsimx8mp.sysimg

For every one who noticed a file size difference between du and ls, see [2].

[1]:

U-Boot 2021.04-F+S-fsimx8mp-Y2023.09 (Aug 31 2023 - 12:56:23 +0000) for F&S

CPU: i.MX8MP[8] rev1.1, 1600 MHz (running at 1200 MHz)

CPU: Industrial temperature grade (-40C to 105C)

Reset: POR

Model: PicoCoreMX8MPr2

Board: PicoCoreMX8MPr2 Rev 1.10 (2x LAN, WLAN, eMMC, 1x DRAM)

DRAM: 2 GiB

TCPC: Vendor ID [0x1fc9], Product ID [0x5110], Addr [I2C2 0x52]

MMC: FSL_SDHC: 0, FSL_SDHC: 2

Env: Loading from MMC... OK

In: serial

Out: serial

Err: serial

SEC0: RNG instantiated

ATF: fa25831

CFG: Found at 0x918000

NBoot: 2023.09

Fastb: flash target is MMC:2

Net: eth1: ethernet@30be0000, eth0: ethernet@30bf0000 [PRIME]

Fastb: Normal fastboot

Normal Boot

Hit any key to stop autoboot: 0

PicoCoreMX8MPr2 # printenv platform

platform=picocoremx8mpr2

PicoCoreMX8MPr2 # bdinfo

boot_params = 0x0000000000000000

DRAM bank = 0x0000000000000000

-> start = 0x0000000040000000

-> size = 0x0000000080000000

flashstart = 0x0000000000000000

flashsize = 0x0000000000000000

flashoffset = 0x0000000000000000

baudrate = 115200 bps

relocaddr = 0x00000000bff15000

reloc off = 0x000000007fd15000

Build = 64-bit

current eth = ethernet@30bf0000

ethaddr = 00:05:51:07:55:83

IP addr = 169.254.255.44

fdt_blob = 0x00000000bdbf32b0

new_fdt = 0x00000000bdbf32b0

fdt_size = 0x000000000000cb00

lmb_dump_all:

memory.cnt = 0x1

memory.size = 0x0

memory.reg[0x0].base = 0x40000000

.size = 0x80000000

reserved.cnt = 0x1

reserved.size = 0x0

reserved.reg[0x0].base = 0xbdbf1eb0

.size = 0x240e150

arch_number = 0x00000000ffffffff

TLB addr = 0x00000000bfff0000

irq_sp = 0x00000000bdbf32a0

sp start = 0x00000000bdbf32a0

BOARD-CFG = 0x0000000000918000

Early malloc usage: a448 / 15000

[2]:

https://askubuntu.com/question…nt-size-for-the-same-file

Hi,

we like the github repos of F+S and already adopted the repos.

What is missing is the toolchain repo (precompiled). I already created this repo on our side ([1]), but it would be great to simply mirror the latest github repo from F+S.

Can you do this. I can also share my repo with older versions (maybe not complete (see [2]).

[1]:

toolchain-armv7ahf

toolchain-armv8ahf

[2]:

Hi.

Thanks. Indeed, the documentation of F+S describes the TFTP option unter 7.2 Installation to eMMC:

"Of course downloading these system images to the board using tftp like in the NAND case
would theoretically also work. But unfortunately these system images are rather big and do
not fit into RAM. And because tftp does not support downloading arbitrary parts of a file,
this approach is typically not a valid option. In the following sections we will use an SD card
or a USB pendrive to install these system images."

What is the DRAM limit of the PicoCore™MX8MPr2?

Hi,

after some research unter [1] and [2] with the documentation under [3] I was able to successfully update the mmc memroy via tftp (see [4]).

Thanks. Case closed.

[1]:

https://gist.github.com/pirate…6a7303404a0793533de38672f

[2]:

https://e2e.ti.com/support/pro…ot-0-partition-using-tftp

[3]:

https://docs.u-boot.org/en/latest/usage/cmd/mmc.html

[4]:

By adopting the new picocore platform we need to update the system image created by buildroot or yocto via network by tftp. Because on your current platform we use a nand flash as memory, the way to update the newly mmc memory the update process is different.

How to update the system image (sysimg) in bootloader u-boot via networt by tftp?

Hi,

the pull request can be found [here].

[here]:

https://github.com/FSEmbedded/linux-fus/pull/2

I added now the real time patch (preempt) version rt68 to the kernel version 5.15.131 from the F+S release fsimx6sx-B2024.01.

@F+S: If you are interested I can create a pull request (maybe a RT branch) to distribute it over your github organisation.

@all others: If F+S do not plan to host the changes you can contact me for the patched kernel.

Best regards.

Hi,

as already mentioned I recommand to check out the pull request here:

Support PicoCORE IMX8MP with a buildroot based release

We decided to stick at buildroot for reasons. Try it out and let me know when you need help.

Best regards.

Maik