beagleboard recovery take 2

[2013-03-06 update]:
after a few years of letting things rot, I just managed to pick up my old binaries and gave it a dry run:
https://github.com/nmenon/beagle-recover has the original working binaries since the google groups link no longer work. NOTE: I HAVE NOT TRIED WITH ANY OF THE LATEST SOURCES. I do not have plans to do so in the future as well  - an quick try indicated things are broke :(

[Original post]

http://groups.google.com/group/beagleboard/web/beagle_recover.tar.bz2 has the recovery package ready to go for ubuntu 8.04 32bit OS: download this, run sudo ./recover_beagle.sh - as shown in the video... Steps summary:
1. first shutdown the board.
2. run 'sudo recover_beagle.sh /dev/ttyUSB0' in a terminal -> you need
super user permissions(sudo permissions) to run this script.
3. Keep the pushbutton S1pressed while powering on the board -> there
are two white push button switches, use the one closer to the edge of
the board
NOTE: if your nand is completely erased, the above step wont be
needed, but what the heck, use it for preventing all kind of cases
where you have an MMC card/partly corrupted nand etc..
4. Once the terminal starts downloading, you can remove ur finger off
the S1 switch ;)..
5. wait a bit for files to reach and be flashed :).. the script should
exit happily once it is done.

With u-boot-v1 in mainline arm repo, here is take two of the same.. this time with a script and a non-Oscar winning video:


complete discussion and thread here: http://groups.google.com/group/beagleboard/t/e193478766224281

copied here for details:

On my ubuntu 8.04 32bit OS PC, here are the steps I did.

------------- Build Steps ----------------
$git clone git://gitorious.org/x-load-omap3/mainline.git xloader
$git clone git://git.denx.de/u-boot-arm.git
$git clone git://git.denx.de/u-boot-v2.git
$git clone git://github.com/nmenon/omap-u-boot-utils.git


$alias mymake='make -j2 CROSS_COMPILE=arm-none-linux-gnueabi- V=1 ARCH=arm'
$cd x-loader
$mymake omap3530beagle_config;mymake
$wget "http://beagleboard.googlecode.com/files/signGP.c"
$gcc -o signGP signGP.c
$./signGP x-load.bin 0x40200800
$cd ../u-boot-v2/
$mymake omap3530_beagle_per_uart_defconfig; mymake
$cd ../u-boot-arm
$mymake omap3_beagle_config;mymake
$cd ../omap-u-boot-utils
$make;make usb
$mkdir -p ../beagle_recover/target_files;cd ../beagle_recover

$cp ../omap-u-boot-utils/pusb ../omap-u-boot-utils/pserial
../omap-u-boot-utils/ukermit ../omap-u-boot-utils/ucmd .
$cp ../u-boot-arm/u-boot.bin target_files/u-boot-v1.bin
$cp ../u-boot-v2/uboot.bin target_files/u-boot-v2.bin
$cp ../xloader/x-load.bin.ift target_files/x-load.bin.ift

------------- Flashing Steps ----------------
$TTY=/dev/ttyS0
$sudo ./pusb -f ./target_files/u-boot-v2.bin
Connected just the USB cable to the board with the user switch S1 pressed.
$./ucmd -p $TTY -c "loadb -f /dev/ram0" -e "bps..."
$./ukermit -p $TTY -f target_files/u-boot-v1.bin
$./ucmd -p $TTY -c "go 0x80000000" -e "serial";./ucmd -p $TTY -c "help" -e "#"
$./ucmd -p $TTY -c "nand erase" -e "#"
$./ucmd -p $TTY -c "nand write.i 80000000 80000 80000" -e "#"
$./ucmd -p $TTY -c "loadb 80000000" -e "bps..."
$./ukermit -p $TTY -f target_files/x-load.bin.ift
$./ucmd -p $TTY -c "nandecc hw" -e "#"
$./ucmd -p $TTY -c "nand write.i 80000000 0 80000" -e "#"


The following step is optional if you want to remove the autoboot.
$ ./ucmd -p $TTY -c "setenv bootcmd;nandecc sw;saveenv" -e "#"


The attached tarball contain prebuilt images, and you can also use a
script recover_beagle.sh which is part of the tgz attached.

Grr at code.google.com uploads

After using a bunch of time getting firefox to upload from my ubuntu 8.10 box to here, I got an util which told me to use my code.google.com password instead of my google passwd.. Grrrr...
anyway, couple of my sleep hours later, u-boot utils rev 0.2 "Jumpin' Monkey" is uploaded (the code name was made up as i typed ;))

is nand ecc correction logic sane enough?

for some time now, I have gone with the belief that the nand ecc imlementation such as this which I helped write good enough for nand devices, but Vimal Singh pointed me to these two articles:
http://lists.infradead.org/pipermail/linux-mtd/2008-August/022611.html
http://lists.infradead.org/pipermail/linux-mtd/2008-August/022613.html

Essentially:
If we do just old_ecc^new_ecc to detect/correct ecc errors - the logic handles the case of bit flip error at 63rd bit(as e.g.) faultily. I was completely unaware of this weakness of the algo.. thanks Vimal for pointing me here..

I have plans of setting up a bit of code to verify this (essentially hack up the current drivers by overriding the read path ;) ).. will post if I can proove(I suspect this would be the case) this is the case with gpmc..

Changes in Linux OMAP

Tony Lindgren, Linux OMAP maintainer announced that source.mvista.com linux omap copy would not be used anymore.. It has been more than three years since the discussion on hosting the kernel tree at mvista site.. Thank you mvista for hosting all our pulls to date.. from now on look here (actually it was there since 2006, though I will miss doing "linux omap git" on google).

omap peripheral boot - what the heck is it?

Kinda got a few questions on how omap uboot utils works.. so here is my attempt to try and summarize what omap3 TRM says(for details TRM is the best place to go - yes, it is beautifully written ;) ):
ARM is a useless unless we have some software to run on it, so OMAP has a special piece of ROM code which gets the initial control of things. Now, ROM code is capable of:
a) booting off a memory device such as NOR, NAND, OneNAND, MMC etc.. kind of devices.
b) booting off a peripheral such as UART, USB etc..
Before anyone asks, yep ROMCode is a software code within OMAP. And, yep, and yeah it's got all kind of drivers for devices it supports, and further yeah, it is a tiny optimized code and finally NO - you cant modify it since it is Read Only Memory.

Now, in the world of OMAP s/w guys, (a) is called memory boot and (b) is called peripheral boot.. Now, how does ROM Code know what kind of device you have and which mode you want to boot from? This is called the SYSBOOT(again read the TRM for details). in short, SYSBOOT tells OMAP ROM Code, ok dude.. now please boot from USB cable, if that fails - try UART, then MMC1 else try NAND, else assume the user(me) is really confused and just get stuck in a loop.

How does peripheral boot work?
It is rather simple if you look at it: when OMAP wakesup in USB/UART mode, it shouts out "hey I am awake"(not literally) by throwing out what is called ASIC ID. The guy on the other end of the cable keeps watching the link(UART/USB) for this message and responds with a predetermined command back saying - "Oh great Rom Code, please recieve and execute the file I am sending you next.. it's file size is xyz"(again not literally, but you get the picture).. in the case of USB, well USB Gadget is what OMAP acts as (you can check the TRM for the exact class and USB descriptors it throws out) - MUSB is used in OMAP3. Now, ROMCode will wait for a short duration of times for slow pokes like me to respond back.

Now, If I dont send a file request to it within a predetermined time(details in TRM), it switches to the next boot device.

The file which is downloaded is put in SRAM and executed.

Well that is the short story.. pusb and pserial essentially explain the above in code.. Hope it helped..