Post Go back to editing

ADSP-SC589 console (ttySC0) not working after boot

Category: Software
Software Version: Linux

Hello!

Custom Dunfell yocto build (not targeting devkit or ezkit).

After boot the /dev/ttySC0 is created, but console is not working (the earlycon gives however all kernel output to the point of getty starting)

When looking at /proc/drivers:

/dev/tty             /dev/tty        5       0 system:/dev/tty
/dev/console         /dev/console    5       1 system:console
/dev/ptmx            /dev/ptmx       5       2 system
ttyprintk            /dev/ttyprintk   5       3 console
adi-uart4            /dev/ttySC      4 64-67 serial
pty_slave            /dev/pts      136 0-1048575 pty:slave
pty_master           /dev/ptm      128 0-1048575 pty:master

Devices console and ttySC0 are created (/dev/serial0 however is NOT created):

crw--w----    1 root     tty         4,  64 Jan  1 04:16 /dev/ttySC0
crw-------    1 root     root        5,   1 Jan  1 04:11 /dev/console

Config options, following are set:

CONFIG_SERIAL_ADI_UART4
CONFIG_SERIAL_ADI_UART4_CONSOLE
CONFIG_SERIAL_DEV_BUS
CONFIG_SERIAL_DEV_CTRL_TTYPORT
CONFIG_TTY
CONFIG_UNIX98_PTYS
CONFIG_LDISC_AUTOLOAD
CONFIG_TTY_PRINTK
CONFIG_DEVMEM

We are starting the system in an initramfs file system, mounting emmc and loading up the real filesystem from emmc, doing switch_root to the real file system (as an overlay). All those parts work fine.

We have a similar setup on a sc598 64 bit, where the console works fine.

We can echo data successfully to /dev/printk.

cat /proc/devices gives:

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

Character devices:
1 mem
2 pty
3 ttyp
4 /dev/vc/0
4 tty
4 ttyS
4 ttySC
5 /dev/tty
5 /dev/console
5 /dev/ptmx
7 vcs
10 misc
13 input
29 fb
89 i2c
90 mtd
128 ptm
136 pts
248 rpmb
249 ttyLP
250 bsg
251 watchdog
252 rtc
253 tpm
254 gpiochip

Block devices:
7 loop
31 mtdblock
179 mmc
259 blkext

cat /proc/tty/driver/adi-uart4 gives:
serinfo:1.0 driver revision:
0: uart:ADI-UART4 mmio:0x00000000 irq:0 tx:0 rx:0 oe:2 RTS|CTS|DTR|DSR|CD

On the sc598 build (where console works) we get:

cat /proc/tty/driver/adi-uart4  
cat /proc/tty/driver/adi-uart4
serinfo:1.0 driver revision:
0: uart:ADI-UART4 mmio:0x00000000 irq:0 tx:2689 rx:65 RTS|CTS|DTR|DSR|CD
(we can tx and rx increments as it should)

The related boot messages for the uart we get are:

ADI serial driver
adi-uart4 31003000.uart: Serial probe
31003000.uart: ttySC0 at MMIO 0x0 (irq = 0, base_baud = 7031250) is a ADI-UART4

Kernel bootargs:
clkin_hz=25000000 earlycon=adi_uart,0x31003000 console=ttySC0,115200 ignore_loglevel mem=224M clkin_hz=25000000 earlyprintk=serial,uart0,115200 ignore_loglevel mem=224M console=ttySC0,115200

In our machine configuration:
SERIAL_CONSOLE ?= "115200 ttySC0"
SERIAL_CONSOLES ?= "115200;ttySC0"

In our inittab the getty is started as:

ttySC0::respawn:/sbin/getty 115200 ttySC0

Have tried lots of varying configuration options but running out of ideas. Can anyone please help or provide clues to what goes wrong?

If needed I can provide devicetree configuration.



correcting about the boot messages
[edited by: Larswad at 8:18 AM (GMT -5) on 17 Jan 2023]
Parents
  • 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:


    // dmas = <&dma_cluster2 20>, <&dma_cluster2 21>;
    // dma-names = "tx", "rx";

    But in the code there are references like this:

    uart->tx_irq = platform_get_irq_byname(pdev, "tx");
    uart->rx_irq = platform_get_irq_byname(pdev, "rx");
    uart->status_irq = platform_get_irq_byname(pdev, "status");

    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.

Reply Children
  • 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