ADSP-SC589 console (ttySC0) not working after boot

Moved to Linux for ADSP-SC5xx processors community

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, I'm working with Larswad on this same issue.

As a test, I'm trying to disable DMA and use interrupt-based uart tx/rx.

However, I have problems constructing a device tree that makes sense in this scenario.


Could you provide an example for how you would write the .dts for that, you could use sc58x.dtsi as a base as we use that for our own board as well.

It seems you would remove the dma specific nodes like:

But in the code there are references like this:

How would those appear in the device tree?

Hi Erik,

Kindly share your kernel configuration and the device tree file, If you have any changes in the dtsi file, share that too.

As you were using a custom board and custom build, I am not sure how exactly the solution can be given.  

I will check for the changes and let you know if there are any modifications that need to be done to fix this issue.

Thanks,

Prasanth R

Hi Prasanth!
Erik and I are troubleshooting the same problem.
In my earlier post I provided a link to the DTS and kernel config for our device and some other files like bootlogs etc. It's been granted by the forum administrators.

The .dtsi file has no modifications from the sc58x.dtsi, it's the very same one.

Hi Erik & Larswad,

As you were getting the serial console,  I don't see the issue with the uart-entries.

Only the user-space was not reachable in th serial port. As a quick check, could you check your inittab entries? I couldn't see the Getty entries which are missing that gets us the console in the serial port.

You can compare the inittab of SC598 & SC589, is it really missing?

Thanks,

Prasanth R

Hi again Prasanth!

Thanks for replying and checking on your side.

Yes, I understand that you reacted there on the inittab missing getty and I should have clarified (or sent the final file instead of the one from our yocto repo since it wasn't the actual one from the file built rd image). What we do in our recipe is that we during the build process add the getty launch with an echo statement. So actually it is there.
In fact it is the poky busybox inittab core recipe that does this for us, we don't change that behavior.
Sorry for giving you a misrepresentative file.

The other only thing that sticks out in our build is that we have our own bootloader (we do not use u-boot since it is far too bloated for us and doesn't fit our upgrade strategy very well). I cannot however imagine how that would affect things, especially since that works on the sc598-based boards we have.

Our own bootloader does make use of the uart, but with a very rudimentary initialization and logs out some minor texts before launching the kernel.

Our own investigations hasn't yet given any results. The whole thing is utterly strange.

Best Regards,

Lars