[Arcady]

Hi,

As I said in my previous messages, I think there is an issue with voltages or MMC initialization.
From meta-ti, in meta-ti/meta-ti-bsp/conf/machine/include/ti33xx.inc:

# Generate an extlinux.conf file
UBOOT_EXTLINUX = “1”
UBOOT_EXTLINUX_ROOT = “root=PARTUUID=${uuid}”
UBOOT_EXTLINUX_KERNEL_ARGS = “rootwait rw earlycon”
UBOOT_EXTLINUX_BOOT_FILES = ” \
extlinux.conf;extlinux/extlinux.conf \
${KERNEL_IMAGETYPE} \
${DEVICETREE_FILE} \
”

Normally the uuid variable should be configured by U-Boot, but I guess it doesn’t happen as expected.

Right now I also started having board powering issues.
When plugging in the USB power connector D1 flashes once and turns off immediately after.
Same goes when pressing the PWR button.
I will try finding a power cable to use the power jack port, but it might be the chip or PMIC specifically that suffered.

Best,

Arcady

[Arcady]

I remade the environment from scratch, and made sure to use the latest device tree along with the 6.6 kernel.
We get past the clock initialization issue, but still get errors especially on MMC setup.
You can find the logs attached, but basically the voltage regulators for MMCs aren’t getting configured properly, so we can’t open a root device on the SD card.
From line 248 onward you can see that only RAM partitions and detected, with neither the eMMC or SD partitions appearing there.

I might try using an older device tree on an older kernel, but there shouldn’t be any reason for the current setup to not work, especially since the device tree is in the kernel source…
I guessed using core-image-minimal might have led to drivers missing or something, but even with core-image-base I had the same issue.

Attachments:

1. log-mmc.txt

[Arcady]

Hi Neeraj,

I did see that the am335x-osd3358-sm-red.dts was in the Linux kernel, but I was wondering about the am335x-osd3358-sm-red-v4 device tree which I have only found in the BeagleBone kernel.
If by component version you mean the board version, it is labeled as “OSD335x-SM EVALUATION BOARD Rev 4”.
This “Rev 4” is exactly why I wanted to know more about the “v4” version of the device tree.
The OSD chip is labeled “OSD3358-512M-BSM 2123 PE230FDC0E”.

I tried builds with the Yocto kernel 6.6 (linux-yocto_6.6) and TI kernel 6.6 (linux-ti-staging_6.6), so it might be a kernel version issue.
Having set up my environment with Yocto branch Scarthgap I didn’t want to change it to the older Zeus branch, but considering that the default Debian image on the board uses kernel 4.19, that might very well be the issue.
Or clock related drivers maybe.

Best regards,

Arcady

[Arcady]

Hi Neeraj,

I have checked all the defconfig files I used and the “CONFIG_SOC_AM33XX=y” is always present.
I used the default defconfig included in meta-ti-bsp, the one from BeagleBone, and even the default one included with the Debian image, yet to no avail.
On the device tree side, the one you provide here (https://github.com/octavosystems/OSD335x-Device-Tree/tree/master/OSD3358-SM-RED) doesn’t work at all, the kernel doesn’t even start.
Maybe something drastically changed with Rev 4 of the evaluation board?
So I instead use am335x-osd3358-sm-red/am335x-osd3358-sm-red-v4 device trees which at least will display me the clock errors when earlyprintk is enabled.
And both these device trees are set to be compatible with “ti, am33xx”.
You can verify it here (https://github.com/beagleboard/linux/blob/master/arch/arm/boot/dts/ti/omap/am335x-osd3358-sm-red.dts) and here (https://git.beagle.cc/RobertCNelson/ti-linux-kernel-dev/-/blob/4.19.94-ti-rt-r73/patches/soc/ti/beagleboard_dtbs/0001-Add-BeagleBoard.org-Device-Tree-Changes.patch#L11725) for the v4.

Would you have up-to-date working dts/dtsi and dtb files?
My intention was simply to run Poky on the evaluation board to get the gist of making a Yocto BSP layer, to prepare for the upcoming C-SiP based custom board we are prototyping.
But right now things are rather worrying.

Best Regards,

Arcady

[Arcady]

I also tried moving from linux-yocto to linux-ti-staging for the kernel, but I still get the same error, so I guess this is a device tree issue.

[Arcady]

I just realized there was an upload error for the file:

“putty.log: Sorry, you are not allowed to upload this file type.”

Here is another attempt at uploading the file.

Attachments:

1. putty-log.txt

[Arcady]

Hi Neeraj,

Thanks for your response.

I have tried to using the config-pin tool but it didn’t solve my issue.
The pin mode did change but transmissions still failed.

I have also followed the PinMux guide to obtain a custom device tree and disabled overlays, yet it failed again.
Since I checked out the AM335x datasheet and the header file with pin data, there shouldn’t be any mistakes.

uart0 {
pinctrl-names = “default”;
pinctrl-0 = <&uart0_pins>;
status = “okay”;
};

uart1 {
pinctrl-names = “default”;
pinctrl-0 = <&uart1_pins>;
status = “okay”;
};

uart2 {
pinctrl-names = “default”;
pinctrl-0 = <&uart2_pins>;
status = “okay”;
};

uart0_pins: pinmux_uart0_pins {
pinctrl-single,pins = <
AM33XX_IOPAD(0x970, PIN_INPUT_PULLUP | MUX_MODE0)
AM33XX_IOPAD(0x974, PIN_OUTPUT_PULLDOWN | MUX_MODE0)
>;
};

uart1_pins: pinmux_uart1_pins {
pinctrl-single,pins = <
AM33XX_IOPAD(0x984, PIN_OUTPUT_PULLDOWN | MUX_MODE0)
AM33XX_IOPAD(0x980, PIN_INPUT_PULLUP | MUX_MODE0)
>;
};

uart2_pins: pinmux_uart2_pins {
pinctrl-single,pins = <
AM33XX_IOPAD(0x954, PIN_OUTPUT_PULLDOWN | MUX_MODE1)
AM33XX_IOPAD(0x950, PIN_INPUT_PULLUP | MUX_MODE1)
>;
};

At this point, I am getting quite confused as to what could be the root cause.
I’ll keep looking into the matter but it doesn’t seem very promising for now.

Best regards.

[Author]

Posts