Neeraj Dantu
Forum Replies Created
-
AuthorPosts
-
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
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
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
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
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
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
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
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
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
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
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
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
Doug,
Apologies, this was overlooked for updates. Will add to the next release.
Best,
Neeraj
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
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
-
AuthorPosts
