K3 using serial port problem

[BusterBrown]

I have moved the good screen between units to be sure that I'm working with a proper working K3. I have tried versions 3.0.2 to 3.3 with the same results. I bricked one of the units after installing a custom kernel.

[knc1]

Originally Posted by BusterBrown

All of my testing is being done with good working units. I can hit return on my computer and stop the boot process and see the U-boot prompt.

And what information can you get u-boot to output for you at that point?
Depending on how it was built, it may have a built-in "help" function to tell you the available commands.

So far, it sounds like passing an incorrect kernel command line.
You should be able to display that setting(s) from the u-boot command line.

[BusterBrown]

Welcome to minicom 2.5

OPTIONS: I18n
Compiled on May 2 2011, 00:39:27.
Port /dev/ttyUSB2

Press CTRL-A Z for help on special keys



U-Boot 1.3.0-rc3-lab126 (Sep 15 2010 - 19:24:53)

CPU: Freescale i.MX35 at 532 MHz
Board: MX35 Luigi [ POR]
WDOG_WCR = 0xff31
WDOG_WMCR = 0x0
Board Id: SP1B000000000000
S/N: B006A0A0xxxxxx
DRAM: 256 MB
Using default environment

In: serial
Out: serial
Err: serial
No ethernet found.
i.MX35 CPU board version 2.0
Net: No ethernet found.
Hit any key to stop autoboot: 1
0
uboot> help
Unknown command 'elp' - try 'help'
uboot> help
? - alias for 'help'
autoscr - run script from memory
base - print or set address offset
bdinfo - print Board Info structure
boot - boot default, i.e., run 'bootcmd'
bootd - boot default, i.e., run 'bootcmd'
bootm - boot application image from memory
bootp - boot image via network using BootP/TFTP protocol
cmp - memory compare
coninfo - print console devices and information
cp - memory copy
crc32 - checksum calculation
dhcp - invoke DHCP client to obtain IP/boot params
echo - echo args to console
go - start application at address 'addr'
help - print online help
iminfo - print header information for application image
itest - return true/false on integer compare
loadb - load binary file over serial line (kermit mode)
loads - load S-Record file over serial line
loady - load binary file over serial line (ymodem mode)
loop - infinite loop on address range
md - memory display
mii - MII utility commands
mm - memory modify (auto-incrementing)
mtest - simple RAM test
mw - memory write (fill)
nfs - boot image via network using NFS protocol
nm - memory modify (constant address)
ping - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
rarpboot- boot image via network using RARP/TFTP protocol
reset - Perform RESET of the CPU
run - run commands in an environment variable
setenv - set environment variables
sleep - delay execution for some time
tftpboot- boot image via network using TFTP protocol
version - print monitor version
uboot>

[knc1]

Originally Posted by BusterBrown

Welcome to minicom 2.5

OPTIONS: I18n
Compiled on May 2 2011, 00:39:27.
Port /dev/ttyUSB2

Press CTRL-A Z for help on special keys



U-Boot 1.3.0-rc3-lab126 (Sep 15 2010 - 19:24:53)

CPU: Freescale i.MX35 at 532 MHz
Board: MX35 Luigi [ POR]
WDOG_WCR = 0xff31
WDOG_WMCR = 0x0
Board Id: SP1B000000000000
S/N: B006A0A0xxxxxx
DRAM: 256 MB
Using default environment

In: serial
Out: serial
Err: serial
No ethernet found.
i.MX35 CPU board version 2.0
Net: No ethernet found.
Hit any key to stop autoboot: 1
0
uboot> help
Unknown command 'elp' - try 'help'
uboot> help
? - alias for 'help'
autoscr - run script from memory
base - print or set address offset
bdinfo - print Board Info structure
boot - boot default, i.e., run 'bootcmd'
bootd - boot default, i.e., run 'bootcmd'
bootm - boot application image from memory
bootp - boot image via network using BootP/TFTP protocol
cmp - memory compare
coninfo - print console devices and information
cp - memory copy
crc32 - checksum calculation
dhcp - invoke DHCP client to obtain IP/boot params
echo - echo args to console
go - start application at address 'addr'
help - print online help
iminfo - print header information for application image
itest - return true/false on integer compare
loadb - load binary file over serial line (kermit mode)
loads - load S-Record file over serial line
loady - load binary file over serial line (ymodem mode)
loop - infinite loop on address range
md - memory display
mii - MII utility commands
mm - memory modify (auto-incrementing)
mtest - simple RAM test
mw - memory write (fill)
nfs - boot image via network using NFS protocol
nm - memory modify (constant address)
ping - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
rarpboot- boot image via network using RARP/TFTP protocol
reset - Perform RESET of the CPU
run - run commands in an environment variable
setenv - set environment variables
sleep - delay execution for some time
tftpboot- boot image via network using TFTP protocol
version - print monitor version
uboot>

The printenv/setenv commands will allow you to see (change) the kernel command line being passed.
Start off by just displaying it - don't be tempted to change anything.
Also note that u-boot can "chain" multiple environment entries.

[BusterBrown]

This is what I got with the 'printenv command' R we making progress?
uboot> printenv
bootdelay=1
baudrate=115200
loadaddr=0x80800000
uboot_net=tftpboot 0x84000000 u-boot.bin
uboot_serial=loady 0x84000000
uboot_ram=go 0x84000000
bootargs_diag=setenv bootargs tests=all
diags_net=tftpboot 0x84000000 diagmon.uimage; run bootargs_diag; bootm 0x8400000
diags_serial=loady 0x84000000; run bootargs_diag; bootm 0x84000000
bootargs_base=console=ttymxc0,115200 mem=256M panic=10
bootcmd_root_nfs=setenv bootargs $(bootargs_base) root=/dev/nfs rw nfsroot=$(nf3
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
bootcmd_kernel_nfs=nfs 0x87f40400 $(nfsrootfs)/uImage; bootm
bootcmd_kernel_tftp=tftp 0x87f40400 uImage; bootm
bootcmd_nfs=run bootcmd_root_nfs; run bootcmd_kernel_nfs
bootcmd_flash=run bootcmd_root_mvn; run bootcmd_kernel_nor
bootcmd_card=run bootcmd_root_mmc; run bootcmd_kernel_nor
bootcmd_recovery=run bootcmd_root_recovery; run bootcmd_kernel_nor
bootcmd_defaultflash=setenv bootargs; run bootcmd_kernel_nor
bootcmd=bootm 0x87f40400
testmem=mtest 0x80000000 0x86ffffff
nfsrootfs=/nfsboot
ethaddr=00:22:33:44:55:66
cfgreset=protect off all ; erase (0xA0000000 + (128 * 1024)) +(128 * 1024)
bootretry=-1
stdin=serial
stdout=serial
stderr=serial

Environment size: 1362/131068 bytes
uboot>

[BusterBrown]

Wonder about this line in Printenv: bootargs_base=console=ttymxc0,115200 mem=256M panic=10

[knc1]

Originally Posted by BusterBrown

Wonder about this line in Printenv: bootargs_base=console=ttymxc0,115200 mem=256M panic=10

That one is the kernel command line.

Not sure what the "panic=10" kernel command line option is, would have to look that one up in the kernel_source/Documentation tree.
Everything else on that line looks "as expected" (and the kernel is being told to run /dev/console on the same hardware you are now using, at the same speed).

Note: The options on that line which are __not__ consumed by the kernel, are passed onto the next stage of initialization (often to the initramfs or init or whatever is next).
So if you don't find that "panic= " option in the kernel documentation, then it is something for later in the process.

If it helps to read those strings ...
u-boot runs a small version of Busybox ash.
Which is why some look like shell scripting - they are.

[knc1]

Originally Posted by BusterBrown

This is what I got with the 'printenv command' R we making progress?
uboot> printenv
bootdelay=1
baudrate=115200
loadaddr=0x80800000
uboot_net=tftpboot 0x84000000 u-boot.bin
uboot_serial=loady 0x84000000
uboot_ram=go 0x84000000
bootargs_diag=setenv bootargs tests=all
diags_net=tftpboot 0x84000000 diagmon.uimage; run bootargs_diag; bootm 0x8400000
diags_serial=loady 0x84000000; run bootargs_diag; bootm 0x84000000
bootargs_base=console=ttymxc0,115200 mem=256M panic=10
bootcmd_root_nfs=setenv bootargs $(bootargs_base) root=/dev/nfs rw nfsroot=$(nf3
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
bootcmd_kernel_nfs=nfs 0x87f40400 $(nfsrootfs)/uImage; bootm
bootcmd_kernel_tftp=tftp 0x87f40400 uImage; bootm
bootcmd_nfs=run bootcmd_root_nfs; run bootcmd_kernel_nfs
bootcmd_flash=run bootcmd_root_mvn; run bootcmd_kernel_nor
bootcmd_card=run bootcmd_root_mmc; run bootcmd_kernel_nor
bootcmd_recovery=run bootcmd_root_recovery; run bootcmd_kernel_nor
bootcmd_defaultflash=setenv bootargs; run bootcmd_kernel_nor
bootcmd=bootm 0x87f40400
testmem=mtest 0x80000000 0x86ffffff
nfsrootfs=/nfsboot
ethaddr=00:22:33:44:55:66
cfgreset=protect off all ; erase (0xA0000000 + (128 * 1024)) +(128 * 1024)
bootretry=-1
stdin=serial
stdout=serial
stderr=serial

Environment size: 1362/131068 bytes
uboot>

Looks like the K3 u-boot is pre-setup so that you can do all sorts of interesting things.

I don't know if this u-boot can init the wired (over USB) or wireless networking, but even if it can't you could still transfer and run a memory resident "rescue kernel" as an s-record image.
Might not be the fastest way to load a kernel and filesystem image, but if nothing else can be done...

[BusterBrown]

Does look interesting but, all I want to do right now is get the LOG-IN screen.... It has taken a lot of work just to get the serial interface hardware to communicate with the Kindle and now, I can't seem to do much with it. I know it's a big learning process of finding little pieces of info here and there on how to do things.

[knc1]

Originally Posted by BusterBrown

Does look interesting but, all I want to do right now is get the LOG-IN screen.... It has taken a lot of work just to get the serial interface hardware to communicate with the Kindle and now, I can't seem to do much with it. I know it's a big learning process of finding little pieces of info here and there on how to do things.

Well, all that takes is for you to successfully start the kernel.
But wait,
Wasn't that the question we are working on?

We can now answer the theory posted here that the kernel is switching away from the serial port and/or changing the line speed. It isn't.

You posted that this is a "good" K3 - Meaning?
Does "good" mean that if you unplugged your serial connector and re-booted it, it would come up and run normally?

[BusterBrown]

Yes, I'm working on a virgin K3G. No jail breaks etc. It boots up and works fine .

[knc1]

Originally Posted by BusterBrown

Yes, I'm working on a virgin K3G. No jail breaks etc. It boots up and works fine .

How "virgin"? Did you fully charge the battery before starting this?

Even if you did, remove your serial connector (which might also be making contact with the lamp control lead);
Re-boot it (it has to be running to be certain the battery management is doing its correct thing);
Put it on a wall charger until the battery is fully charged.

Take two asprins and call me in the morning.

Then we can continue.

[hawhill]

Edit/note: this is directed at BusterBrown

Why don't you check from within the running system then, e.g. using Jailbreak plus USBnetworking?

Ought to be much easier than sitting before a serial console and asking why it wouldn't answer.

But I must admit that I seriously misunderstood the intention of your post. I thought you were on the way to revive a bricked Kindle. Now, I'm not sure what you're up to, but if I got it together in the right way, you just want a working serial console on your Kindle. Well, when the system starts fine, why not look from inside that system?

[BusterBrown]

Knci, Fresh battery (green light with charger cable plugged in) Serial connection is soldered to top of serial connector. I reset by removing the battery each time I watch the boot process on the terminal.

hawhill, I just want to snoop around in the K3G file system before trying to repair the bricked unit. I have used USBnet and know there are other ways to get inside the Kindle. I just can't figure out why I can't see anything on my console after Uncompressing Linux ............. If only I understood what "ustawienia portu szeregowego" in Seanik07's video was all about....

[knc1]

Originally Posted by BusterBrown

Knci, Fresh battery (green light with charger cable plugged in) Serial connection is soldered to top of serial connector. I reset by removing the battery each time I watch the boot process on the terminal.

hawhill, I just want to snoop around in the K3G file system before trying to repair the bricked unit. I have used USBnet and know there are other ways to get inside the Kindle. I just can't figure out why I can't see anything on my console after Uncompressing Linux ............. If only I understood what "ustawienia portu szeregowego" in Seanik07's video was all about....

Google translate did not answer that for you?
"Serial port settings"
We are way past that point.

- - - -

What we do have is a set of circumstances that does not compute (no pun intended).

IFF:
The machine would boot to normal operation before surgery;
The machine would boot to normal operation after surgery __with serial port connection__
The serial port connection communicates normally with u-boot.
THEN:
The messages you see would not stop at the point they are reported to stop.
But the messages do stop at that point. TILT

So there is something wrong with the conditions as reported.

Here is how to narrow down where / what has happened:

"serial cable soldered to top of serial port connector" -
If that is litterally what you did - remove the two screws holding the top of the serial port connector on - remove serial port with cable still soldered on.
ELSE
Cut the three (there should only be three) wires you soldered to the top of the serial port connector at a place where it will later be convenient to splice them back together (I.E: Leave soldering iron cold).

Now confirm assumption #2
Ensure the machine will still re-boot to normal operation with the serial port connection you have made not connected.

If it fails to re-boot to normal operation (removing the top of the serial port connector will not affect this) -
Then what you saw and reported as the last message, is really the last message.

If it successfully re-boots to normal operation -
Then it is the serial adapter cable (or its attachment to top of connector) that is making the difference.

Things to check for:
Is the serial adapter cable in use one configured for 1.8v serial operation?
If it is a home built adapter cable, please discribe.
If it is a commercial product, name, model and if possible a link to the device description.

There are only three wires connected, Tx, Rx and Gnd.
Adapter cable is powered from the host computer, not from the Kindle. There are K3 serial port connection descriptions "on net" that show a 1.8v connection point but that is wrong - that is a floating CMOS input that can not source more than a few microamps of current.

Very, very carefully inspect the soldered connections for any problems.

re-splice the cut leads (if you had to cut them)

re-connect the cable to the K3, do not connect it to the host computer.
Confirm (again) that the K3 will re-boot to normal operation.

If it does, then (with the K3 powered off) connect the cable to the host computer;
Bring up your terminal emulator;
Configure for the adapter cable;
Power on the K3;
You should see it re-boot to normal operation and also see all of the boot messages on the terminal emulator.

There just isn't that many things that might be wrong after having done the above proceedure to diagnose the source of the reported problem.