Torizon

Torizon is a new Linux-based software platform that simplifies the process of developing and maintaining embedded software. It allows you to configure the system for your use case quickly and easily, so you can focus on application development instead of Linux builds.

JTAG DCC/hvc console Colibri IMX6

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?

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?

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.

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.

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 :D 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

1 Answer

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.

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.