View Single Post
Old 03-05-2012, 08:20 AM   #2
knc1
Embedded Cheerleader
knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.
 
knc1's Avatar
 
Posts: 6,457
Karma: 5840130
Join Date: Feb 2012
Device: Too many.
Quote:
Originally Posted by Frenko View Post
If I press enter it returns
Code:
Welcome to Kindle!

kindle login:
immediately followed by the ever looping error
Just close your eyes and keep on typing whatever is expected for the login response.
It is a full duplex serial line, it is listening to your key strokes even while outputting other messages.

Then, once you log in, we just need to find and stop what is sending the error messages. Not to fix the overall problem, but just so the serial line can be used without a bunch of distracting chatter from something failing.

Hints:
Turn on the 'capture' feature of your terminal and save the capture file. It may be neccessary to use a text editor on the capture file to sort out the input/output from the error message chatter.

If your terminal has a provision to define 'keystroke macros' (strings sent in response to a specific key combination), it may be neccessary to use that for the various things to be sent to the kindle (like the login strings).

And/Or - check if your terminal has a 'hand off' feature (many do) it may be neccessary to use that to turn the serial line over to an 'expect' or 'chat' script.

Some terminal emulators have such a 'chat' feature included, left over from dealing with modems and dial-up connections. It may be neccessary to use that to get past the chatter.

Eventually we will get to the point where we can get a process list of what is running (using either 'ps aux' or 'top -bn1') -
It is one of those things which:
Is a script;
Is calling 'cat';
Does not have stderr redirected;
And not checking the error return from the 'cat' command.
(And from the content of the message, wants to know if the charger is connected and the state of the battery charge but is doing it Before the software charger controls are loaded. I.E: a start-up script without the proper dependences set.)

Notes:
Linux (any *nix) starts up with only an "operator's console line" (/dev/console) to communicate with the outside world. Everything else is add-ons by other programs.
Something (which shouldn't be by design) is still talking to /dev/console.

Linux (any *nix) is a single, stand-alone, program that only runs one other program when it is ready to run anything at all.

The usual default is a special program that starts, controls and stops multiple other programs but it does not have to be. A common debugging setting is to set either: 'init=/bin/sh' or 'rdinit=/bin/sh' on the kernel command line.

That leaves the system as just you, the kernel, and the command shell talking on /dev/console. No chance for anything else to start up (and fail) while locating the source of the original problem.

Changing the kernel command line arguments in an embedded system is done from the boot loader (here: u-boot) with commands to 'setenv', 'getenv', etc.

Translation: This is good progress, just a bit messy with all of the chatter going on.

O.P. first complains his machine will not talk to him. Now complains that it says too much. What will make him happy?

Last edited by knc1; 03-05-2012 at 08:43 AM.
knc1 is offline   Reply With Quote