ADSP-SC589 console (ttySC0) not working after boot

Hi Larswad,

Have you tried with the default baud rate 57600, is that working?

BTW, Could you clarify the issue a little bit,

You have mentioned the issue for SC589 Console. But you reported the same it is working for the same SC589 by reaching the userspace. 

How you can cat the values without reaching the console?

root@sc598-devkit:~# cat /proc/devices

Sorry I didn't get your query clearly.

In addition, you can share the steps followed, complete bootlog, and dts file changes for reference. 

Thanks,

Prasanth R

Hi Prasanth!

Thanks your answering, much grateful!

I do realize I need to give you much more information.

Honestly I haven't (yet) tried 57600, since we see in the driver that the default is 115200 (and our getty starts with 115200, kernel bootargs are also specifying 115200 for console=ttySC0,115200). And also the 115200 setting works on our sc598 board. But I will try that just to rule it out (and of course changing the relevant parameters while tesitng that).

Why we can see things in userspace is because we do get network up and we can ssh in to the device, which is fine for troubleshooting. The device seems to be up in all aspects beside the console. It feels right now that we have turned every stone but can't understand the source of the problem.

We have done some debugging in the driver, by adding some pr_info or dev_info here and there. We do get a lot of frequent calls into "adi_uart4_serial_rx_dma_timeout", but we don't know if that is a normal behavior or not (I mean, whether the timeout is normally "driving" the rx handler). We can also see that if we do like 8 or more key presses in the minicom terminal that we start to get overrun errors in "adi_uart4_serial_dma_rx_chars" (the OE bit is set).

An interesting observation as a difference between the sc589 and sc598 boot logs is that the sc598 switches out the boot console with the real console, which can not be seen on the sc589.
Do we somehow perhaps have two drivers conflicting with each other (the earlycon / printk simple driver and the final dma controlled driver)?

I will here provide you with a boot log and our DTB file (we have not modified the sc58x.dtsi file or any of the other include, which are the original ones from the original release/yocto-2.1.0 branch). Our dts is much like the sc589-devkit dts, but with some removed hardware support that is not relevant for our board. I will also provide a boot log for our sc598 board that has a working console.

I will also give you our init file for initramfs and our inittab for the real file system. You will see in our init file that we have used the kmsg to debug our way to reach to the final file system.

I hope attachments work fine here in the forum :-)

Best regards,

Larswad

https://wadefalk.se/toadi/

Hi Prasanth!

Some more info:

Tried 57600, no go. Modified all relevant parameters, same result.

I was curious about why the following lines appeared in the 598 log and not for the 589: 

printk: console [ttySC0] enabled
printk: console [ttySC0] enabled
printk: bootconsole [adi_uart0] disabled
printk: bootconsole [adi_uart0] disabled

Adding a driver like FSL_LPUART (that is not relevant for the adi uart itself) made those lines appear on the 589 as well and that
was my suspicion after having followed that flow in the kernel.
The earlycon is not switched in / bootconsole switched out unless having a driver present that will make these calls. Our 598 config
happened to have the 8250 uart enabled which is another example of that (enabling 8250 on the 589 crashes kernel somewhere).

But, it didn't make any difference to the problem itself, the ttySC0 is not working, like I have described, its still the same behavior.

Can you actually confirm that the 589-devkit uar driver ever have had this working in the release/2.1.0 branch?

I am starting to doubt everything now. :-(

/Larswad

Hi Prasanth!

Some more info:

Tried 57600, no go. Modified all relevant parameters, same result.

I was curious about why the following lines appeared in the 598 log and not for the 589: 

printk: console [ttySC0] enabled
printk: console [ttySC0] enabled
printk: bootconsole [adi_uart0] disabled
printk: bootconsole [adi_uart0] disabled

Adding a driver like FSL_LPUART (that is not relevant for the adi uart itself) made those lines appear on the 589 as well and that
was my suspicion after having followed that flow in the kernel.
The earlycon is not switched in / bootconsole switched out unless having a driver present that will make these calls. Our 598 config
happened to have the 8250 uart enabled which is another example of that (enabling 8250 on the 589 crashes kernel somewhere).

But, it didn't make any difference to the problem itself, the ttySC0 is not working, like I have described, its still the same behavior.

Can you actually confirm that the 589-devkit uar driver ever have had this working in the release/2.1.0 branch?

I am starting to doubt everything now. :-(

/Larswad