Running Poky

[Arcady]

Hello,

For the past few days I have been trying to run a custom-built image on the OSD3358-SM-RED using Yocto.
I simply started from the meta-ti-bsp layer, created a custom layer with a osd3358-sm-red machine config, and tried to get the kernel to start with the default Poky distro and some configs.
I am now at a point where I can’t figure things out myself anymore and need some help.
I have attached the putty log file that shows the messages displayed by u-boot and the early stages of the kernel initialization.
There are apparently some clock errors that causes the kernel to panic and hang up, but I can’t pinpoint the issue nor tell how to fix it.
It could partially be due to the defconfig file I picked (https://github.com/RobertCNelson/bb-kernel/blob/am33x-v6.6/patches/defconfig) although I think that this was the way suggested in another post, and I have matched the kernel version to the one I use.

I also spent a lot of time trying to get the kernel to even start, and it turned out to be a device tree issue.
At first I was trying to do it properly, by creating a patch file for the kernel to add the device tree sources (https://github.com/octavosystems/OSD335x-Device-Tree).
But the kernel woud not boot with it, and the compiled file size was also smaller than the pre-compiled version, so there probably was an issue.
I therefore tried to use the pre-compiled version but it didn’t work either.
In the putty log you can see that u-boot loads the osd3358-bsm-refdesign.dtb file but that is actually the am335x-osd3358-sm-red-v4.dtb file renamed, and the only one with which I managed to even start the kernel.
So I would like to get the sources of the working device tree and instructions on how to properly compile it within Yocto.

Best regards.

PS:
I previously had posted a “Using UART” topic, to which I respond quite early on, but only now do I see my reply appearing.
Similar messages might keep poping up since I tried to reply multiple times.
And it also worries me that I might not be able to reply on this new topic either if such bugs persist.

[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]

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.

[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

[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

[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

[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]

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

[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

[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

[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

[Author]

Posts