So while debugging an issue with the “flasher” script when flashing a large number of boards. We are yanking power when all 4 led’s are on. It seems to reason, eventually the “flashing” microSD might just get corrupt.
So in the interest of making the “flashing” microSD more reliable and of course to mess up every single new user, as every existing blogs/wiki/etc everywhere will now be wrong.
The “flashing” is now done when all 4 led’s are off. (As the board has physically been shutdown by the script.)
- Of course, some os’s like ubuntu 14.04 like to just randomly crash when shutting down with our v3.8.x kernel, so while it “halted*” all 4 led’s are sometimes still on.
ubuntu 14.04: (it shut down, but randomly the 4 led’s are still on)
[ 100.173493] (NULL device *): gadget not registered.
[ 100.187875] System halted
- Whereas Debian Wheezy it works just fine…
So back to your regularly scheduled hacking time!
Regards,
So has this change been incorporated in the latest downloadable flasher images? If so it might be a good thing to note both here and on any official wiki instructions (possibly linked to FROM the Download page) that images AFTER said date have this change. Though many do not, we ought hold people responsible for reading the directions and documentation and link them to appropriate authoritative sources whenever possible.
Eric
So has this change been incorporated in the latest downloadable flasher images? If so it might be a good thing to note both here and on any official wiki instructions (possibly linked to FROM the Download page) that images AFTER said date have this change. Though many do not, we ought hold people responsible for reading the directions and documentation and link them to appropriate authoritative sources whenever possible.
Pretty much everything with a date stamp from within the last two days. I’ve updated the docs which mention 2 of the image links.
Otherwise it’ll be anything new from me.
As an alternative or maybe in conjunction you could have the 4 LED’s blink together in the following order: 0000000111010100011101110111000111010001 (DONE) with a bit duration somewhere between 250 & 62.5 milliseconds, 1 representing on, and 0 representing off and the string repeating a number of times prior to off or infinitely. come to think of this, have the script as it’s final task compute an MD5 or similar checksum on what was just written to verify a proper write and on success start flashing the above sequence. if somewhere along the process something went wrong causing it to exit, halt, or otherwise not obtain success it could blink 000000010101110100010111000101000101110101 (FAIL) using the same timing as above. Just a thought
Eric
Where are these new files located? Just wondering if they are better than the old one’s.
Thanks
new files are in the same place as the old ones. just that the new flasher images give a slightly different indication to the user when complete than the images prior to a couple days ago.
Eric
It would be cooler if it did the cylon back n forth while flashing..
Regards,
Hi,
So while debugging an issue with the "flasher" script when flashing a large number of boards. We are yanking power when all 4 led's are on. It seems to reason, eventually the "flashing" microSD might just get corrupt.
Did you verify that the SD power rail has a hickup during the process when microSD gets corrupted? Or how did you end up with LEDs being related to the issue?
I am asking this because we had on custom board a problem on GPMC NAND access. (reading sectors gave ECC errors randomly and then retrying the read all was fine, expect in some special cases when even that wasn't sufficient). We had to customize read access for NAND to always use prefetch engine (instead of odd bytes reading with direct acces,s and then reading rest with prefetch) in order to get more stability to access. This basically eliminated the whole issue on our boards. Signals in normal usage seemed to be OK when measured with scope.
We did send query to TI thru hardware vendor but no response so far on the issue...
I am just wondering if there is some unknown bug in the hardware that could also affect microSD/eMMC side?
Thanks,
Vesa Jääskeläinen
So this facility was programming 100's of boards with the old Angstrom
flasher. Which booted into a base image, that then extracted a known
.tar.gz to the eMMC.
With the debian image, we rsync the live system image on the microSD
to the eMMC.
During the test phase, they noticed a few of the boards where not
coming up after eMMC programming. With your standard debian: 'please
enter root password for fsck' error. By shutting down the board,
might still only be a bandaid, but it should keep the flasher microSD
file system in much better shape.
Regards,
As an alternative or maybe in conjunction you could have the 4 LED’s blink together in the following order: 0000000111010100011101110111000111010001 (DONE) with a bit duration somewhere between 250 & 62.5 milliseconds, 1 representing on, and 0 representing off and the string repeating a number of times prior to off or infinitely. come to think of this, have the script as it’s final task compute an MD5 or similar checksum on what was just written to verify a proper write and on success start flashing the above sequence. if somewhere along the process something went wrong causing it to exit, halt, or otherwise not obtain success it could blink 000000010101110100010111000101000101110101 (FAIL) using the same timing as above. Just a thought
It would be cooler if it did the cylon back n forth while flashing…
Not as cool a doing a cylon, but it is at least a recognizable sweeping pattern (sweep_leds.sh · GitHub):
#!/bin/sh
BASE=/sys/class/leds/beaglebone\:green\:usr
echo timer > ${BASE}0/trigger
echo 2000 > ${BASE}0/delay_off
sleep 0.5
echo timer > ${BASE}1/trigger
echo 2000 > ${BASE}1/delay_off
sleep 0.5
echo timer > ${BASE}2/trigger
echo 2000 > ${BASE}2/delay_off
sleep 0.5
echo timer > ${BASE}3/trigger
echo 2000 > ${BASE}3/delay_off
As an alternative or maybe in conjunction you could have the 4 LED's
blink together in the following order:
0000000111010100011101110111000111010001 (DONE) with a bit duration
somewhere between 250 & 62.5 milliseconds, 1 representing on, and 0
representing off and the string repeating a number of times prior to off or
infinitely. come to think of this, have the script as it's final task
compute an MD5 or similar checksum on what was just written to verify a
proper write and on success start flashing the above sequence. if
somewhere along the process something went wrong causing it to exit, halt,
or otherwise not obtain success it could blink
000000010101110100010111000101000101110101 (FAIL) using the same timing as
above. Just a thought
It would be cooler if it did the cylon back n forth while flashing..
Yes, but the morse sequence actually conveys something meaningful (an exit
code of sorts) kinda like the audio post codes of old in the pc world.
This eliminates the need for a serial console when flashing.
Eric
It would seem that a piece of “official” documentation ought to be updated then. As of 5:21pm Pacific time on 29MAY2014 http://beagleboard.org/Getting%20Started#update still reflects the old pattern. I’d propose the following sentence be added, “flasher images dated after automatically power down the board upon completion, thus all 4 USRx LEDs will be off.”
Eric
It would seem that a piece of "official" documentation ought to be updated
then. As of 5:21pm Pacific time on 29MAY2014
Getting Started - BeagleBoard | How do I start using my board? still reflects the old
pattern. I'd propose the following sentence be added, "flasher images dated
after <insert proper date> automatically power down the board upon
completion, thus all 4 USRx LEDs will be off."
Thanks for the concrete suggestion. Please check the updated wording
for clarity.
Yes, now works as stated. The only reason I somewhat avoided the
construction used is that one could ask "which is it, on or off?" but I did
notice that the flasher actually illuminates all 4 LED's briefly prior to
power off. So yes, it is kinda both. hopefully people will have sense
enough to figure out that an unpowered board will have no indicators
illuminated (as they require power)
Eric