[Farid Azhar]

Hi Neeraj,

Thanks for your response. We found the problem and fixed it.

The WiFi module’s VBAT supply needs 3.3V to operate but in our device tree it was powered by 1.8V from buck4 that’s why it was failing to initialize.

We changed the VBAT supply to 3.3V (ldo5) and WiFi module initialize and works OK.

We don’t need vqmmc-supply for WiFi module, leaving the strapping option pin (GPIO_7) unconnected sets it for 1.8V.

Regarding the earlier boot issue, we didn’t change anything in software. Just clean the area on board around strapping option pin (GPIO_7) may be it was shorting, not sure, but board starts booting with eMMC working at 1.8V.

Thanks again for your help.

/Farid

 

[Farid Azhar]

few more mmc logs ..

$ dmesg | grep -i mmc

[    3.146380] mmci-pl18x 48004000.sdmmc: allocated mmc-pwrseq

[    3.151679] mmci-pl18x 48004000.sdmmc: mmc0: PL180 manf 53 rev1 at 0x48004000 irq 48,0 (pio)

[    3.187294] mmci-pl18x 58007000.sdmmc: mmc1: PL180 manf 53 rev2 at 0x58007000 irq 54,0 (pio)

[    3.201548] mmci-pl18x 48004000.sdmmc: no support for card’s volts

[    3.206280] mmc0: error -22 whilst initialising SDIO card

[    3.261074] mmci-pl18x 48004000.sdmmc: no support for card’s volts

[    3.267396] mmc0: error -22 whilst initialising SDIO card

[    3.327512] mmc1: new HS200 MMC card at address 0001

[    3.332902] mmcblk1: mmc1:0001 X29128 117 GiB

[    3.337005] mmcblk1boot0: mmc1:0001 X29128 partition 1 4.00 MiB

[    3.343798] mmcblk1boot1: mmc1:0001 X29128 partition 2 4.00 MiB

[    3.348819] mmcblk1rpmb: mmc1:0001 X29128 partition 3 4.00 MiB, chardev (243:0)

[    3.359377] mmci-pl18x 48004000.sdmmc: no support for card’s volts

[    3.364471] mmc0: error -22 whilst initialising SDIO card

[    3.381567]  mmcblk1: p1 p2 p3 p4 p5 p6

[    3.424181] mmci-pl18x 48004000.sdmmc: no support for card’s volts

[    3.428925] mmc0: error -22 whilst initialising SDIO card

 

[Farid Azhar]

Board has started booting up in kernel but failing to initialize WiFi module.

Its generating following error and $ ifconfig is not showing up wlan0 interface.

[    3.204544] mmc0: error -22 whilst initialising SDIO card

• This reply was modified 2 years ago by Farid Azhar.

[Farid Azhar]

Hi Neeraj,

Thanks for your response, it really helped.

Setting the pull-down for RTS/CTS pins in the pinmux section fixed the problem. Bluetooth is working now.

The BT Firmware ver is correct, I’ve checked it with Murata earlier.

“BCM4345C0_003.001.025.0172.0344.1MW.hcd” is renamed to “BCM4345C0.hcd” on the device as expected by the driver.

Regards,

/Farid

 

[Farid Azhar]

Hi Neeraj,

Thanks for your response.
You are right. The problem appears to be in dfu driver. I added lots of debug traces and and Flash the same eMMC image (.tsv, .stm32 etc) to RED board and our NEW board.
Flashing on RED board works OK but fail on NEW board.
Comparing the logs shows that NEW board it is failing at dfu_read() function, it is trying to download the binary file from eMMC rootfs partition Not from the virtual partition.
I tested on Cube Programmer version 2.10.

Following are some logs and code reference where these logs are captured.

https://github.com/STMicroelectronics/u-boot/blob/v2020.10-stm32mp/drivers/dfu/dfu.c#L637
*** On RED board ***
DFU alt settings list:
dev: eMMC alt: 0 name: @fsbl1/0x04/1*8Me layout: RAW_ADDR
dev: eMMC alt: 1 name: @fsbl2/0x05/1*8Me layout: RAW_ADDR
dev: eMMC alt: 2 name: @fip/0x06/1*2Me layout: RAW_ADDR
dev: eMMC alt: 3 name: @boot/0x21/1*64Me layout: RAW_ADDR
dev: eMMC alt: 4 name: @vendorfs/0x22/1*16Me layout: RAW_ADDR
dev: eMMC alt: 5 name: @rootfs/0x23/1*14945Me layout: RAW_ADDR
dev: VIRT alt: 6 name: @virtual/0xf1/1*512Be layout: RAW_ADDR
dev: VIRT alt: 7 name: @OTP/0xf2/1*512Be layout: RAW_ADDR
dev: VIRT alt: 8 name: @PMIC/0xf4/1*8Be layout: RAW_ADDR
*** On NEW board ***
DFU alt settings list:
dev: eMMC alt: 0 name: @fsbl1/0x04/1*4Me layout: RAW_ADDR
dev: eMMC alt: 1 name: @fsbl2/0x05/1*4Me layout: RAW_ADDR
dev: eMMC alt: 2 name: @fip/0x06/1*2Me layout: RAW_ADDR
dev: eMMC alt: 3 name: @boot/0x21/1*64Me layout: RAW_ADDR
dev: eMMC alt: 4 name: @vendorfs/0x22/1*16Me layout: RAW_ADDR
dev: eMMC alt: 5 name: @rootfs/0x23/1*119293Me layout: RAW_ADDR
dev: VIRT alt: 6 name: @virtual/0xf1/1*512Be layout: RAW_ADDR
dev: VIRT alt: 7 name: @OTP/0xf2/1*512Be layout: RAW_ADDR
dev: VIRT alt: 8 name: @PMIC/0xf4/1*8Be layout: RAW_ADDR

Note: alt 0, 1 and 5 names are different. Is this due to eMMC difference on two boards?

https://github.com/STMicroelectronics/u-boot/blob/v2020.10-stm32mp/drivers/dfu/dfu.c#L462
dfu_read()
dfu_read: name: @virtual/0xf1/1*512Be buf: 0xddf2d7c0 size: 0x1000 p_num: 0x0 i_buf: 0x00000000 => On RED board
dfu_read: name: @rootfs/0x23/1*119293Me buf: 0xddf2d7c0 size: 0x1000 p_num: 0x0 i_buf: 0x00000000 => On NEW board

https://github.com/STMicroelectronics/u-boot/blob/v2020.10-stm32mp/drivers/dfu/dfu.c#L302
dfu_transaction_initiate()
dfu_transaction_initiate: @virtual/0xf1/1*512Be dfu->r_left: 512 [B] => On RED board
dfu_transaction_initiate: @rootfs/0x23/1*119293Me dfu->r_left: 533725184 [B] => On NEW board

https://github.com/STMicroelectronics/u-boot/blob/v2020.10-stm32mp/drivers/dfu/dfu.c#L483
dfu_read()
if (ret < size) {
(ret 9 < size 4096) => On RED Board
(ret 4096 < size 4096) => On NEW board

RED board satisfies above condition, print “UPLOAD … done” message and moves to next stage
NEW board fails above condition and stuck.

I coundn’t figure out what is the root cause of failure on NEW board.
Is some thing different in “dfu_alt_info” environment? how to update it?
Is this due to eMMC difference between two boards or something missing in dts files.

Your help is much appreciated.

[Farid Azhar]

I verified USB-A is working for flashing, downloading TF-A binaries to SRAM and DDR.
It is failing when trying to download TF-A binary to eMMC boot1 partition ID: 0x04 (first boot area) at offset 0x0.

Heres are the complete logs …

../deploy$ STM32_Programmer_CLI -c port=USB1 -log ~/emmc_flash.log -vb 1 -w FlashLayout_emmc_stm32mp157c-osd32mp1-new-trusted.tsv
——————————————————————-
STM32CubeProgrammer v2.8.0
——————————————————————-

Log output file: ~/emmc_flash.log

USB speed : High Speed (480MBit/s)
Manuf. ID : STMicroelectronics
Product ID : DFU in HS Mode @Device ID /0x500, @Revision ID /0x0000
SN : 004400343239511837383434
FW version : 0x0110
Device ID : 0x0500
Device name : STM32MP1
Device type : MPU
Device CPU : Cortex-A7

Start Embedded Flashing service

Memory Programming …
Opening and parsing file: tf-a-stm32mp157c-osd32mp1-new-usb.stm32
File : tf-a-stm32mp157c-osd32mp1-new-usb.stm32
Size : 225572 Bytes
Partition ID : 0x01

Download in Progress:
[==================================================] 100%

File download complete
Time elapsed during download operation: 00:00:00.493

RUNNING Program …
PartID: :0x01
Start operation done successfully at partition 0x01

Flashlayout Programming …
[==================================================] 100%
Running Flashlayout Partition …
Flashlayout partition started successfully

Memory Programming …
Opening and parsing file: fip-stm32mp157c-osd32mp1-new-trusted.bin
File : fip-stm32mp157c-osd32mp1-new-trusted.bin
Size : 1021582 Bytes
Partition ID : 0x03

Download in Progress:
[==================================================] 100%

File download complete
Time elapsed during download operation: 00:00:01.267

RUNNING Program …
PartID: :0x03

Reconnecting the device …

USB speed : High Speed (480MBit/s)
Manuf. ID : STMicroelectronics
Product ID : USB download gadget@Device ID /0x500, @Revision ID /0x2001, @Name /STM32MP157C?? Rev.Z,
SN : 004400343239511837383434
FW version : 0x0110
Device ID : 0x0500
Start operation done successfully at partition 0x03
Error: an error occured while uploading data from the virtual partition 0xF1
Received PhaseID == 0xFF, system is going to reboot
../deploy$

[Farid Azhar]

Hi Neeraj,

We’ve received our custom board from manufacturing.
We’ve changed the USB-C (OTG) to USB-A (Device). I’ve modified the USB node (usbotg_hs) in kernel and u-boot dts files same as BRK board dts files. We are now running on SDKv3.

When I tried to flash the eMMC using STM32_Programmer_CLI (on ubuntu laptop), it failed after downloading the partition 0x03 binary.
Following logs shows USB devcice failed to re-connect and download partition 0x04.
lsusb shows usb is not in dfu mode anymore.

I also tried to flash a BRK board SD card with STM32_Programmer_CLI and same tsv file, I got exactly the same error.
I would appreciate any help.
Thanks.

Farid.

:
Flashlayout Programming …
[==================================================] 100%
Running Flashlayout Partition …
Flashlayout partition started successfully

Memory Programming …
Opening and parsing file: fip-stm32mp157c-osd32mp1-red-trusted.bin
File : fip-stm32mp157c-osd32mp1-red-trusted.bin
Size : 1021582 Bytes
Partition ID : 0x03

Download in Progress:
[==================================================] 100%

File download complete
Time elapsed during download operation: 00:00:01.986

RUNNING Program …
PartID: :0x03

Reconnecting the device …

Error:
Unable to reconnect the target device: time out expired

Error: Start operation failed at partition 0x03
Error: TSV flashing service failed

[Farid Azhar]

Hi carlos,
Thanks for pointing out the osd32mp1-xyz-u-boot.dtsi file. It didn’t show up in my search for files to be updated. I added this file and u-boot works ok.
New board image build is OK and I can flash and boot from both sdcard and emmc.
Thank you for your help.

[Farid Azhar]

Hi Carlos, Thanks for your response.
I verified the deploy/bootfs directory has correct extlinux.conf and dtb files.
I also tried “make bootfs” and “make ssbl” and “make clean” but its not working.
I tried both, bothing from SD card and eMMC and they both appears to be failing to start u-boot after flashing u-boot binary (u-boot-osd32mp1-xyz-trusted.stm32).

I’m able to build and flash successfully the card type “osd32mp1-red” but not the new card type “osd32mp1-xyz”, even though all the code and DTS fiels are identical except name change.

I noticed a difference in file size of u-boot binary of new card vs old card, all other file sizes are same.
Something is making the u-boot binary different then OSD32MP1-RED board and that is failing.
Is there a secure build option for u-boot that I’m missing?

804459 Jan 12 12:40 u-boot-osd32mp1-xyz-trusted.stm32 => This one does not work
807692 Jan 12 14:08 u-boot-osd32mp1-red-trusted.stm32 => This one works OK

[Farid Azhar]

Hi Neeraj,
Thanks for your response.
I looked at the links you provided, but didn’t get the answer I’m looking for.
We want to configure the USB2 in Client/Device mode not the Host or OTG. We’ve made the HW changes on USB-C (OTG) circuitry and want to know what changes we need to do in the Devcietree to reflect this changes.

[Farid Azhar]

Hi Neeraj,
Thanks for your response. I understood, we can not control USB peripheral via M4 core.
We have made some HW changes to the USB-C (OTG) port, since we want to use it as a Device (not OTG).
We have replaced the USB-C port wkth a USB-A port and connected it directly to SiP USB signals (USB_DM2, USB_DP2) passing through an ESD.
We have removed the USB Type-C controller (U24 – STUSB1600AQTR) and associated circuitry.
USB_DM2 -> ESD -> USB-A (Device)
USB_DP2 -> ESD -> USB-A (Device)
I beleive I have to make some changes in DeviceTree and Kernel to make it work, but not sure where to do these changes.
I would appreciate if you could give me some direction.
Thanks.

Farid.

[Farid Azhar]

This problem resolved after connecting the RF Antenna (https://www.digikey.ca/en/products/detail/anaren/66089-2430/3903374).
I was not usng the Antenna before. It looks Hitron modem/router needs more strong WiFi signals to do the authentication.

[Author]

Posts