Yocto Linux build version 5.0.0 on ADSP-SC594 EZKIT - system freezes

Hi hkhauke ,

Is this stock yocto/linux with nothing else running whatsover?

Additionally, could you try the following steps with yocto 5.0.0:

- Load uboot via gdb as usual

- Once in uboot shell, run "run erase_spi"

NOTE: This will take some time, do not worry if there is no output. The process should take about 10-15mins.

- run "env default -a"
- run "run update_spi"

Alternatively, you could also attempt using the OSPI: github.com/.../Getting-Started-with-ADSP‐SC594-(Linux-for-ADSP‐SC5xx-Processors-5.0.0)

Hi,

thank you for your response.
I am using the stock yocto/linux - following in detail what is described on the website for version 5.0.0 Yocto/Linux build on a Ubuntu 24.04 host PC.

I tried what you proposed:

run erase_spi
env default -a
run update_spi

Then switch boot switch to option 1 and reset. The system boots as expected and is then up and running. I then left the room and after 30 minutes, the watchdog had restarted the device. Hence, problem is still present even though the hang seems not to start immediately. A few days ago my feeling was that the uptime is shorter the longer the board is on, therefore, I added a cooling capability on the device - without any real impact.

I also tried to run the OSPI option. However, I am not able to store the overall system on OSPI since the size of the image is too large (seems that OSPI is only 32 MB large).

By the way, the behavior of the linux is also kind of strange: Typing, e.g., "ip a" does not return unless I push return. Could also be that something is broken in the serial output of the Linux with version 5.0.0.

Thank you and best regards

hkhauke

hkhauke said:

I also tried to run the OSPI option. However, I am not able to store the overall system on OSPI since the size of the image is too large (seems that OSPI is only 32 MB large).

You can store the file system on the qspi, if you have another media present like a USB stick, that should work too. You can then run "run update_ospi_uboot_only" and only flash uboot onto the ospi and boot with bootmode 5 that way. The default command that is executed on autoboot or just "boot" is set at "bootcmd". So if you wanted to mix and match boot modes, you could give that a try as well.

hkhauke said:

Hence, problem is still present even though the hang seems not to start immediately.

As for the system after booting with qspi, we will try to reproduce on our side.

hkhauke said:

By the way, the behavior of the linux is also kind of strange: Typing, e.g., "ip a" does not return unless I push return. Could also be that something is broken in the serial output of the Linux with version 5.0.0.

Hmm, about the serial console, it sounds a bit strange. From what I understand, you type the command out - no delay, working as expected, press return - no response and return again - after which you get a response?

Is there any kernel panic or kernel crashes? Any logs to share?

I just got the system booting from USB external drive - memory stick. This works for version 5.0.0 BUT - again system freezes after a short moment and is not useable.

However, I did the same for version 3.1.2 and it works. Hence, for me to work with version 3.1.2 booting from USB memory stick is a good option for now. Hopefully all features for communication between DSPs and ARM core also work with version 3.1.2...

Searching this for a while, I finally found the option to override the "bootcmd" expression in uboot, but now the systems boots straight through which was the desired goal for the next development issues.

Regarding the serial console with version 5.0.0: I type "ip a". Then the information is shown but prompt is not back. Then I push return and see prompt twice. It seems hence that the first "return" after "ip a" was stuck.

can you try to run "run ramboot" from u-boot and if you experience same issue? I have closer look at this issue

I just running Yocto-5 from my current build and I can't reproduce same behaviour, so will need to get clean build and see if I can reproduce 

Yes, I started to "run ramboot" a few hours ago. The system was still stable after 6 hours - looks good. It does not show the weird console behavior reported earlier.

I could provide you with those six files (uboot, fitImage, root filesystem) which are stored in my /tftpboot folder for version 5.0.0 to give it a quick try.

Another update on this issue: I cross combined rootfs and kernels:

1) Rootfs from version 5.0.0, Kernel from version 3.1.2 -> System runs properly and stable for at least 30 minutes
2) Rootfs from version 3.1.2, kernel from version 5.0.0 -> System boots and hangs immediately

No log can be reviewed as the system freezes without any verbose output. I cannot even logon using ssh as the system does not live long enough to view the IP address.

Also, I have run the same tests on a second board today - same results, unfortunately. 

From these tests I conclude that the problem is related to the kernel itself and not a hw issue.

Best regards