K3 using serial port problem

[geekmaster]

Could it be a software-handshake (ctrl-s, ctrl-q) problem with the terminal program? Could it be a buffer full problem?

Try different handshake settings. Try a different serial comm program. Perhaps that program is sending a crtl-s (XOFF) to the kindle at that point (after a certain number of characters have been received), making the kindle output "pause"... Try typing a crtl-q (XON) at that point to see if it continues.

[knc1]

Originally Posted by geekmaster

Could it be a software-handshake (ctrl-s, ctrl-q) problem with the terminal program? Could it be a buffer full problem?

Try different handshake settings. Try a different serial comm program. Perhaps that program is sending a crtl-s (XOFF) to the kindle at that point (after a certain number of characters have been received), making the kindle output "pause"... Try typing a crtl-q (XON) at that point to see if it continues.

Sorry, did not think of software flow control problems -
Add the checks GM suggests into the steps of my post above at the appropriate points.

You might also mention what serial comm program and host OS your using.

[geekmaster]

Originally Posted by knc1

Sorry, did not think of software flow control problems - ...

I did not think of them until now either. It is hard to think of everything at once. It is a lot easier to think of ANOTHER THING when all the other things you tried have failed. Incremental evolution of ideas...

Originally Posted by knc1

... You might also mention what serial comm program and host OS your using.

Post #18 shows that he is using minicom, the same program that seaniko7 used in the video.

[knc1]

This one looks interesting:

bootcmd_root_mmc=setenv bootargs $(bootargs_base) root=/dev/mmcblk1p1 rw ip=none
bootcmd_root_mvn=setenv bootargs $(bootargs_base) root=/dev/mmcblk0p1 rw ip=none

If that is not just a "left over" from lab126 development environment, the K3 has a second eMMC block and another root file system (plus maybe another kernel?).

As can be seen in the eMMC documentation, the part has the ability to hardware host two boot partitions (three if you count the user area of the flash).
Ref: http://drpbox.knetconnect.com/k3/KLMxGxxEHx.pdf
Page 9.


Once we get the immediate problem solved, BB can try that out for us.

[geekmaster]

Originally Posted by knc1

This one looks interesting:

If that is not just a "left over" from lab126 development environment, the K3 has a second eMMC block and another root file system (plus maybe another kernel?).

As can be seen in the eMMC documentation, the part has the ability to hardware host two boot partitions.
Ref: http://drpbox.knetconnect.com/k3/KLMxGxxEHx.pdf

mmcblk1 is an external mmc device (SD card) that they have in their development system, according to comments in the source code. Those pins may be buried under the SoC chip in the production devices though. It would be nice to find them and add an SD socket.

[BusterBrown]

Hi guys, I was just kidding about the language translation. I have the clip downloaded from youtube so, I can see what should be displayed on my screen. Please look at my post #11. As I said before, I am working with a good unit that boots correctly with my serial adaptor connected. My next step is going to be monitoring the data flow with my scope and see if it ends at the same time I stop getting text on the computer screen. I am beginning to think something is wrong with my minicom setup but, the scope will confirm this.

[knc1]

Originally Posted by BusterBrown

Hi guys, I was just kidding about the language translation. I have the clip downloaded from youtube so, I can see what should be displayed on my screen. Please look at my post #11. As I said before, I am working with a good unit that boots correctly with my serial adaptor connected. My next step is going to be monitoring the data flow with my scope and see if it ends at the same time I stop getting text on the computer screen. I am beginning to think something is wrong with my minicom setup but, the scope will confirm this.

Disable flow control in minicom.
U-boot may not recognize flow control but /dev/console does and your only getting as far as the kernel initialization of /dev/console if the messages are to be beleived.

Also - this adapter __must__ be 1.8v __not__ 3.3v
It is not known that the Kindle SoC is 3.3v tolerant.

[BusterBrown]

This is how Minicom is setup:
+-----------------------------------------------------------------------+
| A - Serial Device : /dev/ttyUSB2 |
| B - Lockfile Location : /var/lock |
| C - Callin Program : |
| D - Callout Program : |
| E - Bps/Par/Bits : 115200 8N1 |
| F - Hardware Flow Control : No |
| G - Software Flow Control : No |
| |
| Change which setting? |
+-----------------------------------------------------------------------+
| Screen and keyboard |
| Save setup as dfl |
| Save setup as.. |
| Exit |
| Exit from Minicom |
+--------------------------+
I am using Linux Mint 12 and have the Sparkfun level converter, Max 232, U232-P9 USB to serial and getting 1.8 volt supply from the Kindle serial port.

[knc1]

Originally Posted by BusterBrown

I am using Linux Mint 12 and have the Sparkfun level converter, Max 232, U232-P9 USB to serial and getting 1.8 volt supply from the Kindle serial port.

That is a CMOS input signal that controls the lamp power to the upper connector. You can't pull enough power from its pull-up resistor to power your level converter.
I.E: Once the SoC gets re-configured by the kernel in its startup process, you are losing power to the level converter.

Re-option your level converter to be powered by the USB side.

The minicom options all look reasonable (both hardware and software flow control disabled).

[BusterBrown]

I just monitored the data from the Kindle with my scope and sure enough, No data after the Kernel boot as in post 11. I also checked the 1.8 volt supply for the K3 and it doesn't change very much. I could try using an external 1.8 volt suppy though. Looking at the video again it looks like there is a (b) in the 'program callout' portion of the port setup?? See attached picture. http://s618.photobucket.com/albums/tt266/wallyntoni/K3/

[geekmaster]

The K4 and K5 have a 1K series resistor on both Rx and Tx. The K3 may be the same. The kindle Tx cannot sink enough current to bring the SoC side of its 1K resistor down to a logic zero.

I used a series diode, to allow the kindle to pull Tx down to 0.7v (good logic zero), then on the serial adapter side a 20K pullup resistor to 3.3v (or 5v). Less than 20K pullup will not give a good logic zero.

That does not seem to be a problem here though because you seem to have good output.

The K4 and K5 do NOT get a good ground from the serial connector. It is better to get a ground from elsewhere, like the USB cable.

On a K3, I did not test this, but you might have a voltage level problem on the SoC side of the internal pullup resistor, if you are supplying too much current.

[BusterBrown]

Case solved...... I just used an external 1.8 volt supply and guess what IT WORKS..... this is really strange that I would get data from U-boot but, not the kernel. Guess you guys know what you are talking about. Thanks for all that replied to this thread.

[knc1]

Originally Posted by BusterBrown

Case solved...... I just used an external 1.8 volt supply and guess what IT WORKS..... this is really strange that I would get data from U-boot but, not the kernel. Guess you guys know what you are talking about. Thanks for all that replied to this thread.

Pins on an SoC, nearly all SoCs, nearly all pins, are programmable.

If the kernel was built with the early printK / early console option(s), then initializing the /dev/console driver would have been __almost__ the first thing it does after being uncompressed and the image starting execution.

Betting that the pin characteristics would be programmed by the kernel driver the same as either the SoC default or those programmed by U-boot is a poor bet.

So what you have learned just adds to our knowledge of the considerations in using this (un-documented for us) hardware.