[Neeraj Dantu]

Good to hear!

If the device is being powered down and powered back up, that should reset any fault that has occurred previously, unless somehow the PMIC internal state machine was still powered. See Section 8.4 of the PMIC datasheet(https://www.ti.com/lit/ds/symlink/tps65217.pdf) for the state machine.

I will look at the layout to see if I have additional inputs.

Best,

Neeraj

[Neeraj Dantu]

Arcady,

 

I think the panic is specifically because the configuration you have is not setting the variable ${uuid}.

From the logs you attached previously:  “panic from mount_root_generic+0x1e8/0x290”

From a power perspective, trying the AC input(power jack) would be a good step. If issue persists, the PMIC power up sequence would need to be investigated to determine root cause to see where it is failing.

Best,

Neeraj

[Neeraj Dantu]

Alvan,

The trace width to 5V AC input could be an issue due to in-rush(~1500mA). There are 3 traces 5 mil each, I am not sure whether that is the issue.

I did notice on 2nd look that 3.3V is also needed from the connector H2. Is this being supplied as well? Sequencing wise, this 3.3V should come ON with SYS_VOUT.

The messages you shared in the screenshot, do they appear immediately one after another? or does the board take ~30 sec for each header message print? If it is immediate, it is more likely that there is an issue with the Power system as PMIC tries to power up immediately after 1 sec or so of failure. If it is longer, SPL(first stage bootloader) might be running into problems resulting in a software related fault, which resets the board because of watchdog timer expiration.

You can try using the USB input as it looks like you have brought it out to a big via and it has better routing.

Let me know of progress in debug.

Best,

Neeraj

[Neeraj Dantu]

Arcady,

The issue seems to be that the root file system path is not set correctly::

[    2.525290] VFS: PARTUUID= is invalid.

[    2.525290] Expected PARTUUID=<valid-uuid-id>[/PARTNROFF=%d]

[    2.534799] Disabling rootwait; root= is invalid.

[    2.541670] /dev/root: Can’t open blockdev

[    2.545874] VFS: Cannot open root device “PARTUUID=” or unknown-block(0,0): error -6

[    2.553708] Please append a correct “root=” boot option; here are the available partitions:

Please review bootcmd: “append: root=PARTUUID= rootwait rw earlycon console=ttyS0,115200n8,115200”

It looks like root and PARTUUID are not being set.

Best,

Neeraj

[Neeraj Dantu]

Alvan,

Here are some pointers:

1. If you need to program the EEPROM, you will need to connect the EEPROM_WP(write protect) to GND. Can you verify that the EEPROM was programmed after you write to it? If SPL is running into an error, presumably because of a blank EEPROM, the watch dog timer may be resetting the board, resulting in the boot cycling

2. From the design repository, it looks like AC input line for OSD3358 SiP could be a bottleneck for current because of trace width. Are you powering the device through USB input or the AC input?

3. You can generate custom images using the beagle SDK for OSD3358-SM-RED here: https://github.com/RobertCNelson/omap-image-builder/tree/master/octavo including images that boot with blank EEPROM

Best,

Neeraj

[Neeraj Dantu]

Arcady,

What versions of components are you using? OSD3358-SM-RED device tree is mainlined. See here: https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/ti/omap/am335x-osd3358-sm-red.dts.

I am waiting on a RED board to do testing, I will report back when I have some additional info.

Best,

Neeraj

[Neeraj Dantu]

Arcady,

Looking at the error message, it looks like it is originating here: https://github.com/torvalds/linux/blob/v6.6/drivers/clk/ti/clkctrl.c#L578. Can you check if you have the right config file that defines CONFIG_SOC_AM33XX(https://github.com/torvalds/linux/blob/v6.6/drivers/clk/ti/clkctrl.c#L548) and if you defined the compatible property for the board in the device tree with “ti, am33xx” as being checked here: https://github.com/torvalds/linux/blob/v6.6/drivers/clk/ti/clkctrl.c#L549?

Best,

Neeraj

[Neeraj Dantu]

Doug,

Apologies, this was overlooked for updates. Will add to the next release.

Best,

Neeraj

[Neeraj Dantu]

Gil,

(1) & (2) – Yes you are correct.

 

(3) – The patch is essentially checking whether the regulator was set as “always on” supply in the device tree. If it is configured as an always on regulator, it will not turn the regulator off even when a function call is made to turn it off.

Best,

Neeraj

[Neeraj Dantu]

Arcady,

The pinmux should be setup parts of the device tree overlay. You can make sure you are using the right pins looking at the pinmux section of the overlay(for example: https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-UART2-00A0.dts#L29).

You can also use the config-pin utility to check on the pinmux states of the pins: https://github.com/beagleboard/bb.org-overlays/blob/master/tools/pmunts_muntsos/config-pin.c.

Depending on your kernel version and config, you should also be able to “cat /sys/kernel/debug/pinctrl” to get status of all pinmux for the device.

The bootlog you posted indicates that drivers were successfully initialized for several UARTs. So, it is probably a pinmux issue.

Best,

Neeraj

[Neeraj Dantu]

Gil,

The patch has been integrated into newer releases of OpenSTLinux. So, I would use the patch as opposed to the DT work around.

Best,

Neeraj

[Neeraj Dantu]

Gil,

From the bootlog of the failure, it looks like CMD13 issued by TF-A is not getting a response from the SD card. See detail here: https://chlazza.nfshost.com/sdcardinfo.html.

 

I found https://community.st.com/t5/stm32-mpus-products/stm32mp1-occasionally-emmc-boot-fail-with-quot-cmd13-failed/td-p/108285 on ST’s forums looks very close to what you are seeing. The issue you are encountering may be because power cycling of the regulator that supplied power to the SD card during TF-A execution.

The solution proposed by ST: https://community.st.com/t5/stm32-mpus-embedded-software/when-updating-from-arm-trusted-firmware-v2-4-stm32mp-r1-to-arm/td-p/94079 is a patch that disables this cycling. Can you try this solution and check if the issue still exists?

Best,

Neeraj

[Neeraj Dantu]

Hey Gil,

A few questions on the board behavior:

1. When you observe DDR at 0V, do you see all the other power rails with RANK 0 coming up normally?

2. Is this ‘erratic’ boot observed on all the prototypes?

 

As   Michal suggests, it may be that TF-A execution is running into error. Can you post the boot log file when the failure is observed?

You are correct that TF-A would bring up DDR power rail and initialize the clocks and DDR interface. TF-A is being read from SD card. If you don’t observe any boot logs when boot fails, it could be that the SD interface may be failing to transfer TF-A. I would try using a different SD card to see if that fixes the issue.

If TF-A successfully initializes and runs, the logs could give you an indication of where execution if failing. See https://wiki.st.com/stm32mpu/wiki/How_to_debug_TF-A_BL2 for additional help on enabling traces.

Best,

Neeraj

[Neeraj Dantu]

Ryan,

Please take a look at the Beaglebone Black Wireless(https://github.com/beagleboard/beaglebone-black-wireless/blob/master/BeagleBone_Black_Wireless_SCH.pdf) for an example use of MMC2. In this design, MMC2 is used for WiFi as SDIO interface.

Best,

Neeraj

[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

[Author]

Posts