PICO-PI-IMX7: Editing and Recovery/Linux 4.19.x

@RobertCNelson My shcematic pdf (https://drive.google.com/file/d/1Bd_lXEkywucwcdcvqsL_ua7Hfz1413MB/view?usp=sharing) is a little different from yours. Is jp8 and not j8. But I know it must be the same, my doubts are below:

Question 01 : The 3.3v and 5.0v pins are already configured or should I proceed similarly to the gpio40?

Question 02 : Similar to the question above, only referring to GND

Question 03 : JP8_40 is can_rx and jp8_18, too (according to my pdf) And not can_rx2 and can_rx1.
Does this change anything when configuring?

Wouldn’t it be better if I use the jp8_34, jp8_35, jp8_36, jp8_37 that are already defined with gpio and not as can_rx ???

3v3 and 5v0 are voltage rails directly connected to the regulators.

Same as answer 1, already configured…

Nice catch, looks like a typo in the spread sheet. One quick test, after configuring D11 in Linux, grab your LED and try both locations while toggling the pin in Linux. Very quickly you’ll discover the correct location.

Personally i believe J8 pin18 to not be D11, as D11 isn’t a possible option according to NXP’s Pinmux tool:


When comparing with the Linux Kernel:

	pinctrl_can1: can1frp {
		fsl,pins = <

The D11 typo should be E12, for can1_rx…

Yes, you are free to use any gpio’s, however you had specifically requested a step by step direction on utilizing gpio_40. You can use those same directions to configure any the pins the P8 header.


Do the results for the ./tools/rebuild.sh command look okay?

is the NXP software only used to verify Magic values?

Question 01: In this part I have a difficulty. I commanded a ums 0 mmc 0 (in picocom) and on the ubuntu-server computer lsblk and got the result of the photo. It doesn’t seem ok for me to go to Setup extlinux.conf (sudo mkdir -p /media/rootfs/boot/extlinu/), correct?

What should I do to fix this?

It built, that’s really the only verification you can have.


The NXP software is used to find the correct pinmux name for a specific setting, along with pull-up/pull-down settings that you require.

You photo looks fine. As you already have a booting pico board, just update the extlinux.conf file with your new kernel version…


Make sure to copy the kernel, modules and device tree’s…



root@arm:/sys/class/leds# ls
gpio-led  mmc0::  mmc1::  mmc2::

Unfortunately, it still doesn’t look like it worked. I had some mistakes at the end (photo issue1211) but I don’t think that was it.

According to photo00, there are two files. One of them has something like /ignore/ I didn’t touch it. Should I have touched it too?

Here are pictures of the changes I made to the files:

Well first check that you booted the new kernel, just type:

uname -v
debian@bbb-pwr01-ser09:~$ uname -v
#1buster SMP PREEMPT Tue Aug 25 01:48:27 UTC 2020

The “build date” in above is “Tue Aug 25 01:48:27 UTC 2020” in your case it should match your build time of today…

Your photo’s are missing the pin defines, from “./KERNEL/” just run “git diff” and pastebin the changes…

all "./ignore/’ directories are a local cache for git…

PS, looking at your screen log, why did you rewrite /etc/fstab? you just need to update the kernel, module and device tree blobs and then extlinux.conf, don’t touch anything else…



root@arm:/sys/class/leds# uname -v
#1 SMP PREEMPT Sun Sep 27 23:24:29 -03 2020

In the photo01 above, it shows that I made changes to the pin

So it’s still September??? Nope it’s now middle of November, so you booted the ‘old’ kernel. Try copying over the Kernel/modules and device-tree again.


It’s like I told you before. I have difficulties to update only the kernel. The times it worked, I went back to pico-imx7d in factory condition (via mfgtool2) and started from scratch. The photo below indicates the error (I think). Instead of sdd1 - part - /media/neuberfran/rootfs should be /media/rootfs, correct?

That’s no error, that’s just your desktop “auto-mounting” the drive.

On the wiki i state:

On most systems these partitions may be auto-mounted…

sudo mkdir -p /media/rootfs/
for: DISK=/dev/mmcblkX
sudo mount ${DISK}p1 /media/rootfs/
for: DISK=/dev/sdX
sudo mount ${DISK}1 /media/rootfs/

So in your case, it “auto-mounted” thus just use “/media/neuberfran/rootfs/” instead of “/media/rootfs/”…

If you woried about it, just unmount it:

sudo umount /media/neuberfran/rootfs/

and correctly mount it…

sudo mount /dev/sdd1 /media/rootfs/

EDIT; thinking more about this, i don’t know what your version of FUSE, or the auto-mount settings did, i’d just advise to un-mount it and properly mount it.

That’s only first 24 lines…

Just do:

git diff | pastebinit


@RobertCNelson http://paste.ubuntu.com/p/BjP4JRqXb6/

Looks good, should just work… :wink:



Hum, the led’s are showing up… I bet, the ‘date’ was set when you originally built the kernel, whereas ./tools/rebuild.sh only builds the changes… Since only the device-tree changed, the kernel build date wasn’t updated…


I had problems (died) my mobo p8h61m lx3 r2.0. I’ll only be back on 25.11.2020 with another. I re-recorded the bios(bin file), but it didn’t work. Before, there was time to make echo 0 and echo 255 and turn off/on led on gpio40

@RobertCNelson I’m back. I can blink led with:

echo 255 > /sys/class/leds/gpio40/brightness But I can’t with
gpioset 5 14=1

I only can Use gpiochip0 (zero) ? How to solve ? (Pls)

@RobertCNelson Can you help me just one more time? Why can’t I use gpioset commands on my pico-imx7d with debian (after being able to use sysfs correctly)?

Error images posted above

Hi @neuberfran

Answer/Question 1: Simple, you Defined GPIO6_IO14 as an LED, thus you NO longer have permission to access it thru gpioset.

Answer/Question 2: /dev/gpiochipX is the peripheral, /syc/class/gpio/chipchip*/ are the gpio’s…

Well, the root:root permission is Yocto’s choice… Feel free to change it:


@RobertCNelson Sir.: You said : "Simple, you Defined GPIO6_IO14 as an LED, thus you NO longer have permission to access it thru gpioset!

  1. How to solve it? I am trying to use the gpioset command and then implement libgpio in a c++ program


root@arm:~# gpioset 1 6=1
[ 517.810239] imx7d-pinctrl 30330000.iomuxc: pin MX7D_PAD_EPDC_DATA06 already requested by 30210000.gpio:38; cannot claim for 30210000.gpio:38
[ 517.823409] imx7d-pinctrl 30330000.iomuxc: pin-19 (30210000.gpio:38) status -22
gpioset: error setting the GPIO line values: Invalid argument