Friday, April 26, 2024

pinctrl in device tree

An example where we configure imx8mp GPIO1_IO15 (B5) to use as a PWM output.

Can configure it in several ways in the device-tree.


option 1

&pwm4 {

    status = "okay";

};


&iomuxc {

    pinctrl-names = "default";

    pinctrl-0 = <&..>, <&pinctrl_pwm4>; // other pinctrls and pinctrl_pwm4


    pinctrl_pwm4: pwm4grp {

        fsl,pins = <

            MX8MP_IOMUXC_GPIO1_IO15__PWM4_OUT          0x00000006

        >;

    };

};


option 2

&pwm4 {

    pinctrl-names = "default";

    pinctrl-0 = <&pinctrl_pwm4>;

    status = "okay";

};


&iomuxc {

    pinctrl-names = "default";

    pinctrl-0 = <&..>;          // other pinctrls but no pinctrl_pwm4


    pinctrl_pwm4: pwm4grp {

        fsl,pins = <

            MX8MP_IOMUXC_GPIO1_IO15__PWM4_OUT          0x00000006

        >;

    };

};


Documentation/devicetree/bindings/pinctrl/fsl,imx8mp-pinctrl.yaml tells us how to interpret the pinmux settings we are seeing in the device-tree


fsl,pins:

description:

  each entry consists of 6 integers and represents the mux and config

  setting for one pin. The first 5 integers <mux_reg conf_reg input_reg

  mux_val input_val> are specified using a PIN_FUNC_ID macro, which can

  be found in <arch/arm64/boot/dts/freescale/imx8mp-pinfunc.h>. The last

  integer CONFIG is the pad setting value like pull-up on this pin. Please

  refer to i.MX8M Plus Reference Manual for detailed CONFIG settings.

$ref: /schemas/types.yaml#/definitions/uint32-matrix

items:

  items:

    - description: |

        "mux_reg" indicates the offset of mux register.

    - description: |

        "conf_reg" indicates the offset of pad configuration register.

    - description: |

        "input_reg" indicates the offset of select input register.

    - description: |

        "mux_val" indicates the mux value to be applied.

    - description: |

        "input_val" indicates the select input value to be applied.

    - description: |

        "pad_setting" indicates the pad configuration value to be applied..


from arch/arm64/boot/dts/freescale/imx8mp-pinfunc.h


                      pad/pin     functionality we want to

                      in imx8mp   assign to the pad

                     |--------|  |---------|

#define MX8MP_IOMUXC_GPIO1_IO15__GPIO1_IO15    0x050 0x2B0 0x000 0x0 0x0

#define MX8MP_IOMUXC_GPIO1_IO15__USB2_OC       0x050 0x2B0 0x000 0x1 0x0

#define MX8MP_IOMUXC_GPIO1_IO15__USDHC3_WP     0x050 0x2B0 0x634 0x4 0x0

#define MX8MP_IOMUXC_GPIO1_IO15__PWM4_OUT      0x050 0x2B0 0x000 0x5 0x0

#define MX8MP_IOMUXC_GPIO1_IO15__CCM_CLKO2     0x050 0x2B0 0x000 0x6 0x0


pin mux from the imx8mp reference manual


instance    port            pad             mode

CCM         CCM_CLKO2       GPIO1_IO15      ALT6

GPIO1       GPIO1_IO15      GPIO1_IO15      ALT0

PWM4        PWM4_OUT        GPIO1_IO15      ALT5

USB2        USB2_OC         GPIO1_IO15      ALT1

USDHC3      USDHC3_WP       GPIO1_IO15      ALT4


from the imx8mp reference manual, we see mux_reg and conf_reg registers of iomuxc are


32-bit MUX Control Register IOMUXC_SW_MUX_CTL_PAD_x to configure ALT mode (MUX MODE)

32-bit PAD Control Register IOMUXC_SW_PAD_CTL_PAD_x to configure pad settings


for our GPIO1_IO15


SW_MUX_CTL_PAD_GPIO1_IO15 SW MUX Control Register

(IOMUXC_SW_MUX_CTL_PAD_GPIO1_IO15)

Address: 3033_0000h base + 50h offset = 3033_0050h


31 .... 5   4       3      2   1  0

[reserved][SION][reserved][mux mode]


mux_val: IOMUXC_SW_MUX_CTL_PAD_GPIO1_IO15[2:0] = 101 -  ALT5_PWM4_OUT


SW_PAD_CTL_PAD_GPIO1_IO15 SW PAD Control Register

(IOMUXC_SW_PAD_CTL_PAD_GPIO1_IO15)

Address: 3033_0000h base + 2B0h offset = 3033_02B0h


31 .... 9  8    7    6    5    4      3      2..1    0

[reserved][PE][HYS][PUE][ODE][FSEL][reserved][DSE][reserved]


pad_setting = 0x00000006 : sets the drive strength

where

PE  : pull resistors enable/disable

HYS : cmos/schmitt

PUE : pull up/down config

ODE : open drain enable/disable

FSEL: slew rate slow/fast

DSE : drive strength


Other than linux kernel documentation, some good documentation on pin setting can be found in 

AN5078: Influence of Pin Setting on System Function and Performance


Saturday, March 23, 2024

A note on UUU

I didn't pay much attention to the UUU tool till we ran into an issue recently with imx8mm.

Adding this note as a future reference.

In a new port build, UUUing the image didn't proceed as usual, so checked its help, then ran in verbose mode and individual command mode to see what's going on

First check the lsusb


$ ./uuu -lsusb

uuu (Universal Update Utility) for nxp imx chips -- libuuu_1.5.141-3-g3a5beb6


Connected Known USB Devices

Path Chip Pro Vid Pid BcdVersion

==================================================

3:6 MX8MM SDP: 0x1FC9 0x0134 0x0101



$ lsusb

Bus 003 Device 017: ID 1fc9:0134 NXP Semiconductors SE Blank M845S


Now, UUU in verbose mode. This will also list all compatible configs


$ sudo ./uuu -v -b emmc_all imx8mm-boot.bin imx8mm.sdcard

uuu (Universal Update Utility) for nxp imx chips -- libuuu_1.5.141-3-g3a5beb6


Build in config:

Pctl Chip Vid Pid BcdVersion

==================================================

SDPS: MX8QXP 0x1fc9 0x012f [0x0002..0xffff]

SDPS: MX8QM 0x1fc9 0x0129 [0x0002..0xffff]

SDPS: MX8DXL 0x1fc9 0x0147

SDPS: MX28 0x15a2 0x004f

SDPS: MX815 0x1fc9 0x013e

SDPS: MX865 0x1fc9 0x0146

SDPS: MX8ULP 0x1fc9 0x014a

SDPS: MX8ULP 0x1fc9 0x014b

SDPS: MX93 0x1fc9 0x014e

SDPS: MX95 0x1fc9 0x015d

SDP: MX7D 0x15a2 0x0076

SDP: MX6Q 0x15a2 0x0054

SDP: MX6D 0x15a2 0x0061

SDP: MX6SL 0x15a2 0x0063

SDP: MX6SX 0x15a2 0x0071

SDP: MX6UL 0x15a2 0x007d

SDP: MX6ULL 0x15a2 0x0080

SDP: MX6SLL 0x1fc9 0x0128

SDP: MX7ULP 0x1fc9 0x0126

SDP: MXRT106X 0x1fc9 0x0135

SDP: MX8MM 0x1fc9 0x0134

SDP: MX8MQ 0x1fc9 0x012b

SDPU: SPL 0x0525 0xb4a4 [0x0000..0x04ff]

SDPV: SPL1 0x0525 0xb4a4 [0x0500..0x9998]

SDPV: SPL1 0x1fc9 0x0151 [0x0500..0x9998]

SDPU: SPL 0x0525 0xb4a4 [0x9999..0x9999]

SDPU: SPL 0x3016 0x1001 [0x0000..0x04ff]

SDPV: SPL1 0x3016 0x1001 [0x0500..0x9998]

FBK: 0x066f 0x9afe

FBK: 0x066f 0x9bff

FBK: 0x1fc9 0x0153

FB: 0x0525 0xa4a5

FB: 0x18d1 0x0d02

FB: 0x3016 0x0001

FB: 0x1fc9 0x0152

FB: 0x0483 0x0afb


Run built-in script:

 

uuu_version 1.4.149


# @_flash.bin            | bootloader, which can extract from wic image

# @_image   [_flash.bin] | wic image burn to emmc.



# This command will be run when i.MX6/7 i.MX8MM, i.MX8MQ

SDP: boot -f imx8mm-boot.bin -scanlimited 0x800000


# This command will be run when ROM support stream mode

# i.MX8QXP, i.MX8QM

SDPS: boot -scanterm -f imx8mm-boot.bin -scanlimited 0x800000


# These commands will be run when use SPL and will be skipped if no spl

# SDPU will be deprecated. please use SDPV instead of SDPU

# {

SDPU: delay 1000

SDPU: write -f imx8mm-boot.bin -offset 0x57c00

SDPU: jump -scanlimited 0x800000

# }


# These commands will be run when use SPL and will be skipped if no spl

# if (SPL support SDPV)

# {

SDPV: delay 1000

SDPV: write -f imx8mm-boot.bin -skipspl -scanterm -scanlimited 0x800000

SDPV: jump -scanlimited 0x800000

# }



FB: ucmd setenv fastboot_dev mmc

FB: ucmd setenv mmcdev ${emmc_dev}

FB: ucmd mmc dev ${emmc_dev}

FB: flash -raw2sparse all imx8mm.sdcard

FB: flash -scanterm -scanlimited 0x800000 bootloader imx8mm-boot.bin

FB: ucmd if env exists emmc_ack; then ; else setenv emmc_ack 0; fi;

FB: ucmd mmc partconf ${emmc_dev} ${emmc_ack} 1 0

FB: done



Wait for Known USB Device Appear...

New USB Device Attached at 3:6

3:6>Start Cmd:SDP: boot -f imx8mm-boot.bin -scanlimited 0x800000

100%3:6>Okay (0.652s)

^C


It doesn't proceed beyond this SDP and gets stuck. So, if you run


$ sudo ./uuu SDP: boot -f imx8mm-boot.bin -scanlimited 0x800000


it'll be successful, but SDPV won't


$ ./uuu -lsusb

uuu (Universal Update Utility) for nxp imx chips -- libuuu_1.5.141-3-g3a5beb6


Connected Known USB Devices

Path Chip Pro Vid Pid BcdVersion

==================================================


So, it's not listing down any compatible mode. Let's check what USB is seeing


$ lsusb

Bus 003 Device 016: ID 0525:0151 Netchip Technology, Inc. USB download gadget


In the UUU config listing we saw above, there's no config compatible with the vid/pid USB is seeing


In NXP u-boot commit e330a88a8a76f1815d54109c6ad0d94b34808dac, they had changed vid/pid CONFIG_USB_GADGET_VENDOR_NUM/CONFIG_USB_GADGET_PRODUCT_NUM, but we had't changed them in our defconfig

For example, at SDPV, UUU expects 0x1fc9/0x0151

After accommodating the vid/pid change, things work as usual with UUU.


commit e330a88a8a76f1815d54109c6ad0d94b34808dac

Author: Frank Li <Frank.Li@nxp.com>

Date:   Thu Dec 16 12:21:49 2021 -0600


    MLK-25803-2: Update VID/PID

    

    VID 0x525 and PID 0xa4a5 already registered as

    PLX Technology, Inc.

    Linux-USB File-backed Storage Gadget

    

    But fastboot device is not mass storage devices

    windowns 10 latest update already cached above vid/pid

    

    Change to use Freescale VID 0x1fc9

    

    PID 0x151, for SPL SDP HID download

    PID 0x152, for Fastboot

    PID 0x153, for Kernel fastboot

    

    Need update uuu above 1.4.182

    

    Signed-off-by: Frank Li <Frank.Li@nxp.com>

    Reviewed-by: Ye Li <ye.li@nxp.com>

    (cherry picked from commit 7b84c587ba607844d53a7553c7238e6acd0bba9a)


diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c

index 46b7f80b8b..7644f1e1e6 100644

--- a/arch/arm/mach-imx/spl.c

+++ b/arch/arm/mach-imx/spl.c

@@ -183,7 +183,7 @@ u32 spl_boot_device(void)

 #ifdef CONFIG_SPL_USB_GADGET

 int g_dnl_bind_fixup(struct usb_device_descriptor *dev, const char *name)

 {

-       put_unaligned(CONFIG_USB_GADGET_PRODUCT_NUM + 0xfff, &dev->idProduct);

+       put_unaligned(0x0151, &dev->idProduct);

 

        return 0;

 }

diff --git a/configs/imx6dl_mamoj_defconfig b/configs/imx6dl_mamoj_defconfig

index ae27857e6f..294d580b91 100644

--- a/configs/imx6dl_mamoj_defconfig

+++ b/configs/imx6dl_mamoj_defconfig

@@ -58,6 +58,6 @@ CONFIG_USB=y

 # CONFIG_SPL_DM_USB is not set

 CONFIG_USB_GADGET=y

 CONFIG_USB_GADGET_MANUFACTURER="FSL"

-CONFIG_USB_GADGET_VENDOR_NUM=0x0525

-CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5

+CONFIG_USB_GADGET_VENDOR_NUM=0x1fc9

+CONFIG_USB_GADGET_PRODUCT_NUM=0x0152

 CONFIG_CI_UDC=y

:


Sunday, February 25, 2024

Yocto notes - 2

Follow the yocto documentation to setup poky. I'm using kirkstone branch. Some details might vary depending on the branch. Always refer to the branch documentation.


MACHINE and DISTRO

==================

when you create a build, conf/local.conf specifies distro and the machine

dld@dld:~/yocto$ source poky/oe-init-build-env build-qemu

in this build, we have

MACHINE ??= "qemux86-64"

DISTRO ?= "poky"

distro comes from meta-poky/conf/distro/poky.conf


dld@dld:~/yocto/poky$ ls meta-poky/conf/distro/ -F

include/  poky-altcfg.conf  poky-bleeding.conf  poky.conf  poky-tiny.conf


machine comes from meta/conf/machine/qemux86-64.conf


dld@dld:~/yocto/poky$ ls meta/conf/machine -F

include/  qemuarm64.conf  qemuarm.conf  qemuarmv5.conf  qemumips64.conf  qemumips.conf  qemuppc64.conf  qemuppc.conf  qemuriscv32.conf  qemuriscv64.conf  qemux86-64.conf  qemux86.conf


What is a BSP layer

===================

- MACHINE comes from a BSP layer

- at a minimum, a BSP layer should have a machine configuration (see documentation/bsp-guide/bsp.rst for details)

- meta has machine configs in its conf/, so it's a BSP layer

- meta-poky isn't a BSP layer, it only has distro (check on your side or see its listed contents in the previous post)

- our build directory's conf/bblayers.conf has the following


# POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf

# changes incompatibly

POKY_BBLAYERS_CONF_VERSION = "2"


BBPATH = "${TOPDIR}"

BBFILES ?= ""


BBLAYERS ?= " \

  /home/dld/yocto/poky/meta \

  /home/dld/yocto/poky/meta-poky \

  /home/dld/yocto/poky/meta-yocto-bsp \

  "


Why is the meta-yocto-bsp there?

- it's a BSP layer

- if you check the conf/local.conf, you'll see that we can use the following for the MACHINE


# There are also the following hardware board target machines included for 

# demonstration purposes:

#

#MACHINE ?= "beaglebone-yocto"

#MACHINE ?= "genericx86"

#MACHINE ?= "genericx86-64"

#MACHINE ?= "edgerouter"

#


- these machines come from meta-yocto-bsp


dld@dld:~/yocto/poky$ tree meta-yocto-bsp/conf/

meta-yocto-bsp/conf/

├── layer.conf

└── machine

    ├── beaglebone-yocto.conf

    ├── edgerouter.conf

    ├── genericx86-64.conf

    ├── genericx86.conf

    └── include

        └── genericx86-common.inc


- so, if you build for one of these machines, you need the meta-yocto-bsp BSP layer

- when you are building for qemux86-64, you don't really need it

- so try removing that layer, and the build should work just fine


dld@dld:~/yocto/build-qemu$ bitbake-layers remove-layer /home/dld/yocto/poky/meta-yocto-bsp

dld@dld:~/yocto/build-qemu$ bitbake-layers show-layers

NOTE: Starting bitbake server...

layer                 path                                      priority

==========================================================================

meta                  /home/dld/yocto/poky/meta              5

meta-poky             /home/dld/yocto/poky/meta-poky         5


dld@dld:~/yocto/build-qemu$ bitbake core-image-minimal


bootloader and kernel specification

===================================

Where u-boot comes from

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


meta/recipes-bsp/u-boot


- this is the only u-boot specification in poky which is in meta BSP layer

- in meta/recipes-bsp/u-boot/u-boot.inc

PROVIDES = "virtual/bootloader"


- for example, if we build for beaglebone, we have in meta-yocto-bsp/conf/machine/beaglebone-yocto.conf

PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot"


- see how PROVIDES and PREFERRED_PROVIDER work in documentation/ref-manual/variables.rst


Where linux kernel comes from

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


- from the machine configuration file in the BSP layer, the machine we are building for

- for example, if we build for qemux86-64, which is the default, machine config will specify it (may get from an *.inc)

PREFERRED_PROVIDER_virtual/kernel ??= "linux-yocto"


- version comes from meta-poky/conf/distro/poky.conf for qemux86-64

PREFERRED_VERSION_linux-yocto ?= "5.15%"


- for beaglebone, we'll get them from the machine configuration beaglebone-yocto.conf


PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"

PREFERRED_VERSION_linux-yocto ?= "5.15%"


- Q: where's the PROVIDES that specifies virtual/kernel?

- A: it's in the kernel.bbclass, and the kernel recipes inherit kernel.bbclass


- experiment commenting out the version and see what happens by querying the variables using bitbake -e (BitBake’s -e option is used to display variable values after parsing)


- lets check the linux version that'll be used

- for beaglebone


dld@dld:~/yocto/build-bb$ bitbake -e core-image-minimal | grep PREFERRED_VERSION_linux-yocto

# $PREFERRED_VERSION_linux-yocto

PREFERRED_VERSION_linux-yocto="5.15%"

# $PREFERRED_VERSION_linux-yocto-rt

PREFERRED_VERSION_linux-yocto-rt="5.15%"


- if you check the full bitbake -e (redirect to a file and search), you'll see from where it's set


for qemux86-64


#

# $PREFERRED_VERSION_linux-yocto

#   set? /home/dld/yocto/poky/meta-poky/conf/distro/poky.conf:23

#     "5.15%"

PREFERRED_VERSION_linux-yocto="5.15%"

#


for beaglebone


#

# $PREFERRED_VERSION_linux-yocto [2 operations]

#   set? /home/dld/yocto/poky/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf:27

#     "5.15%"

#   set? /home/dld/yocto/poky/meta-poky/conf/distro/poky.conf:23

#     "5.15%"

# pre-expansion value:

#   "5.15%"

PREFERRED_VERSION_linux-yocto="5.15%"

#


- so, qemux86-64 will use

meta/recipes-kernel/linux/linux-yocto_5.15.bb

- beaglebone will use

meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.15.bbappend

beaglebone is having the following in linux-yocto_5.15.bbappend

KBRANCH:beaglebone-yocto = "v5.15/standard/beaglebone"

KMACHINE:beaglebone-yocto ?= "beaglebone"

SRCREV_machine:beaglebone-yocto ?= "9aabbaa89fcb21af7028e814c1f5b61171314d5a"

COMPATIBLE_MACHINE:beaglebone-yocto = "beaglebone-yocto"

LINUX_VERSION:beaglebone-yocto = "5.15.54"













Friday, January 26, 2024

Yocto notes - 1

Follow the yocto documentation to setup poky. I'm using kirkstone branch. Some details might vary depending on the branch. Always refer to the branch documentation.


How bblayers.conf and local.conf are created in the build directory

====================================================================

- you can see this when you create the build for the first time

- meta-poky/conf/ has the bblayers.conf.sample and local.conf.sample files

- scripts/oe-setup-builddir uses these to create the bblayers.conf and local.conf in your build directory's conf/

- and, oe-setup-builddir spits out this info

- see the following example

- meta-poky/conf/ also has conf-notes.txt, which oe-setup-builddir uses to show you info about the targets etc. at the end

- local.conf.sample.extended has more configs you can add to the local.conf


 

dld@dld:~/yocto/poky$ ls meta-poky/conf/ -F

bblayers.conf.sample  conf-notes.txt  distro/  layer.conf  local.conf.sample  local.conf.sample.extended  site.conf.sample


dld@dld:~/yocto/poky$ source oe-init-build-env ../build-test

You had no conf/local.conf file. This configuration file has therefore been

created for you from /home/dld/yocto/poky/meta-poky/conf/local.conf.sample

You may wish to edit it to, for example, select a different MACHINE (target hardware). See conf/local.conf for more information as common configuration options are commented.


You had no conf/bblayers.conf file. This configuration file has therefore been created for you from /home/dld/yocto/poky/meta-poky/conf/bblayers.conf.sample

To add additional metadata layers into your configuration please add entries to conf/bblayers.conf.


The Yocto Project has extensive documentation about OE including a reference manual which can be found at:

    https://docs.yoctoproject.org


For more information about OpenEmbedded see the website:

    https://www.openembedded.org/


### Shell environment set up for builds. ###


You can now run 'bitbake <target>'


Common targets are:

    core-image-minimal

    core-image-full-cmdline

    core-image-sato

    core-image-weston

    meta-toolchain

    meta-ide-support


You can also run generated qemu images with a command like 'runqemu qemux86'


Other commonly useful commands are:

 - 'devtool' and 'recipetool' handle common recipe tasks

 - 'bitbake-layers' handles common layer tasks

 - 'oe-pkgdata-util' handles common target package tasks


- let's see what's in our build directory's conf/ ,and the contents of conf/bblayers.conf. conf/local.conf is too big to show here, check its contents yourself 


dld@dld:~/yocto/build-test$ ls conf/

bblayers.conf  local.conf  templateconf.cfg


dld@dld:~/yocto/build-test$ cat conf/bblayers.conf 

# POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf

# changes incompatibly

POKY_BBLAYERS_CONF_VERSION = "2"


BBPATH = "${TOPDIR}"

BBFILES ?= ""


BBLAYERS ?= " \

  /home/dld/yocto/poky/meta \

  /home/dld/yocto/poky/meta-poky \

  /home/dld/yocto/poky/meta-yocto-bsp \

  "



But, why/how does it use meta-poky/conf/ in the first place?

============================================================

- for details, see documentation/ref-manual/structure.rst and scripts/oe-setup-builddir

- a brief explanation follows

- as we saw in the previous listing, our build directory has a conf/templateconf.cfg


dld@dld:~/yocto/build-test$ cat conf/templateconf.cfg 

meta-poky/conf


- poky has a .templateconf


dld@dld:~/yocto/poky$ cat .templateconf

# Template settings

TEMPLATECONF=${TEMPLATECONF:-meta-poky/conf}


- build directory's conf/templateconf.cfg is created by scripts/oe-setup-builddir like this:


. "$OEROOT"/.templateconf


if [ ! -f "$BUILDDIR/conf/templateconf.cfg" ]; then

    echo "$TEMPLATECONF" >"$BUILDDIR/conf/templateconf.cfg"

fi


. "$OEROOT"/.templateconf is the same as source "$OEROOT"/.templateconf

- now, the bblayers.conf.sample etc. are picked from meta-poky/conf


if [ -n "$TEMPLATECONF" ]; then

    :

    OECORELAYERCONF="$TEMPLATECONF/bblayers.conf.sample"

    OECORELOCALCONF="$TEMPLATECONF/local.conf.sample"

    OECORENOTESCONF="$TEMPLATECONF/conf-notes.txt"

fi


- however, if $TEMPLATECONF is empty, $OECORELAYERCONF etc. will be empty, so, those files are picked from meta/conf/

- for example, in scripts/oe-setup-builddir


if [ -z "$OECORELAYERCONF" ]; then

    OECORELAYERCONF="$OEROOT/meta/conf/bblayers.conf.sample"

fi