Mity CPU Platforms » MitySOM-AM62, MitySOM-AM62A, & MitySOM-AM62P

Hi Rajkumar,

Did you note the (brief) instructions here:

https://support.criticallink.com/redmine/projects/mitysom_am62x/wiki/Repositories_and_Pre-built_Images#Debian-Image-Not-typically-needed

The reference image from TI will need to be updated to use the CL bootloader (to deal with RAM and console port changes), kernel, and kernel configuration (devicetree) files. Then it will boot up.

If time permits I can try to pull a procedure together. It may be a few days.

With regards,
Mike

Hi Mike,

Thanks for your reply.

I flashed the reference microSD card image (Debian) provided by Critical Link, not the one from TI.
https://support.criticallink.com/redmine/projects/mitysom_am62x/wiki/Repositories_and_Pre-built_Images#Debian-Image-Not-typically-needed
The Image That is available inside the table(By default, this image is for HS-FS SOMs TI Debian Bookworm Processor SDK 10.0 (>700MB, A 16GB OR LARGER SD CARD is required))
Does this image already include the Critical Link bootloader, kernel, and kernel configurations, or do we need to replace them manually?

If we need to make changes, could you please let me know which image I should use as a reference to work with Debian?

Thanks,
Rajkumar.

Hi Rajkumar,

Can you try this image?

https://support.criticallink.com/files/mitysom62x/tisdk-debian-trixie-mitysom-am62xx-devkit.wic.xz

I am working on instruction.

Thanks,
Mike

Hi Mike,

I'll try the image that you sent and will update you on the status.

Thank you.

Note replace references of am62x with am62p. So make sure to download the am62p tisdk image and but still start with the am62 debian image.

TI does have a 62p debian sdcard image as well, though in reality they should be mostly identical other than the u-boot and kernel files.

Hi Rajkumar,

The image I provided was for a MitySOM-AM62x, not an MitySOM-AM62P. You'll need to redo what I have listed in the link below with our AM62P reference image. Sorry for the inconvenience.

https://support.criticallink.com/redmine/projects/mitysom_am62x/wiki/Updating_the_TI_EVM_Debian_Image_for_the_MitySOM-AM62x_DevKit

-Mike

Hi Mike,

Just to clarify, I hadn’t found the link below previously—it looks like it was updated recently:

https://support.criticallink.com/redmine/projects/mitysom_am62x/wiki/Updating_the_TI_EVM_Debian_Image_for_the_MitySOM-AM62x_DevKit

That said, I had already tried the steps mentioned there before our conversation started. I’d like to clarify two things:

I used the kernel, U-Boot, and device tree files from the SD card that came with the Critical Link kit.

Instead of using the losetup (loopback setup) command, I copied the files directly using the file manager on my Linux system.

For our development, we require a full Debian-based OS because it includes the Linux headers (/usr/src/linux-headers-*) necessary for building the EtherCAT IgH master. As far as I understand, the SDK provided on the Critical Link SD card doesn’t include these headers since it’s based on a BSP/Yocto Linux (please correct me if I’m wrong).
I tried the steps from the link above, but the board did not boot (no working init found). I'm including the recent boot log below for reference.

@@ #1
[ 2.010559] Hardware name: Critical Link MitySOM-AM62Px (DT)
[ 2.016203] Call trace:
[ 2.018641] dump_backtrace+0x98/0xf8
[ 2.022309] show_stack+0x20/0x38
[ 2.025616] dump_stack_lvl+0x48/0x60
[ 2.029274] dump_stack+0x18/0x28
[ 2.032580] panic+0x338/0x3a8
[ 2.035631] kernel_init+0x1a4/0x1f0
[ 2.039197] ret_from_fork+0x10/0x20
[ 2.042767] SMP: stopping secondary CPUs
[ 2.046686] Kernel Offset: disabled
[ 2.050160] CPU features: 0x0,00000008,00020000,1000420b
[ 2.055458] Memory Limit: none
[ 2.058505] ---[ end Kernel panic - not syncing: No working init found. Try passing init= option to kernel. See Linux Documentation/admin-guide/init.rst for guidance. ]---

Thanks,
Rajkumar

Hi Rajkumar,

Ok. I rebuilt the image using TI's SDK 10.01 debian trixie am62pxx-evm build (vs. the am62xx build) and only copied the boot files (in the first partition) and added our device tree. I left the kernel and modules the same as the pre-built image and was able to get my devkit with an 8 GB MitySOM-AM62P to boot and have networking support. I did have to edit the /etc/resolv.conf to point to a valid nameserver with the build. Same instructions, just skip the step of coping the Image files and kernel modules.

Here is a link to the image that booted for me:

https://support.criticallink.com/files/mitysom62x/tisdk-debian-trixie-mitysom-am62p-devkit-10.01.10.04.wic.xz

I was able to run an apt update, etc. I have only tested the console and the ethernet ports.

As a side note, our kernel build and associated headers (the git repo) is publicly available. So if our kernel is used we can supply the kernel headers if needed. With this kernel, I don't know if the display will work correctly as we have some patches for the TFP410 I2C control that are needed to enable the output.

With regards,
Mike

Hi Mike,

I did the same setup using the TI Debian SDK v10.00. It booted successfully, and I have the default TI kernel and kernel headers. I also installed the EtherCAT IGH Master.

I want to bring up one point: I entered manual boot mode (by pressing the Escape key during boot) and checked the environment variables. For the device tree, it was using k3-am62px-mitysom-devkit.dtb (provided by Critical Link), whereas TI uses their own device tree — I believe it was something like k3-am62p5-sk.dtb (I don't remember the exact name).

We had previously enabled UART5 in the device tree and made some minor modifications during development with the TI evaluation board. These changes will not work if the Critical Link (CL) version of the device tree does not have UART5 enabled or lacks our customizations.

Therefore, could you please share the kernel device tree source and U-Boot source code provided by Critical Link? That way, we can apply our changes and deploy a working version.

The links to our git repositories and branch names for the kernel and uboot (you'll want the latest / scarthgap release) are at the top of the
Repositories_and_Pre-built_Images page. This includes the dts files you'll need to modify to configure the pinmux and enable the UART5 device. You'll want to update the k3-am62px-mitysom-devkit.dts file.

With regards,
Mike

We also have specific guides on how to build our u-boot and kernel linked below.

https://support.criticallink.com/redmine/projects/mitysom_am62x/wiki/U-Boot_Building_for_MitySOM-AM62
https://support.criticallink.com/redmine/projects/mitysom_am62x/wiki/Linux_Kernel

We’ve now implemented the changes you suggested, and the OS is working fine.

Since we only copied the U-Boot and device tree from the Critical Link (CL) build into the TI file system, we needed to explicitly enable main_uart5 in the device tree. To do this, I performed the following steps:

1.Added the UART5 node in the device tree at the path:linux-ti/arch/arm64/boot/dts/ti/k3-am62px-mitysom-som.dtsi
@
aliases {
serial0 = &wkup_uart0;
serial2 = &main_uart0;
serial3 = &main_uart1;
serial5 = &main_uart5;
mmc0 = &sdhci0;
mmc1 = &sdhci1;
mmc2 = &sdhci2;
spi0 = &ospi0;
ethernet0 = &cpsw_port1;
ethernet1 = &cpsw_port2;
usb0 = &usb0;
usb1 = &usb1;
};
&main_uart5 {
bootph-all;
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&main_uart5_pins_default>;
/* Main UART5 is used by USER firmware /
};
main_uart5_pins_default: main-uart5-default-pins {
bootph-all;
pinctrl-single,pins = <
AM62PX_IOPAD(0x1d8, PIN_INPUT, 1) / (B23) UART0_RXD /
AM62PX_IOPAD(0x1dc, PIN_OUTPUT, 1) / (F20) UART0_TXD */
>;

};
@
Device Tree Modifications:

The pin details for UART5 were taken from the AM62P TRM to ensure the correct ball assignments.

• The source tree is not clean, please run 'make mrproper'
• in /home/svaya/cl/linux-ti
  make³: * [../Makefile:651: outputmakefile] Error 1
  make²: [/home/svaya/cl/linux-ti/Makefile:798: include/config/auto.conf.cmd] Error 2
  make¹: [/home/svaya/cl/linux-ti/Makefile:234: __sub-make] Error 2
  make¹: Leaving directory '/home/svaya/cl/linux-ti/build-mitysom62x'
  make: ** [Makefile:234: __sub-make] Error 2@

I ran the 62xx-build-dts.sh script, but it threw an error because it was unable to find the .config file, so I entered the following command fro ti document :

make ARCH=arm64 CROSS_COMPILE="$CROSS_COMPILE_64" dtbs && make ARCH=arm64 CROSS_COMPILE="$CROSS_COMPILE_64" dtbs
whith this it generated k3-am62px-mitysom-devkit.dtb.

After generating the k3-am62px-mitysom-devkit.dtb file, I copied it to /boot/dts/ti/ on the target filesystem.

Then, I rebooted the board.

However, UART5 is still not functioning.

Case 2: I cleaned everything and ran 62xx-build.sh, which successfully generated the .dtb, Image, vmlinux, etc. However, UART5 is still not working.

Could you please guide us on how to properly enable UART5?

Thank you,
Rajkumar

Hi Mike,
Update on the above comment:
It is working now. The issue was that pins B23 and F20 were already being used in the main_gpio_p3_pins_default node for the P3 connector. I commented out those two pins, and now UART5 has started working.

Thank you,
Rajkumar--

Can you check if you disabled the MCAN0 mux options? Usually the first device to claim the resource wins, so if MCAN initializes first it might claim the pins on you.

make sure the lines below are commented out in k3-am62px-mitysom-devkit.dts:

   AM62PX_IOPAD(0x01d8, PIN_INPUT_PULLDOWN, 7) /* (B23) MCAN0_TX.GPIO1_24 */
   AM62PX_IOPAD(0x01dc, PIN_INPUT_PULLDOWN, 7) /* (F20) MCAN0_RX.GPIO1_25 */

-Mike

Glad you got it fixed! (our comments passed each other!)

I ran the 62xx-build-dts.sh script, but it threw an error because it was unable to find the .config file

Thanks for pointing this out. I'd never tried using the dts script without already having run the full build. But this can be resolved by grabbing the make defconfig line from the regular build script and add it.
https://support.criticallink.com/gitweb/?p=linux-ti.git;a=commit;h=7a2fa4c2307057e6c0fba995546f6d006afcd575

The source tree is not clean, please run 'make mrproper'

This error occurs because the build scripts use an out of tree build using the "O=" argument. If you manually run the commands without that argument, it starts an in-tree build and the kernel will complain if you switch between the two. Running 'make mrproper' should be enough to clean the build and resolve the issue.