2009-03-10 06:23:53     weird console problem

2009-03-10 06:23:53     weird console problem

Thorsten Pohlmann (GERMANY)

Message: 70684   

Hi!

I experience the following problem: (On a BF537 Stamp and on a custom BF537 Board)

I set the console to a serial port (BF0/1 makes no difference), booting, shell everything works fine. If there is a Terminal connected via the serial line. If i boot without a connected cable, the console never works again when i replug it and the system behaves strangely (which i can't investigate further, without any console...)

It's the same behaviour with the very old stamp (Linux version 2.6.12.1-BFIN-2005R3 (root@sevens) (gcc version 3.4.4) #1 Fri Sep 30 10:59:31 CST 2005)

and our own board (Linux version 2.6.22.19-ADI-2008R1.5-svn (root@Z-TP-30Suse102) (gcc version 4.1.2) #100 Tue Mar 10 09:38:37 CET 2009)

I tried the kernel's serial drivers with/without rts/cts support, dma/pio mode, it makes no difference.

As  i can see with an attached tester, the output completes to the busybox-shell. My autostart program seems to hang at the point it does an fgets to the console.

Any hints?

TranslateQuoteReplyEditDelete

2009-03-10 06:28:19     Re: weird console problem

Mike Frysinger (UNITED STATES)

Message: 70685   

that does seem odd considering the hardware and software does not care at all whether a cable is connected.  it will still wiggle the pins exactly the same as before.

you arent running custom userspace code that mucks with the terminal are you ?  what about modifications to the Blackfin UART driver ?

otherwise, are you sure your host PC isnt the one screwing things up ?

i do this kind of thing all the time (booting a board w/out a cable attached and connecting it after wards) and it works without a problem ...

QuoteReplyEditDelete

2009-03-10 06:40:09     Re: weird console problem

Thorsten Pohlmann (GERMANY)

Message: 70687   

Hi!

I think the BF-Stamp is right out of the box as I got it a few years ago. There are no appl. running but the busybox-shell on both boards. On the custom board it's the 2008R1.5-svn release, with no patches but the board-initialization (which does not touch the serial-ports)

I dont' think the PC is the problem, because I am too doing this all the day with different (PowerPC-)boards running Linux, no problem there. That would also not explain my stalling application on the BF.

Meanwhile i measured the uarts during boot with a logicanalyser, no difference there between with/without cable. Could this be some strange fallback to x-on/off or something?

TranslateQuoteReplyEditDelete

2009-03-10 06:50:42     Re: weird console problem

Mike Frysinger (UNITED STATES)

Message: 70688   

software flow control isnt enabled by default i dont believe

hardware flow control might act oddly, but you said you arent using that right ?  and the switch settings on the BF537-STAMP has those shorted anyways ?

can you telnet into the board and see if there's anything odd in like the kernel log buffer (dmesg) ?

QuoteReplyEditDelete

2009-03-10 07:00:29     Re: weird console problem

Michael Hennerich (GERMANY)

Message: 70689    I've never seen or heard something similar.

Check your cable and board power supply.

On the STAMP boards we use a straight through DB9 male/female cable.

Crossover is done on the STAMP board.

It might be that your power supply is bad. And as soon as you connect

the board with the shielding of your PC your board gets a better

ground???

-Michael

QuoteReplyEditDelete

2009-03-10 10:44:31     Re: weird console problem

Thorsten Pohlmann (GERMANY)

Message: 70704   

So, i did some further investigations:

My mistake was that my proprietary bootloader messed up the gpio-polarity for both cts.

But there still is a problem: The cts from uart0 seems to be used for both uarts, means if uart1 is the console and there is no terminal with cts on uart0, uart1 blocks. If i then open a terminal on uart0, the missing output and my inputs come out of uart1 as suggested. If uart0 is the console, cts works as expected and uart1's cts doesnt care.

Exchanging  the hardware-flow-control pins in kernel-config does not change anything, it seems as if they are hardwired somewhere?! It also seems the whole BFIN_UART0_CTSRTS settings dont care... ; I double or tripple checked all CONFIG_UART?_???_PIN includes, they are correct, the only diff in bfin_5xx.c is the i-pipe #ifdef which is not configurated.

The console is set via kernel-cmdline "console=ttyBF1,115200", i boot the kernel via tftp, root-fs is nfs.

TranslateQuoteReplyEditDelete

2009-03-10 17:33:28     Re: weird console problem

Mike Frysinger (UNITED STATES)

Message: 70726   

i'm assuming you're using the 2008R1.5 release ?  i'm pretty sure this was fixed in trunk (and it should be in the branch) ...

QuoteReplyEditDelete

2009-03-11 07:07:42     Re: weird console problem

Thorsten Pohlmann (GERMANY)

Message: 70762   

Hi!

Thanks for that hint, i tried the 2.6.28.7 from trunk and it works better (no more dependencies between uart0/1), but rts/cts on console ttyBF1 still seems to be ignored.

I now struggle to get the rest of my system back to work (mmc and xenomai)

regards,

TranslateQuoteReplyEditDelete

2009-03-11 07:12:06     Re: weird console problem

Mike Frysinger (UNITED STATES)

Message: 70764   

did you set your console= correctly ?

QuoteReplyEditDelete

2009-03-11 07:50:40     Re: weird console problem

Thorsten Pohlmann (GERMANY)

Message: 70768   

Hi!

This is the boot msg:

Linux version 2.6.28.7-ADI-2009R1-pre-svn6167 (root@Z-TP-30Suse102) (gcc version 4.1.2 (ADI svn)) #15 Wed Mar 11 11:52:32 CET 2009

Kernel command line: root=/dev/nfs nfsroot=192.168.6.34:/opt/ucLinux/uClinux-dist-2008R1.5-RC3/romfs rw console=ttyBF1,9600 ip=192.168.5.33:192.168.6.34:192.168.0.254:255.255.248.0:bf537-udaks:eth0:off

What puzzles me: cat /proc/gpio shows used gpios  (bfin-uart, gpio-irq75) for uart1 rts/cts, but no entries for the uart0 gpios.

If i inspect the PORTGIO_DIR register via the ice, the wrong pin (rts) is set as input, but the _POLAR and _INEN Bits are correct.

For uart0, the sysregs are correct.

regards,

TranslateQuoteReplyEditDelete

2009-03-11 07:54:04     Re: weird console problem

Mike Frysinger (UNITED STATES)

Message: 70769   

you should read the documentation.  look at linux-2.6.x/Documentation/kernel-parameters.txt (the console= section).  RTS is disabled by default for consoles ... you have to tell the kernel to enable it.

QuoteReplyEditDelete

2009-03-11 08:28:21     Re: weird console problem

Thorsten Pohlmann (GERMANY)

Message: 70771   

Hi!

Perhaps I was a bit unclear:

In PORTGIO_DIR rts1 is set as input(1) and cts1 is set as output(0), and in PORTGIO_INEN cts1 is correct as input(1).

For uart0 the rts0 and cts0 Bits in PORTGIO_DIR and _INEN are correct.

This is a error for me, since cts1 is a input at any time (i would suppose if i enable cts/rts for uart1 in kernelconfig)

> RTS is disabled by default for consoles

Then there is another problem, since rts/cts definitively works as suggested on ttyBF0 with these params. I went back to the BF537-STAMP_defaultconfig for all of these tests, so there should be no interference.

regards,

TranslateQuoteReplyEditDelete

2009-03-13 03:01:42     Re: weird console problem

Thorsten Pohlmann (GERMANY)

Message: 70924   

Hi!

I tried "ttyBF1,115200n8r" as console, still no rts/cts on uart1. IMHO something goes wrong with the gpio-initialization.

regards,