[Neeraj Dantu]

Tomas,

You should see a new branch “kirstone” on meta-octavo-osd32mp1 here: https://github.com/octavosystems/meta-octavo-osd32mp1/tree/kirkstone. We are working on getting audio issues resolved. Apart from that, everything should be working.

Best,

Neeraj

[Neeraj Dantu]

Hey Ben,

As a quick check, can you make sure you have proper double quotation marks around the FIP_BL32_CONF variable? There could be a problem with the way the quotation marks are encoded. Can you check by deleting the quotation marks and re-entering them when you execute the command on the terminal?

Also, please make sure you have your FIP_DEPLOYDIR_ROOT assignment correctly as that is important. Please see https://octavosystems.com/app_notes/stm32mp1-cubemx-tutorial-for-osd32mp15x/ for more information on compiling using Developer Package.

Finally, please note that we stopped maintaining the BRK developer Package patches as we have moved to supporting Distribution Package: https://github.com/octavosystems/meta-octavo-osd32mp1. So, the latest sources in the BRK patches repo will only work for OpenSTLInux v2.x.

However, you can use the patches in meta-octavo and import them into the Developer Package. For example, uboot patches are available here: https://github.com/octavosystems/meta-octavo-osd32mp1/tree/dunfell/recipes-bsp/u-boot/files.

Best,

Neeraj

 

[Neeraj Dantu]

Hey Farid,

The kernel messages indicate an issue with voltage selection settings in the device tree. In the sdmmc3 node, an IO VCC supply may be needed. See example here: https://wiki.st.com/stm32mpu/wiki/SDMMC_device_tree_configuration. The property needed could be vqmmc-supply.

I am assuming you have VIO for the WiFi module set to 1.8V and the IOs of the MMC interface are pulled to 1.8V and not 3.3V.

If you have some time, please post some info about how you were able to resolve your earlier boot issue.

Thanks and Best,

Neeraj

[Neeraj Dantu]

Thanks Michal for a great reply.

Gil,

If you have an eMMC on board, you will need a way to program it. Michal described 2 ways to do it and both of them require different interfaces to be active:

1. You can program the eMMC by booting from a secondary source like an SD card interface(this would also require you to change boot mode). From the Linux image booted from the SD card, you can program the eMMC by using “dd”

2. You can also program the eMMC via USB device port(like in OSD32MP1-BRK or OSD32MP1-RED). You will need to use Cube Programmer to USB boot

There is a 3rd way to boot which also involves using Cube Programmer, but only requires a UART via Serial boot. You can send FSBL(TF-A) and SSBL(U-Boot) via serial using Cube Programmer while you set the boot mode to serial. Then you can program the eMMC via a communication interface enabled by the SSBL, generally this is Ethernet, because you do not have USB/SD card interfaces as described in #1 or #2.

Please take a look at https://www.st.com/resource/en/application_note/an5275-usb-dfuusart-protocols-used-in-stm32mp1-series-bootloaders-stmicroelectronics.pdf and https://wiki.stmicroelectronics.cn/stm32mpu/wiki/How_to_use_UART_as_serial_boot_device_with_STM32CubeProgrammer for more info.

Best,

Neeraj

[Neeraj Dantu]

Tomas,

Apologies for the delay in reply. We are testing the port right now on the dev boards. Repos should be updated this week. Thank you for your patience.

Best,

Neeraj

[Neeraj Dantu]

alexandre,

I am not sure what process the SIP pictured went through. If the SIP experienced delamination and cracking, then solder could come out from inside the SIP(could be MSL issue) but that may not be the cause of problem. Cause could be BGA desoldering process which could overheat the part for quick remove.

If it is MSL issue, please make sure you are following storage and reflow requirements described in sections 9.2 and 9.3 in the datasheet(https://octavosystems.com/docs/osd32mp15x-datasheet/)

Are you replacing or re-using the SIP? If so, you will need to be very careful not to damage the SIP.

You also need to dry bake board before removal and bake part before replacing on the baord. Board drying specs are different (lower T and longer duration).

Best,

Neeraj

[Neeraj Dantu]

Sreerag,

The power application note for OSD335x provides information on internal power configuration of the SiP: https://octavosystems.com/app_notes/osd335x-power-application-note/. Specifically, Figure 2 shows the power up sequencing of the SiP. You should be able to map the power up sequencing of the faulty boards against the sequence in Figure 2 to see where the PMIC is experiencing problems while powering up.

Also, make sure to test for the PMIC power rails for shorts. If the boards are operated out of spec, it could damage the PMIC power supplies.

Best,

Neeraj

[Neeraj Dantu]

Farid,

 

Few things to check:

1. For the device tree compatible property see https://www.kernel.org/doc/Documentation/devicetree/bindings/net/broadcom-bluetooth.txt for the appropriate naming scheme.

2. I would set pull-up/pull-down for pins in the pinmux section of the device tree

3. Make sure the driver is finding the right firmware file BCM43xx.hcd and that the file is named correctly. Looks like your file name is “BCM4345C0_003.001.025.0172.0344.1MW.hcd”, not sure this is what the driver is looking for..

4. The bootlog for a working board with Bluetooth should look something like this:

[   13.887871] Bluetooth: HCI device and connection manager initialized

[   13.892812] Bluetooth: HCI socket layer initialized

[   13.897656] Bluetooth: L2CAP socket layer initialized

[   13.956382] Bluetooth: SCO socket layer initialized

[   14.024362] Bluetooth: HCI UART driver ver 2.3

[   14.027388] Bluetooth: HCI UART protocol H4 registered

[   14.065541] Bluetooth: HCI UART protocol Broadcom registered

[   14.444703] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1

[   14.479055] Bluetooth: hci0: BCM: chip id 94

[   14.482570] Bluetooth: hci0: BCM: features 0x2e

[   14.488523] Bluetooth: hci0: BCM43430A1

[   14.490927] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000

[   14.498956] Bluetooth: hci0: BCM43430A1 ‘brcm/BCM43430A1.hcd’ Patch

[   14.678856] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1

[   14.768279] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43430/1 wl0: Feb 16 2020 22:39:24 version 7.45.98.97 (r724416 CY) FWID 01-bf41ed64

[   15.240495] Bluetooth: hci0: BCM4343WA1 37.4MHz Murata Type-1DX BT4.2-0093

[   15.245961] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0395

This is from bootlog for OSD32MP1-RED with CY4343W chipset. Comparing this to t=your log, it does seem like there bluetooth firmware file is not being loaded. Folks at Murata should be of more help on the chipset you are using.

Hope this helps.

Best,

Neeraj

 

[Neeraj Dantu]

Answered in another thread. You can use the patches in meta-octavo-osd32mp1 layer.

Best,

Neeraj

[Neeraj Dantu]

Pratik,

You are correct. You can use the patches for meta-octavo-osd32mp1 layer.

Best,

Neeraj

[Neeraj Dantu]

Pratik,

Thanks for the logs. This is interesting. From the logs it looks like the driver was unable to shutdown the peripheral successfully: https://github.com/torvalds/linux/blob/v5.4/drivers/tty/serial/stm32-usart.c#L644. Given that you are not seeing this on kernel 5.10, the bug must be fixed in the updates to the driver. Upgrading the kernel seems to be the easiest way to resolve this issue.

Best,

Neeraj

[Neeraj Dantu]

Thanks Aedan!

Pratik,

As it is clear that the behavior you are seeing cannot be reproduced independently, I would suggest looking at your board configuration. In addition to Aedan’s inputs, here are a few things to check:

1. Probe signals and see if you can actually see the traffic you are generating on each interface and narrow down where during the transmission you are running into issues.

2. Check the pinmux configuration(https://github.com/octavosystems/OSD32MP1-BRK-device-tree/blob/master/linux-v5.4/stm32mp157c-osd32mp1-brk.dts#L268) and peripheral configuration(https://github.com/octavosystems/OSD32MP1-BRK-device-tree/blob/master/linux-v5.4/stm32mp157c-osd32mp1-brk.dts#L1063) in the device tree as compared to the BRK on your custom board.

Best,

Neeraj

[Neeraj Dantu]

Noel,

Apologies for the late reply. It seems that your post was stuck in our SPAM filter.

Looking at the power up sequencing of the good part vs bad part you attached, it looks like several of the output rails do not come up. Specifically, LDO2, LDO3, DCDC2 and DCDC3 do not come up, indicating a short on 1 or more of these power rails. Can you check for shorts on these power rails?

Shorts like this could be caused if the recommended handling procedures are not followed. If you have more parts, we recommend you bake at 125C for 35 to 48 hours before you try to put them on the boards and reflow. The recommended handling procedure is described in sections 9.2 and 9.3 of the datasheet: https://octavosystems.com/docs/osd335x-sm-datasheet/

If you have X-ray capability, you can image the failed parts to see any solder flow inside the SiP.

Best,

Neeraj

[Neeraj Dantu]

Carlos,

The log indicates that there is no USB interface found on the board. Can you check if you defined the USB interface in u-boot device tree?

The patch you linked creates a new machine and a separate board.c initialization file for BRK. So, it may not work without further modification. The board.c in the patch is modified from the default ST board.c file to avoid use of STUSB1600 USB-C Controller chip as BRK implements a Micro-USB OTG port instead of a USB-C.

Best,

Neeraj

[Neeraj Dantu]

Tomas,

The current schedule has OpenSTLinux v4.0 support for end of Oct.

 

If you have any specific question or difficulty in the mean time, please feel free to generate a forum post. Thank you for your patience.

Best,

Neeraj

[Author]

Posts