JTAG DCC/hvc console Colibri IMX6

Technical Support
, , , ,
1

Hello,

My intention is to use linux serial console over JTAG. Currently our board has an UART for that but eventually we must have all of the UART ports for other use, so it will not be useable in the future.

I’m using Lauterbach/Trace32 as client. I’ve succesfully gotten the console setup to the point that I get kernel boot prints, so I know that HW and kernel image should be OK to that point. As a sidenote I got the console to work by setting CONFIG_HVC_DCC in the kernel and setting hvc0 as console in u-boot.

So the actual issue is that when booting, the kernel hangs when it’s setting up serial consoles. I can get the terminal prints and dmesg using lauterbach. Below are the final lines that both of them output (debug_initcall used).

JTAG is present at the colibri evaluation board, so I assume that someone has done this before?

Additional info:

  • JTAG debugging works
  • Kernel debugging works
  • T32/Lauterbach control works

Console:

[ 0.318254] mxc_sdc_fb fb@0: 640x480 h_sync,r,l: 64,16,80 v_sync,l,u: 4,3,13 pixclock=23750000 Hz

[ 0.367908] mxc_sdc_fb fb@0: 640x480 h_sync,r,l: 64,16,80 v_sync,l,u: 4,3,13
pixclock=23750000 Hz

[ 0.387392] Console: switching to colour frame buffer device 80x30

[ 0.413721] mxc_sdc_fb fb@1: mxcfb1 is turned off!

[ 0.417239] imx-sdma 20ec000.sdma: no iram assigned, using external mem

[ 0.419390] imx-sdma 20ec000.sdma: no event needs to be remapped

[ 0.421500] imx-sdma 20ec000.sdma: loaded firmware 3.3

[ 0.426053] imx-sdma 20ec000.sdma: initialized

[ 0.429649] pfuze100-regulator 1-0008: Full layer: 2, Metal layer: 1

[ 0.432143] pfuze100-regulator 1-0008: FAB: 0, FIN: 0

[ 0.434040] pfuze100-regulator 1-0008: pfuze100 found.

[ 0.862579] console [hvc0] enabled

[ 0.866725] 2020000.serial: ttymxc0 at MMIO 0x2020000 (irq = 24, base_baud =
5000000) is a IMX

Dmesg:

[ 0.441205] SW3B: at 1500 mV

[ 0.441995] SW4: at 1000 mV

[ 0.442826] SWBST: 5000 <–> 5150 mV at 5000 mV

[ 0.444119] VSNVS: 1000 <–> 3000 mV at 3000 mV

[ 0.444299] VREFDDR: override min_uV, 1 → 750000

[ 0.444309] VREFDDR: override max_uV, 2147483647 → 750000

[ 0.444931] VREFDDR: 750 mV

[ 0.445744] VGEN1: at 1500 mV

[ 0.446547] VGEN2: 800 <–> 1550 mV at 1500 mV

[ 0.447348] VGEN3: at 3300 mV

[ 0.448161] VGEN4: 1800 <–> 3300 mV at 1800 mV

[ 0.448974] VGEN5: 1800 <–> 3300 mV at 2500 mV

[ 0.449794] VGEN6: 1800 <–> 3300 mV at 2800 mV

[ 0.449922] initcall pfuze_driver_init+0x0/0x20 returned 0 after 21151 usecs

[ 0.449949] calling rn5t618_regulator_driver_init+0x0/0x20 @ 1

[ 0.450091] initcall rn5t618_regulator_driver_init+0x0/0x20 returned 0 after 121 usecs

[ 0.450111] calling pty_init+0x0/0x254 @ 1

[ 0.450321] initcall pty_init+0x0/0x254 returned 0 after 187 usecs

[ 0.450344] calling hvc_dcc_init+0x0/0x6c @ 1

[ 0.862579] console [hvc0] enabled

[ 0.866148] initcall hvc_dcc_init+0x0/0x6c returned 0 after 406033 usecs

[ 0.866191] calling imx_serial_init+0x0/0x48 @ 1

[ 0.866725] 2020000.serial: ttymxc0 at MMIO 0x2020000 (irq = 24, base_baud = 5000000) is a IMX

[ 0.875587] 21e8000.serial: ttymxc1 at MMIO 0x21e8000 (irq = 295, base_baud = 5000000) is a IMX

EDIT: I tried to get more info for this by taking the console from u-boot environment. For some reason the Angstrom console popped up, even though it now shouldn’t be configured anywhere. Well it still doesn’t work because it appears that the linux kernel deadlocks. I would venture out to guess that the same issue was on the original question? Right now my question is: Should I give up on this matter? Judging on the deadlock, could I say that JTAG console is not supported at all?

2

What exactly is it that you are trying to achieve? May it be that you are trying to debug something which isn’t actually broken?

3

Dear @marcel.tx,

My intention is to use linux serial console over JTAG. Currently our board has an UART for that but eventually we must have all of them for other use, so it will not be useable in the future.

Sorry if my question was unclear. I’ll add this text so it will be clearer.

4

My intention is to use linux serial console over JTAG.

Yes, that much I gathered.

But what exactly is it that you are trying to achieve? What exactly is your application? Are all your UARTs so important that it is impossible to ever use one as a console should one ever need any such? Or are you planning to ship a Lauterbach with every unit? Not to speak of the weeks of training required to make use of it. How many units are we talking about anyway? It’s just that I don’t know of any single customer having gone down this path. I could also think of dozens of easier ways to achieve what you seem to be trying but maybe you have some super special requirements which do actually mandate doing it this way.

Currently our board has an UART for that but eventually we must have all of them for other use, so it will not be useable in the future.

All of them meaning how many and you truly need them all at all times even when you might want to use a console which most regular products do not actually ever need.

Sorry if my question was unclear. I’ll add this text so it will be clearer.

No, it’s just that I am trying to understand the big picture.

5

Dear @marcel.tx

But what exactly is it that you are trying to achieve?

I’m trying to get linux console access when developing/debugging our board. The console would only be used by our R&D if needed for accessing linux/Angstrom or for running commands over Lauterbach. Lauterbach itself will be used for more purposes than just for the console, but this would be one of the features that would benefit development.

What exactly is your application?

My application is an automation controller.

Are all your UARTs so important that it is impossible to ever use one as a console should one ever need any such?

Yes, and moreover, it’s undesirable for anyone else than our R&D to access the console. I think it would be possible to use one UART port when debugging but then it would require our application to take into account that one of those ports is not usable. Console over JTAG would be convenient because it would fit to both these things.

Or are you planning to ship a Lauterbach with every unit?

The end-user will not be accessing the console. Only those involved developing might get one or then share one with others. Even then, getting an SSH-session would likely cover most cases.

I could also think of dozens of easier ways to achieve what you seem to be trying but maybe you have some super special requirements which do actually mandate doing it this way.

I’m open to suggestions. I might make this look like that this is the only path I ever want to take, but it’s not. For the moment, this has been deemed to be the most convenient one that does not require hardware or application changes but could be managed in our image only.

Sincerely
esalaak

6

Hi

Usually JTAG is used for debugging and should not used as UART.

For other solutions, is SSH connection sufficient for you for debugging?

Regarding UART, did you think also about using USB/UART converter for your application?

Best regards,
Jaski

7

Dear @jaski.tx

For other solutions, is SSH connection sufficient for you for debugging?

For most situatuions, yes but I would like to have the possibility to access serial console for bootloader and early-printk.

Regarding UART, did you think also about using USB/UART converter for your application?

Actually, no I didn’t. It sounds like a simple solution for my case :smiley: The only problem I can think of is that our only accessible USB port is the USB-OTG port. I’ve changed it in device-tree but I haven’t done anything on bootloader. I must test and google this, but do you know of any guide on how to change it?

Sincerely
Esalaak

8

Hi @esalaak

Sorry for the delayed answer.

I tested this on my side and it works pretty well with one exception.

So I used a viola board with a iMX7 (you could any module) and connected to UART B. So this will be my debugging machine. On other side, I connected a USB to UART to the OTG Port of iMX6, which is the target to be debugged.

On target module side, you change the console to ttyUSBx and then reboot. Then you can SSH to your debugging machine and start a screen or minicom session to see all the debug messages and also do debugging.

The only thing is you don’t see any U-boot messages. For this, you have to recompile/reconfigure U-Boot.

A different approach would be to use the serial console over OTG Gadget device port.

I hope these answers help you.

Best regards,
Jaski

9

Hi @jaski.tx

As per your suggestion, I did the same and it seems to work. I can use console with USB-RS232 converters. This is a good solution for my original problem, so that I do not have to use any of the original ports on the board.

Thank you
BR,
esalaak

10

Perfect that it works. Thanks for your feedback.