[Neeraj Dantu]

mlarkin, Ronan,

Apologies for the delay. Please find a patch for OpenSTLinux version 6.1 OPTEE attached to this forum post. We are working on adding the support for OPTEE boot mode for latest OpenSTLinux under meta-octavo. I will push a new meta-octavo layer update in the next week.

Best,

Neeraj

Attachments:

1. 0001-Add-OSD32MP1-BRK-board-support.patch

[Neeraj Dantu]

Gil,

The device tree attached shows that GPIOE8 has the internal pull-up enabled. However, there should not be a measurement discrepancy between u-boot CLI and measurement.

Here is an interaction I just had on the CLI to show status of GPIOE8 on the RED board:

STM32MP> gpio input GPIOE8 gpio: pin GPIOE8 (gpio 72) value is 0 STM32MP> gpio status GPIOE8 Bank GPIOE: GPIOE8: input: 0 [ ]

1 2 3 4 5 6 7 8 9

STM32MP> gpio input GPIOE8   gpio: pin GPIOE8 (gpio 72) value is 0   STM32MP> gpio status GPIOE8   Bank GPIOE:   GPIOE8: input: 0 [ ]

 

 

[Neeraj Dantu]

Budimir,

There are better ways for device tree modification:

1. Developer Package: https://wiki.st.com/stm32mpu/wiki/How_to_compile_the_device_tree_with_the_Developer_Package (Keep track of kernel version you are using and match the developer package kernel version)

2. Distribution Package: https://wiki.st.com/stm32mpu/wiki/How_to_compile_the_device_tree_with_the_Distribution_Package

3. Use the Debian SDK: https://github.com/octavosystems/osd32mp1-build-tools/blob/master/Makefile#L148

I am not sure whether this is happening on OSD32MP1-RED, but bootloader and kernel can modify the device tree at runtime.

Best,

Neeraj

[Neeraj Dantu]

spengler,

First thought is that you should check the card detect pin. It is different for OSD32MP1-RED and OSD32MP1-BRK. If you are using BRK device tree, the card detect pin is set to PG7(https://github.com/octavosystems/OSD32MP1-BRK-device-tree/blob/kirkstone/u-boot-v2021.10-stm32mp-r1/stm32mp157c-osd32mp1-brk.dts#L881).

Best,

Neeraj

[Neeraj Dantu]

Manish,

Initial look into the schematics does not reveal anything obviously incorrect. Although 1 thing I noticed was both pull-ups and pull-downs for Address setting of IC1 seem to be populated, which might mess withe EEPROM configuration as EEPROM inside OSD3358-SM is on address 0x50. May not be an issue, but recommend checking and making sure the external EEPROM is on a different address.

If you are getting outputs on power rails, that would mean that the PMIC is up. Can you double check all voltage rails are OK according to https://octavosystems.com/app_notes/osd335x-sm-power-application-note/?

When there is no SD card, do you get “CCCC” output on UART0? If so, this is an indication that the processor has booted correctly and searching for a boot media.

The other things to check is 24MHz and 32KHz clock signals.

One way you can completely bypass EEPROM is by using EEPROM Blank image as described in https://github.com/RobertCNelson/omap-image-builder/tree/master/octavo. You can build this image on your machine by selecting octavo-blank-eeprom.conf while running https://github.com/RobertCNelson/omap-image-builder/tree/master/octavo#generate-image-file.

When booting with the SD card, you should be able to see activity on SD CLK and CMD lines, if you have an oscilloscope, this would be a debug step to understand whether the processor is attempting to boot from the SD card.

Please let us know if you have an update on the debug,

Best,

Neeraj

[Neeraj Dantu]

David,

1. The parameters that are default for Beagleboards can be used for OSD3358. Because how close the DDR is to the SoC, a range of parameters work well. Please take a look at Section 6.2 of the datasheet(https://octavosystems.com/docs/osd335x-datasheet/) for the parameters that Octavo publishes and recommends.

2. Please contact sales@octavosystems.com for purchase information.

Best,

Neeraj

[Neeraj Dantu]

Alexio,

Do you mean early_system_init() here: https://github.com/u-boot/u-boot/blob/master/arch/arm/mach-omap2/am33xx/board.c#L504 ?. If you are referring to this location, this is SPL still running out of AM335x internal SRAM. sdram_init() is called after board_early_init_f().

In addition to the inputs on the other thread, another thing to try is using Starterware for AM335x here: https://www.ti.com/tool/download/STARTERWARE-AM335X/02.00.01.01. You can use code composer studio(CCS) to run baremetal example applications via JTAG as another avenue for debug. One step further is debugging SPL in CCS: https://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components/U-Boot/Apps-SPL-Debug.html.

Best,

Neeraj

[Neeraj Dantu]

Alexio,

I am not sure about the u-boot version that the log posted above uses, but SPL  in newer versions does a preliminary size check for DDR that would error out if there is an issue with the DDR here: https://github.com/u-boot/u-boot/blob/master/arch/arm/mach-omap2/am33xx/board.c#L501.

Q: Does the PMIC stay ON after the board encounters an error?

Q: Is it possible for you to point to the location where the fault occurs in u-boot?

My suspicion right now is a cold solder joint causing an in-rush based error. Please also let us know the status of how many boards you built/how many are failing this way. All units behaving the same way could indicate something systemic.

Please take a look at “Setup early (debug) UART” section of https://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/How_to_Guides/Board_Port/U-Boot.html for more information on enabling UART outputs in early boot.

Best,

Neeraj

[Neeraj Dantu]

Doug,

Yes, SYSBOOT configuration is latched at power on reset. After that, you can use these pins for other functions. Some Beagleboards and OSD3358-SM-RED use these pins for LCD interface.

If you are getting a ‘busy’ status, that may be because they are being used for some other interface elsewhere in the device tree. I would review the device tree to see if there is any pinmux other than the UART being setup for these pins.

Best,

Neeraj

[Neeraj Dantu]

Doug,

Beaglebone Black wireless(https://github.com/beagleboard/beaglebone-black-wireless/blob/master/BeagleBone_Black_Wireless_SCH.pdf) uses MMC2 interface for WiFi. MMC0 is used for SD card and MMC1 is used for eMMC. All 3 MMC interfaces are used.

I have seen issues with WiFi modules such as https://e2e.ti.com/support/processors-group/processors/f/processors-forum/541016/am335x-error-message-in-sdio-driver. Do you know whether the module vendor supports AM335x? Please review the config files as well as firmware to see if they are platform(SoC) specific. If you can you post the log, we can take a closer look.

Best,

Neeraj

[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

[Author]

Posts