[Neeraj Dantu]

Ryan,

Yes, you can use multiple SD cards. There are 3 MMC interfaces for AM335x inside OSD335x. As you mentioned, you can use MMC0 for boot and additional SD cards on MMC1 and MMC2 interfaces. Please note that MMC1 interface is used for eMMC in OSD3358-ICB. So, you will need to use MMC2 for the additional SD card interface on ICB device.

 

Best,

Neeraj

[Neeraj Dantu]

Apporva,

The above log seems to indicate that there was a kernel panic during initialization of the WiFi module. Here are a few debug inputs:

First, I suggest making sure the module is powered and enabled. The Beaglebone black sets up an enable signal here: https://github.com/RobertCNelson/dtb-rebuilder/blob/4.19-ti/src/arm/am335x-boneblack-wireless.dts#L20.

In addition, please check for proper pinmux setup. The MMC interface pinmux for BBWireless is here: https://github.com/RobertCNelson/dtb-rebuilder/blob/4.19-ti/src/arm/am335x-boneblack-wireless.dts#L40. Also verify GPIO control pinmux for the WiFi module here: https://github.com/RobertCNelson/dtb-rebuilder/blob/4.19-ti/src/arm/am335x-boneblack-wireless.dts#L60.

Please probe the ENABLE signal to the WiFi module to make sure the module is being enabled to respond to probing.

Best,

Neeraj

[Neeraj Dantu]

Apoorva,

Please take a look at the device tree bindings for WLXX devices here: https://elixir.bootlin.com/linux/v4.19.315/source/Documentation/devicetree/bindings/net/wireless/ti,wlcore.txt

Beaglebonne Black Wireless uses a similar Wilink modue(WL1835). The schematics are available here: https://github.com/beagleboard/beaglebone-black-wireless/blob/master/BeagleBone_Black_Wireless_SCH.pdf. The device tree for WiFi for Beaglebone Black Wireless is here: https://github.com/RobertCNelson/dtb-rebuilder/blob/4.19-ti/src/arm/am335x-boneblack-wireless.dts#L73. You should be able to use this device tree as a reference.

 

Additional documentation if you want to dig deeper: https://www.ti.com/lit/ug/swru561a/swru561a.pdf.

Best,

Neeraj

[Neeraj Dantu]

Craig,

In addition to Eshtaartha’s notes on M4 debug in production mode, please see https://community.st.com/t5/stm32-mpus-other-tools/how-to-generate-elf-file-for-cortex-m4-using-iar/td-p/84786 for a discussion on 3rd party tools working with MP1.

Best,
Neeraj

[Neeraj Dantu]

Palmer,

Apologies for the late reply.

The Flashlayout file format for SD card is different from the Flahslayout file for eMMC. Please take a look at Section 3 of this page: https://wiki.st.com/stm32mpu-ecosystem-v3/wiki/STM32CubeProgrammer_flashlayout#Typical_FlashLayout_file_with_FIP. Also note that the mmc interface used looks like mmc0. Make sure that your mmc interface is correct. Once you replace the Flashlayout file with the one for eMMC and chose the right mmc interface, this flashing procedure over UART should work.

 

Best,

Neeraj

[Neeraj Dantu]

Yanjun,

You can do this, but you will need to add the mass storage gadget drivers to the kernel first:

CONFIG_USB_GADGETFS=m

CONFIG_USB_G_ACM_MS=m

CONFIG_USB_MASS_STORAGE=m

Once you add these drivers, you will also need to disable the current USB RNDIS network on the board. Then, you should be able to do:

modprobe g_mass_storage file=/path_to_storage_file

Best,

Neeraj

 

 

[Neeraj Dantu]

The updated release of OSD3358-SM-RED software(v10.3) removed the sensors from userspace to the kernel space. So, you should be able to access the sensors in /sys/bus/iio/devices

 

If you do want to utilize the userspace library, we suggest you use the v9.1 image. Both images are available here: https://octavosystems.com/octavo_products/osd3358-sm-red/#Software

 

Best,

Neeraj

[Neeraj Dantu]

Gil,

The log you attached above indicates that the kernel is running into an error as soon as it takes control from u-boot. Increasing the log level can tell what exactly is going wrong. I do not believe that there is a dependency between U-Boot and kernel versions except for the boot command being passed on to the kernel from u-boot, but the boot process also involves other components: https://wiki.st.com/stm32mpu/wiki/Boot_chain_overview#STM32MP15_boot_chain. Please note that ST has also changed the boot image layout between Dunfell and Kirkstone(https://wiki.st.com/stm32mpu/wiki/STM32CubeProgrammer_flashlayout).

My recommendation would be to use Krikstone versions of everything for the 15.67 kernel.

Best,

Neeraj

• This reply was modified 11 months, 3 weeks ago by Neeraj Dantu.

[Neeraj Dantu]

Gil,

Please change “&exti_pwr” to “&exti” as it looks like all the interrupts are being handled by the exti driver. This should fix the error you are encountering.

Best,

Neeraj

[Neeraj Dantu]

Ed,

We are aware of this issue. The ALSA setup is not configured correctly in the Debian image. Software team is looking into it.

Best,

Neeraj

[Neeraj Dantu]

Gil,

The patches that Octavo applies are for BRK an RED board. If your board is based on these boards, you will need the patches. If not, the 2 patches you need are the DDR parameters(for u-boot: stm32mp15-osd32mp1-ddr3-1x4Gb.dtsi or stm32mp15-osd32mp1-ddr3-2x4Gb.dtsi) for the specific DDR in use and https://github.com/octavosystems/meta-octavo-osd32mp1/blob/dunfell/recipes-bsp/u-boot/files/0009-Fix-device-tree-for-800MHz-speedgrade-MP1-to-work-wi.patch to add support for “F” variant devices to run on 650MHz.

For the custom board device tree, I recommend taking a look at BRK device tree to understand what you need to port to your custom device tree. For example, OSD32MP1 uses STPMIC1 and so, STPMIC1 related configuration in the device tree is needed for any OSD32MP1 based board.

All the Octavo patch files do not modify kernel source code. They add device tree source files for the supported boards. So, there should not be any issues with using .24 patches with .67 kernel version.

Best,

Neeraj

[Neeraj Dantu]

maynarde,

Yes, you should be able to modify uEnv.txt to flash the eMMC from SD card.

Best,

Neeraj

[Neeraj Dantu]

Gil,

You are correct, it looks like 1 of the patches from ST failed to apply because the file it was modifying was too different. The patch that is failing is from ST. You will need to resolve the error by reviewing the code being modified by the patch and making sure the modification applied by the patch is still valid and will function correctly.

An easier way probably would be to pull the kernel source from ST’s repository here: https://github.com/STMicroelectronics/linux/tree/v5.15-stm32mp-r2 (This code has all the ST patches already applied).

If you need granular control of the kernel source code, I suggest you look at https://wiki.st.com/stm32mpu-ecosystem-v4/wiki/OpenEmbedded_-_devtool to export the kernel code into its own workspace and make modifications/resolve conflicts in the source code.

Best,

Neeraj

[Neeraj Dantu]

Gil,

You should be able to use the kirkstone patches with 5.15.67. There are not any kernel level modifications that would affect the compilation.

Best,

Neeraj

[Neeraj Dantu]

Ray,

Since the only option for MII_COL is either PA3 or PH3, it won’t be possible to add 10/100 Ethernet to the BRK. However, RGMII configuration is possible.

Best,

Neeraj

 

Adding the RGMII configuration pins:

PD24 — ETH1_MDIO

PC24 — ETH1_MDC

PD22 — ETH1_RX_DV

PC20 — ETH1_RX_CLK

PC21 — ETH1_RXD0

PC19 — ETH1_RXD1

PD21 — ETH1_RDX2

PC11 — ETH1_RXD3

PD10 — ETH1_TX_EN

PC06 — ETH1_TX_CLK

PC07 — ETH1_TXD0

PD08 — ETH1_TXD1

PD14 — ETH1_TXD2

PD07 — ETH1_TXD3

 

• This reply was modified 1 year, 1 month ago by Neeraj Dantu.

[Author]

Posts