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.
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.
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.
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.
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:
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.
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.