PE Hardware serial console

[toyz]

Originally Posted by nikkie

I suspect what we have is a link somewhere here on the forum labelled incorrectly. I've checked all of mine, and the links all indicate that the versions I've downloaded are for the PE. Therefore, at least one of the links is wrong. What do you think? I'm thinking we should put out a PSA with a moratorium until we figure out what the bad download link is.

In another thread (aren't forums wonderfully messy?) I posted that I thought I had downloaded the EE firmware without knowing the difference initially between an EE and PE. From that thread, "I'm 98% sure I upgraded to e-update.golden.zip (EE) that emusan had tweaked to not do the TARGET != UPDATE check that DarkGrue had success with. Thus, attempting to install the EE firmware on my PE." I would say that file should be named in a way to scare people away.

Originally Posted by nikkie

The solution mentioned above by Envo doesn't seem to help for this situation.

Yes, for me either. I don't thing we have a prayer trying to get the EE (Edge) firmware to completely boot on PE (Pocket Edge). I've been reading a bit how u-boot works. If we only had the command "usbboot" I think we'd be quite close. We have "tftpboot" but I'm not sure what that means on this hardware. We have wifi, which I doubt u-boot has a driver stack for. We also have usb. I keep seeing u2o-eth which must be usb-to-ethernet. For tftp to work you'd need TCP/IP working, but can that be done over vanilla USB? I have an old usb-to-ethernet from 3com, but I can't believe u-boot would have a driver stack for that weird thing.

FYI, "printenv" shows some default IP stuff set. "u2o-eth" gets very few hits on google... This page is #1 now! The env variable "bootargs_nfs" shows ip=192.168.2.101:192.168.2.100::usb0:on" So... you must be able to do tftp over plain old USB. I wonder what the tftp server end looks like? The only tftp servers I know of talk to a real ethernet adapter.

[toyz]

Apparently I live in the dark ages. It looks like people do tftp over usb on embedded devices quite often.

http://osdir.com/ml/linux.distributi.../msg00023.html

http://comments.gmane.org/gmane.linu....embedded/2436

> How about the TFTP over USB? It's required feature for no ethernet devices

you'll have to be more specific if you want a real answer. U-Boot has
USB Ethernet gadget support already.

More reading....

Well, the other alternative is seeing if u-boot can see a USB flash as some kind of memory range. Then you could copy X bytes from USB flash to a memory address and boot it.

[toyz]

(sorry for all the posts, I'm about to call it a day on this)

At the u-boot prompt this is interesting:

run boot_recover

After the kernel boots, the Pocket Edge logo appears on the LCD. Nice, since it's just displayed "entourage Edge" backwards for a few weeks. But it doesn't get very far. But it does fire up adb for a short time. You have 10 seconds to press a key to drop to a prompt, but keyboard entry on the serial console isn't being heard. I tried passing bootargs of console=ttyS1,etc,etc.... but didn't seem to help. I'm thinking we can figure out a bootarg to to suspend it or drop to a shell, then we can adb the device to death.

Dump with lots removed, see full dump attached

Edge>> run boot_recover
Hostname : ESIedge
Filesystem : v1.0.0

Kernel release : Linux 2.6.29
Kernel version : #1 PREEMPT Wed Sep 29 13:04:47 EDT 2010

Mounting /proc : [SUCCESS]
Mounting /sys : [SUCCESS]
Mounting /dev : [SUCCESS]
Mounting /dev/pts : [SUCCESS]
Enabling hot-plug : [SUCCESS]
Populating /dev : [SUCCESS]
Mounting other filesystems : [SUCCESS]
Starting syslogd : Oct 9 22:03:11 ESIedge syslog.info syslogd started: BusyBox v1.9.1
[SUCCESS]
Starting telnetd : [SUCCESS]

System initialization complete.
Archive: /usr/esi/images.zip
inflating: /tmp/img-splash-flip.raw
inflating: /tmp/img-splash.raw
inflating: /tmp/migrate-1.raw
inflating: /tmp/migrate-2.raw
inflating: /tmp/migrate-3.raw
inflating: /tmp/migrate-4.raw
inflating: /tmp/migrate-flip-1.raw
inflating: /tmp/migrate-flip-2.raw
inflating: /tmp/migrate-flip-3.raw
inflating: /tmp/migrate-flip-4.raw

show splash screen...

starting adbd...
[ 8.438872] enabling adb

UBI device number 0, total 7864 LEBs (4058578944 bytes, 3.8 GiB), available 1 LEBs (516096 bytes, 504.0 KiB), LEB size 516096 bytes (504.0 KiB)
/etc/init.d/edge_start: No valid command specified for Maintenance Mode...
*** Press any key within 10 seconds to start shell...^J
starting pid 691, tty '': '/bin/umount'
umount: mdev busy - remounted read-only

starting pid 693, tty '': '/sbin/swapoff'

The system is going down NOW!

You can see a BUNCH of boot options with printenv. "run" just runs the env variable on the commandline. So you can run them directly. I experimented with different parts of various boot arguments from the different environment variables.

For people that are new to u-boot like me:

run boot_recover

Actually looks up the env variable $boot_recover and runs it so it runs:

nand read 0x01000000 0x01300000 0x01800000
setenv esiboot sf read 0x500000 0x400000 0x300000
setenv bootargs $(bootargs_maint)
setenv autoboot boot
bootz 0x500000

[vicinc]

any luck for a full recovery procedure over serial or other means?

[toyz]

Originally Posted by vicinc

any luck for a full recovery procedure over serial or other means?

vicinc, I'm 95% sure we will get one. I suspect there are several ways:
- serial to u-boot, tell u-boot to tftp the kernel etc over usb
- serial to u-boot, tell it to find a kernel or root/initrd on sdcard or usb flash (there is a boot option env variable to recover from sd)
- I read someone was sending their kernel over serial/u-boot with kermit, but on a very different device.

It's just a matter of time now in my opinion. Need some help. Once we understand stuff better and have easy recovery, we'll be able to experiment maybe with clockworkmod, homebrew kernels, android stuff... I'd like to get rid of crappy apps in the rom, get android market and friends happy, keep reader/journal capability.

[ptsenter]

Originally Posted by toyz

I keep seeing u2o-eth which must be usb-to-ethernet. For tftp to work you'd need TCP/IP working, but can that be done over vanilla USB? I have an old usb-to-ethernet from 3com, but I can't believe u-boot would have a driver stack for that weird thing.

Just in case you haven't seen this StarTech.com Compact Black USB 2.0 to 10/100 Mbps Ethernet Network Adapter (USB2106S) works on PE. If your 3Com is based on the same chipset it might work.

[nikkie]

@toyz, I noticed that after I did the run boot_recover, on that first reboot, pushing the menu/rotate buttons actually displayed output to the terminal indicating the buttons had been pressed. They don't while in the bad flashed firmware. After it does that first boot though, it goes back to the bad firmware, so it doesn't help us too much. I tried doing a flash during that first reboot while the "Pocket Edge" logo displayed, but it didn't take. So the button connections must be wired differently for the regular edge, which explains why those of us with the bad firmware are not able to reflash.

I agree that tftpboot over usb is probably the best option. I don't have the usb-ethernet cable, and have no experience with it, so I'm just sort of fumbling about. I know some folks who might, and have been looking around for an IRC room with people with experience usinb tftpboot with embedded devices.

One thing to note - don't attempt to put in a microSD card with a partially disassembled edge (with the cover off the e-Ink screen). Mine fell into the board, so I'm going to have to completely remove the circuit board to get the card out.

[toyz]

Originally Posted by nikkie

@toyz, I noticed that after I did the run boot_recover, on that first reboot, pushing the menu/rotate buttons actually displayed output to the terminal indicating the buttons had been pressed. They don't while in the bad flashed firmware. After it does that first boot though, it goes back to the bad firmware, so it doesn't help us too much. I tried doing a flash during that first reboot while the "Pocket Edge" logo displayed, but it didn't take. So the button connections must be wired differently for the regular edge, which explains why those of us with the bad firmware are not able to reflash.

I agree that tftpboot over usb is probably the best option. I don't have the usb-ethernet cable, and have no experience with it, so I'm just sort of fumbling about. I know some folks who might, and have been looking around for an IRC room with people with experience usinb tftpboot with embedded devices.

Some thoughts

1. I think by running "boot_recover" we are running the same kernel maybe root/initrd that the tablet normally would when pressing menu+rotate. I think if we pass it the correct boot args (as it would have gotten some how by the menu+rotate method) then it would go through it's re-flash procedure. I think this approach has a lot of promise. I will have to tear apart my good PE and see if I can watch bootargs based on the key presses you mentioned. (tomorrow)

2. At first I thought you must have a usb-ethernet adapter, but I'm not so sure now. Check out sections "Smart USB Peripherals ("Gadgets")" and "Most Linux PDAs: iPaq, Yopy, ..." here: http://www.linux-usb.org/usbnet/

From a practical point of view, I think u-boot would have to have more effort to have a driver stack usb+nic+tcpip than it would usb+clevertcpip hack.

[toyz]

Verified, we can tftp without a usb-ethernet adapter dongle. ptsentor, yay, we don't have to buy more hardware.

It turns out the PE and a lot of other devices have a CDC usb ethernet hardware in them. An example of this is the old cable modem, you can connect to a cable modem with USB, your cable modem acts like a usb ethernet nic into itself.

nikkie, try this:

Connect up your serial console cable.
Plug a mini-usb cable from your computer into the PE.
Boot PE, and "break" quickly with your terminal program as usual
(at this point, in my linux box's messages I see that it sees a usb disk, but no partitions)
Then type, "tftpboot"

Edge>> tftpboot
***** Plug-in USB cable & config usbdnet now ******
exit check_usb_connection:1
*** Warning: no boot file name; using 'C0A80265.img'
Using u2o-eth device
TFTP from server 192.168.2.100; our IP address is 192.168.2.101
Filename 'C0A80265.img'.
Load address: 0x500000
Loading: T T T T T T T T T T T

And now on my Linux box:

[34684.114687] usbcore: registered new interface driver usb-storage
[34684.114689] USB Mass Storage support registered.
[34685.595300] scsi 6:0:0:0: Direct-Access Android File-Stor Gadg etff PQ: 0 ANSI: 2
[34685.596274] sd 6:0:0:0: Attached scsi generic sg2 type 0
[34685.690992] sd 6:0:0:0: [sdb] Attached SCSI removable disk
[34760.467194] usb 2-2: USB disconnect, address 7
[34869.080063] usb 2-2: new high speed USB device using ehci_hcd and address 8
[34869.298676] cdc_subset 2-2:1.0: usb0: register 'cdc_subset' at usb-0000:00:1d.7-2, Boot Loader OBject, de:d4:3c:00:4e:08
[34869.298883] usbcore: registered new interface driver cdc_subset

On my Linux box, I then have a "usb0" with no IP set yet.

Almost there.......!!!

I'm sure I could tftp boot a kernel at this point, but I'm already booting the recovery kernel it seems on the device, so tftp in itself is not helping me. I need the recovery root/initrd accessible to go through the reflash motions.

[nikkie]

Well, the environment variables suggest that you could also do it over nfs, which would be considerably more convenient than setting up a tftpboot server.

In any case, it looks like we will very soon be needing an image to actually drop on here. Can you make one from your good PE using BusyBox?

We could probably drop the files via nfs or kermit if you've got an image ready.

It's interesting - they clearly put a fair bit of effort into making it easy for *them* to fix broken edge software, but then failed to make it easy for anyone else to do so. The below variables suggest that they have a recovery SD image which can be used to do maintenance, as well as a tftpboot server and nfs file system set up for copying shit.

If any of the real Edge devs are lurking here in the forums, you could toss us a bone and send us your maintenance image.

bootcmd=run boot_and
esiboot=sf read 0x500000 0x100000 0x300000
bootargs_and=mem=512M console=ttyS1,115200 flipped=0 initrd=0x01000000,24M ramdisk_size=24576 root=/dev/ram0 init=init ubi.mtd=Android
boot_and=nand read 0x01000000 0x01200000 0x00100000;setenv bootargs $(bootargs_and);setenv autoboot boot; bootz 0x500000
bootargs_andsd=mem=512M console=ttyS1,115200 flipped=0 init=init root=/dev/mmcblk0p1 rw rootwait
boot_andsd=setenv bootargs $(bootargs_andsd);setenv autoboot boot; bootz 0x500000
bootargs_maint=mem=512M console=ttyS1,115200 flipped=0 initrd=0x01000000,24M ramdisk_size=24576 root=/dev/ram0 ip=192.168.2.101:192.168.2.100::255.255.255.0::usb 0n mmode=1 esi_cmd=none
boot_maint=nand read 0x01000000 0x01300000 0x01800000;setenv bootargs $(bootargs_maint);setenv autoboot boot; bootz 0x500000
bootargs_user=mem=512M console=ttyS1,115200 flipped=0 initrd=0x01000000,24M ramdisk_size=24576 root=/dev/ram0 ip=192.168.2.101:192.168.2.100::255.255.255.0::usb 0n mmode=1 esi_cmd=--maint_user=cmd5
boot_user=nand read 0x01000000 0x01300000 0x01800000;setenv bootargs $(bootargs_user);setenv autoboot boot; bootz 0x500000
boot_recover=nand read 0x01000000 0x01300000 0x01800000;setenv esiboot sf read 0x500000 0x400000 0x300000;setenv bootargs $(bootargs_maint);setenv autoboot boot; bootz 0x500000
bootargs_maintsd=mem=512M console=ttyS1,115200 flipped=0 root=/dev/mmcblk0p1 rw rootwait ip=192.168.2.101:192.168.2.100::255.255.255.0::usb 0n mmode=1 esi_cmd=none
boot_maintsd=setenv bootargs $(bootargs_maintsd);setenv autoboot boot; bootz 0x500000
bootargs_nfs=mem=512M console=ttyS1,115200 flipped=0 root=/dev/nfs nfsroot=192.168.2.100:/exports/rootfs rw rootwait ip=192.168.2.101:192.168.2.100::255.255.255.0::usb 0n
boot_maintnfs=setenv bootargs $(bootargs_nfs);setenv autoboot boot; bootz 0x500000

[Gunnerp245]

A quick note of appreciation to 'all' in this thread for your investigative work. It is this type of pro-activeness that makes a community "a community". Though I do not have any of the problems recently discussed, having this outstanding research documented benefits all!

[toyz]

Originally Posted by nikkie

Well, the environment variables suggest that you could also do it over nfs, which would be considerably more convenient than setting up a tftpboot server.

In any case, it looks like we will very soon be needing an image to actually drop on here. Can you make one from your good PE using BusyBox?

We could probably drop the files via nfs or kermit if you've got an image ready.

It's interesting - they clearly put a fair bit of effort into making it easy for *them* to fix broken edge software, but then failed to make it easy for anyone else to do so. The below variables suggest that they have a recovery SD image which can be used to do maintenance, as well as a tftpboot server and nfs file system set up for copying shit.

If any of the real Edge devs are lurking here in the forums, you could toss us a bone and send us your maintenance image.

Typically, tftp is used to transfer the kernel, then nfs is used to supply the root FS. I think that is what is happening in this case.

Nikkie try,

run boot_user

It finds my update.zip and goes through the flashing process. But I still I see no change after reboot. Gurrr. More fiddling later.

[nikkie]

IT'S ALIVE!!!!!!!!!!!!!!!!!!!

*dances a jig*

Okay, So...toyz, I'm guessing you didn't watch while the flashing procedure was attempting to commence. In mine, the log indicated that there was a version mismatch since I was trying to flash a device that currently identified itself as an edge with the edgejr image. So, I downloaded the version of the firmware (Dingo) for the Pocket Edge that has the version commented out, slapped that on the usb drive, and ran run boot_user. It took, and my device was then working.

Next, I updated to Ermine, and it took fine. So, sweet. *dances another jig*

For those interested, here's what's necessary:

Either
1) a motherboard with serial support or
2) a USB to Serial cable such as this one

And
3) a Serial cord that you don't mind chopping the end off. We used a $6 cable from vetco.
4) 3 bricks worth of header from sparkfun

To make the cable - chop the male end of the db9 cable (the one that doesn't fit into the usb to serial cable), and solder it to the header per the pin diagrams shown in the pics linked below, which for us was Red Brown Yellow - if you bought the same cables I did - otherwise you need a multimeter or some such to figure it out.

Then for Windows 7, download Termite. Get your keyboard ready, and as soon as you've hit the boot button, start typing keys until the uboot prompt comes up. Use the settings in Envos post, except the parity bit should be NONE instead of odd.

Then in Termite, type

run boot_user

It will flash with whatever thing you've plugged in, in my case to the usb, (don't try and use a microSD card with the case open). If you have previously accidentally flashed with the edge firmware instead of the edgejr firmware, you should download the firmware from darkgrue's thread FOR YOUR DEVICE and flash with that. I see no reason not to make the same change to an Ermine rom, I just haven't done it yet.

Pics of the process and cabling are available here on flickr.

Gotchas: I couldn't get the serial usb dongle to work on OSX Lion, which is why I ended up doing it in Windows. You might find differently.

[ivanjt]

Congratulations nikkie!!

Now I think we should somehow collect together all the various firmwares and CLEARLY list them for what device they are for.

[tekknogenius]

Originally Posted by ivanjt

Congratulations nikkie!!

Now I think we should somehow collect together all the various firmwares and CLEARLY list them for what device they are for.

Perhaps the update.sh can include a device check?