my first chance to play with my recently-arrived BB XM and, as i
recall, the new DB9 serial port means i should be able to plug my
USB/serial converter directly into the board, so i do that, fire up
minicom, set parameters to /dev/ttyUSB0, 115200, 8N1, no flow control
(as i've always done with my C3 board), and ... garbage. as in,
unprintable characters -- you know, the weird square boxes with two
tiny digits, one above the other. pressing RESET simply repeats the
same short stream of garbage. this is what i used to get with my C3
when, for instance, i had the flow control set incorrectly. so are
the above parameters correct for minicom?
also, weirdly, if i unplug the USB/serial converter, then plug it
back in, what i see in /var/log/messages is:
Alas, this is a common problem for most Linux distributions. For
example, Ubuntu 9.10 launches a "modem-manager" every time feels that a
serial port has been attached. I had to "kill -9" the process and rename
(ouch!!) the /usr/sbin/modem-manager executable (which gave me a lots of
"+GCAP" on the uBoot command-line). I guess your gpsd thing is son of
the same problem: excessively "user-friendly" Linux distributions assume
that the user is definitely not a programmer wanting to fiddle out with
serial ports because serials are either modems or gps units. Disabling
gpsd service at startup could help. On command-line, try "sudo service
gpsd stop" before booting the board (or have a look in the /etc/rc*.d
and /etc/init.d and /etc/default directories).
the gpsd service *is* stopped, so i'm about to look into udev and
deactivate it there since i suspect that's what's causing the trouble.
if nothing else works, i'll simply remove the entire package. but
could that be what's causing the trouble? if gpsd isn't running, is
there any way it could be affecting my talking to the BB XM's serial
port?
so i removed the gpsd package entirely, and that got rid of the
annoying /var/log/messages entries generated by the gpsd udev entry.
but it hasn't solved my serial port communication with the BB XM --
still unprintable garbage every time i reset. still open to
suggestions.
i just connected my C3 BB (adding, of course, the null modem cable
and the IDC cable), and it works fine, proving at least that the
USB/serial converter works. but if i switch back to the XM (using
only the USB/serial converter cable), same problem -- total gibberish.
i'm wondering if the board itself is somehow bad. any other ideas?
Please let me know when you get this solved. I have been living with this feature for weeks now. I am told it has something to do with power management, but I have my doubts. The serial port seems to work fine for me in Uboot, so the HW is fine, and until it boots the the kernel and asks for a password. after that, garbage city.
If I go back to an earlier kernel, there is no issue. And as I said, under UBoot it works fine. The only difference between the -xM and the C3/C4, is the changing of the header to a DB9 connector.
"Robert P. J. Day" <rpjday@crashcourse.ca> writes:
>
>> > Apr 17 17:26:15 localhost gpsd.hotplug: can't reach gpsd
>>
>> Alas, this is a common problem for most Linux distributions. For
>> example, Ubuntu 9.10 launches a "modem-manager" every time feels
>> that a serial port has been attached. I had to "kill -9" the process
>> and rename (ouch!!) the /usr/sbin/modem-manager executable (which
>> gave me a lots of "+GCAP" on the uBoot command-line). I guess your
>> gpsd thing is son of the same problem: excessively "user-friendly"
>> Linux distributions assume that the user is definitely not a
>> programmer wanting to fiddle out with serial ports because serials
>> are either modems or gps units. Disabling gpsd service at startup
>> could help. On command-line, try "sudo service gpsd stop" before
>> booting the board (or have a look in the /etc/rc*.d and /etc/init.d
>> and /etc/default directories).
>
> so i removed the gpsd package entirely, and that got rid of the
> annoying /var/log/messages entries generated by the gpsd udev entry.
> but it hasn't solved my serial port communication with the BB XM --
> still unprintable garbage every time i reset. still open to
> suggestions.
I have no pretend-magic packages installed, and everything is working
perfectly with the normal rs232 settings in minicom.
Please let me know when you get this solved. I have been living with this
feature for weeks now. I am told it has something to do with power
management, but I have my doubts. The serial port seems to work fine for me
in Uboot, so the HW is fine, and until it boots the the kernel and asks for
a password. after that, garbage city.
Now that you mention it, I have weird issues with the login prompt.
It behaves a bit erratically at first, then goes back to normal. No
idea what causes it.
it won't work for me, even to get to uboot. it's garbage right from
the beginning. i attached a screenshot of the very opening of the
minicom session, and what is printed after pressing the RESET button.
Exactly. I have found that if I enter the password immediately when prompted, it seems to work. Koen mentioned it had to do with the serial port going to power down and missing the first character before it woke up. What I have found is that if it gets garbage once, it never seems to clear up.
The 60 is the correct value to be sent out. The other characters are none ASCII characters, basically the serial port sending data to see if the serial boot loader SW is active on the port. This is the same operation as the previous version of the processor.
Exactly. I have found that if I enter the password immediately when prompted, it seems to work. Koen mentioned it had to do with the serial port going to power down and missing the first character before it woke up. What I have found is that if it gets garbage once, it never seems to clear up.
The 2.6.32-r70 uImage on http://www.angstrom-distribution.org/demo/beagleboard/ doesn't have cpuidle enable anymore. I had hoped that having it enabled and having people complain about it would make the kernel team fix it, but alas....
i just ran thru the simple tests i did last night, and nothing's
changed. to sum up, here's what works:
* minicom (115200, 8N1, no flow control), USB/serial converter to
null modem cable to IDC cable to C3 BB -- pressing RESET drops me
into u-boot.
if i swap out the C3 for the XM, and just use a straight USB/serial
converter cable, i get unprintable garbage whenever i RESET the XM.
minicom settings are not changed.
i'm open to suggestions or any other tests i can try.
ok, i think i may have just trashed my XM. just to be methodical, i
wanted to test connecting to it using a USB/serial cable, in addition
to a null modem cable and a male/male gender changer, even though i
realize a null modem cable shouldn't be used anymore but i figured,
what the heck.
i was pushing the cable into the XM's DB9 connector and the XM's DB9
connector simply bent backwards. it's holding on and still attached,
but barely -- i have no idea if any of the traces are now broken. i
suppose i could have been gentler, but i wasn't treating it roughly,
just plugging in a cable. if it's really that delicate, i suspect
others will eventually run into the same problem. sadly, it looks
like i don't have an XM to play with anymore. *sniff*.
I suggest to change conventional uart/rs232 to usb-serial ic. I always have ftdi ic on my Development board so my customers never have a headache about where to have rs232 port on a PC. The price difference is not noticable…
I suggest to change conventional uart/rs232 to usb-serial ic. I always have
ftdi ic on my Development board so my customers never have a headache about
where to have rs232 port on a PC. The price difference is not noticable..
There is one thing I don't like about such setups. Because the serial
port as seen by the PC doesn't exist until the device is powered on,
it becomes tricky to interact with the board quickly after reset.
