this is the very first image i've flashed that simply bricked my
BBB -- no LEDs (other than power) when i tried to reboot it. currently
reflashing with the same image, did anyone else have trouble with that
image?
rday
I have not tested it.
Gerald
well, that's twice i've flashed with that image and produced a dead
BBB.
rday
Could be. I will try it here in a little while myself and report back.
Gerald
if you take a look at this section on my wiki page:
that section of the script that possibly updates the EEPROM looks new,
could that be doing something bad to the BBB, rendering it unbootable?
if so, then reflashing with an earlier flasher image might not fix
things if it leaves "bad" EEPROM data on the board.
we'll know shortly as i'm reflashing with an earlier image that
worked just fine before. but i tried that "test" flasher image twice,
and it totally bricked my board.
rday
BBB EEPROM is write protected. So unless you are poking a wire to ground on the test point, it should not happen.
Also, make sure after you finish flashing that you have ejected the SD card. Otherwise, it will hang.
Obviously if you are re-flashing the board, it is not bricked,
Gerald
i just reflashed with the 2013.05.08 flasher image, and it powered
up nicely. so i don't trust that latest "test" flasher image.
rday
Well, it may be bad, That is not exactly against the rules. It is for testing. Granted it should at least boot, But sometimes, they don’t don’t. Trust me. I have seen my share of bad images.
Did you try the 5_11 version?
Gerald
BBB EEPROM is write protected. So unless �you are poking a wire to
ground on the test point, it should not happen.
so what is that EEPROM code in that version of emmc.sh doing?
Also, make sure after you finish flashing�that�you have ejected the
SD card. Otherwise, it will hang.
i have this down to a ritual by now. 
Obviously if you are�re-flashing�the board, it is not bricked,
you're right, "bricked" was a bad choice of words. but i'll be
interested to know if anyone else got a successful flash with that
latest "test" image. every other flasher image i've tried updated
beautifully.
rday
Well, it may be bad, That is not exactly against the rules. It is
for testing. Granted it should at least boot, But sometimes, they
don't don't. Trust me. I have seen my share of bad images.
i know ... i'm just reporting what i see.
Did you try the 5_11 version?
i don't think i did, i think the 5.12 was the first "test" image i
tried. i think i'll just give the test images a rest for the remainder
of the day and wait to see if anyone else gets the 5.12 test image to
work. if it works for anyone else, i'll be at least a little puzzled.
rday
p.s. my flashing ritual involves running off of 5V, waiting for flash
to complete, yanking power cord, removing uSD card, then powering up
off of USB so i can log in. seems to work.
The code for the EMMC is writing the data to an empty EEPROM, as that is the way the comes, in the production environment. We ground the test point during the flashing process. The image is used to flash the boards in production.
Gerald
ah, got it.
rday
I tested the 5_12 image I can confirm that it is, well, useless.
U-Boot SPL 2013.01-00287-g9c748e0-dirty (Mar 08 2013 - 10:36:42)
OMAP SD/MMC: 0
mmc_send_cmd : timeout: No status update
reading u-boot.img
reading u-boot.img
U-Boot 2013.01-00287-g9c748e0-dirty (Mar 08 2013 - 10:36:42)
I2C: ready
DRAM: 512 MiB
WARNING: Caches not enabled
NAND: No NAND device found!!!
0 MiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Warning - readenv() failed, using default environment
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Peripheral mode controller at 47401000 using PIO, IRQ 0
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Host mode controller at 47401800 using PIO, IRQ 0
Net: not set. Reading from E-fuse
cpsw, usb_ether
Hit any key to stop autoboot: 0
mmc_send_cmd : timeout: No status update
Card did not respond to voltage select!
mmc0(part 0) is current device
mmc_send_cmd : timeout: No status update
Card did not respond to voltage select!
U-Boot#
Gerald
I tested the 5_12 image I can confirm that it is, well, useless.
I swapped hard drives on the buildserver which caused[1] an old MLO/u-boot combo to be used:
U-Boot SPL 2013.01-00287-g9c748e0-dirty (Mar 08 2013 - 10:36:42)
That's supposed to be 2013.04, build May 10 or newer.
OMAP SD/MMC: 0
mmc_send_cmd : timeout: No status update
reading u-boot.img
reading u-boot.imgU-Boot 2013.01-00287-g9c748e0-dirty (Mar 08 2013 - 10:36:42)
Same here.
05.13 has the correct bootloader files. It also has some more flasher related changes compared to 05.08:
Koen Kooi (10):
linux-mainline 3.8: add support for rs232 cape, improve camera cape reliability
linux-mainline 3.8: add patch to make camera cape work on BBB
u-boot-denx: add patch for eMMC resetctrl
linux-mainline 3.8: add patches to try 1080p on lcdc
contrib: bone-flash-tool: enable drm.debug=7 by default
gadget-init: fix EEPROM parsing in g-ether-load.sh
contrib: bone-flash-tool: don't wipe valid EEPROM header
gadget-init: add console on g_multi
linux-mainline 3.8: update 3.8.13
regards,
Koen
[1] The technical explanation: DEPLOY_DIR is not completely under sstate control
thanks for confirming that, just wanted to make sure i wasn't doing
anything silly.
rday
ok, downloading the test 2013.05.13 flasher image now, will let you
know how it turns out.
rday
just flashed and booted "test" 2013.05.13 flasher image, it came up
nicely (thanks, koen) but the slight left-to-right jitter on my ASUS
VE228H monitor is still there as before so i'll just wait to hear from
gerald regarding any exciting new HDMI developments.
whoa, partway through the automatic login, i have the dialog box:
"A program is still running:
Unknown
Not responding
Waiting for the program to finish ..."
that's definitely new, i gave it a minute to do something but nothing
changed so i ssh'ed in and did a "reboot", BBB came back and ... same
thing. currently sitting at:
"Automatically logging in ..."
with that same dialog box. i am not on the network via the BBB's
ethernet interface in case it's somehow waiting for network action.
oh, wait, i didn't have my powered hub connected to the BBB for
mouse and keyboard, maybe that's it -- shut down, power off, plug in
hub, power up again and ... no difference, stuck at same dialog, not
sure what it's waiting for but i can still ssh in so i did and here's
the output from "ps -ef" if anyone wants to peruse:
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 00:00 ? 00:00:00 /sbin/init
root 2 0 0 00:00 ? 00:00:00 [kthreadd]
root 3 2 0 00:00 ? 00:00:00 [ksoftirqd/0]
root 4 2 0 00:00 ? 00:00:00 [kworker/0:0]
root 5 2 0 00:00 ? 00:00:00 [kworker/0:0H]
root 6 2 0 00:00 ? 00:00:00 [kworker/u:0]
root 7 2 0 00:00 ? 00:00:00 [kworker/u:0H]
root 8 2 0 00:00 ? 00:00:00 [migration/0]
root 9 2 0 00:00 ? 00:00:00 [rcu_bh]
root 10 2 0 00:00 ? 00:00:00 [rcu_sched]
root 11 2 0 00:00 ? 00:00:00 [watchdog/0]
root 12 2 0 00:00 ? 00:00:00 [khelper]
root 13 2 0 00:00 ? 00:00:00 [kdevtmpfs]
root 14 2 0 00:00 ? 00:00:00 [netns]
root 15 2 0 00:00 ? 00:00:00 [kworker/0:1]
root 16 2 0 00:00 ? 00:00:00 [bdi-default]
root 17 2 0 00:00 ? 00:00:00 [kintegrityd]
root 18 2 0 00:00 ? 00:00:00 [kblockd]
root 19 2 0 00:00 ? 00:00:00 [khubd]
root 20 2 0 00:00 ? 00:00:00 [irq/86-44e0b000]
root 21 2 0 00:00 ? 00:00:00 [kworker/u:1]
root 26 2 0 00:00 ? 00:00:00 [irq/46-4819c000]
root 35 2 0 00:00 ? 00:00:00 [rpciod]
root 37 2 0 00:00 ? 00:00:00 [khungtaskd]
root 38 2 0 00:00 ? 00:00:00 [kswapd0]
root 39 2 0 00:00 ? 00:00:00 [fsnotify_mark]
root 40 2 0 00:00 ? 00:00:00 [nfsiod]
root 41 2 0 00:00 ? 00:00:00 [crypto]
root 44 2 0 00:00 ? 00:00:00 [pencrypt]
root 45 2 0 00:00 ? 00:00:00 [pdecrypt]
root 52 2 0 00:00 ? 00:00:00 [OMAP UART0]
root 55 2 0 00:00 ? 00:00:00 [kpsmoused]
root 67 2 0 00:00 ? 00:00:00 [kworker/u:2]
root 70 2 0 00:00 ? 00:00:00 [mmcqd/1]
root 71 2 0 00:00 ? 00:00:00 [mmcqd/1boot0]
root 72 2 0 00:00 ? 00:00:00 [mmcqd/1boot1]
root 73 2 0 00:00 ? 00:00:00 [kworker/0:2]
root 74 2 0 00:00 ? 00:00:00 [deferwq]
root 77 2 0 00:00 ? 00:00:00 [kworker/0:1H]
root 78 2 0 00:00 ? 00:00:00 [jbd2/mmcblk0p2-]
root 79 2 0 00:00 ? 00:00:00 [ext4-dio-unwrit]
root 85 1 0 00:00 ? 00:00:00 /lib/systemd/systemd-udevd
root 89 1 0 00:00 ? 00:00:01 /lib/systemd/systemd-journald
root 100 2 0 00:00 ? 00:00:00 [krfcommd]
avahi 121 1 0 00:00 ? 00:00:00 avahi-daemon: running [beaglebone.local]
root 122 1 0 00:00 ? 00:00:00 /usr/sbin/connmand -n
root 123 1 0 00:00 ? 00:00:00 /bin/sh /usr/bin/g-ether-load.sh
root 125 1 4 00:00 ? 00:00:05 /usr/bin/node4 /usr/share/cloud9/bin/cloud9.js -l 0.0.0.0 -w /var/lib/cloud9 -p 3000
root 126 1 1 00:00 ? 00:00:01 /usr/bin/node autorun.js
root 127 1 1 00:00 ? 00:00:01 /usr/bin/python gateone.py
root 130 1 0 00:00 ? 00:00:00 /lib/systemd/systemd-logind
root 132 1 0 00:00 ? 00:00:00 /usr/sbin/crond -n
999 133 1 0 00:00 ? 00:00:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
root 135 1 0 00:00 tty1 00:00:00 /sbin/agetty --noclear tty1 38400 linux
root 136 1 0 00:00 ? 00:00:00 /usr/sbin/gdm-binary -nodaemon
avahi 138 121 0 00:00 ? 00:00:00 avahi-daemon: chroot helper
root 242 136 0 00:00 ? 00:00:00 /usr/libexec/gdm-simple-slave --display-id /org/gnome/DisplayManager/Display1
root 243 2 0 00:00 ? 00:00:00 [file-storage]
root 250 242 1 00:00 tty2 00:00:01 /usr/bin/X :0 -br -verbose -auth /var/run/gdm/auth-for-gdm-ZfVRKq/database -nolisten tcp
root 252 1 0 00:00 ? 00:00:00 /usr/sbin/wpa_supplicant -u
root 254 123 0 00:00 ? 00:00:00 /usr/sbin/udhcpd -f -S /etc/udhcpd.conf
root 255 2 0 00:00 ? 00:00:00 [flush-179:0]
root 340 1 0 00:00 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root 406 1 0 00:00 ? 00:00:00 /usr/libexec/polkitd --no-debug
root 407 1 0 00:00 ttyO0 00:00:00 /sbin/agetty -s ttyO0 115200
gdm 452 1 0 00:00 ? 00:00:00 /usr/bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session
gdm 453 242 0 00:00 ? 00:00:00 /usr/bin/gnome-session --autostart=/usr/share/gdm/autostart/LoginWindow/
gdm 456 1 1 00:00 ? 00:00:01 /usr/libexec/gconfd-2
gdm 460 1 0 00:00 ? 00:00:00 /usr/libexec/gnome-settings-daemon --gconf-prefix=/apps/gdm/simple-greeter/settings-manager-plugins
gdm 462 1 0 00:00 ? 00:00:00 /usr/libexec/gvfsd
gdm 469 453 1 00:00 ? 00:00:01 /usr/libexec/gdm-simple-greeter
gdm 470 453 0 00:00 ? 00:00:00 gnome-power-manager
root 472 242 0 00:00 ? 00:00:00 /usr/libexec/gdm-session-worker
root 474 1 0 00:00 ? 00:00:00 /usr/libexec/upowerd
root 568 1 4 00:01 ? 00:00:00 /usr/sbin/dropbear -i -r /etc/dropbear/dropbear_rsa_host_key -p 22
root 569 568 0 00:01 pts/0 00:00:00 -sh
root 570 569 0 00:01 pts/0 00:00:00 ps -ef
What resolution did the monitor come up to?
Gerald
it *looks* to be the same as yesterday, which was 1280x720. since
the desktop autologin hung, i can't get to the "Preferences" menu to
check, but it appears indistinguishable from yesterday.
since i still have access to the command line via ssh, what's a
command i can run to display that info?
rday
i grabbed the dmesg content from the BBB and pasted it here:
have fun.
rday