Announce: Flasher Changes

[Robert Nelson]

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,

--
Robert Nelson
http://www.rcn-ee.com/

[Eric Fort]

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

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Robert Nelson]

On May 16, 2014 5:49 PM, "Eric Fort" <eric...@gmail.com> wrote:
>
> 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.

[Eric Fort]

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

[Bayani Custodio]

Where are these new files located? Just wondering if they are better than the old one's.

Thanks

Sent from my iPad

[Eric Fort]

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

[Robert Nelson]

On Sat, May 17, 2014 at 5:32 PM, Bayani Custodio <bayani.p...@gmail.com> wrote:

Where are these new files located? Just wondering if they are better than the old one's.

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2014-05-14

http://elinux.org/BeagleBoardUbuntu#Flasher

http://elinux.org/BeagleBoardDebian#Flasher

Regards,

[Robert Nelson]

On Fri, May 16, 2014 at 7:24 PM, Eric Fort <eric...@gmail.com> wrote:

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..

Regards,

[Vesa Jääskeläinen]

Hi,

On 16/05/14 17:53, Robert Nelson wrote:
> 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

[Robert Nelson]

On Mon, May 19, 2014 at 1:46 PM, Vesa Jääskeläinen <dac...@gmail.com> wrote:
> Hi,
>
>
> On 16/05/14 17:53, Robert Nelson wrote:
>>
>> 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?

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.

[Jason Kridner]

Not as cool a doing a cylon, but it is at least a recognizable sweeping pattern (https://gist.github.com/jadonk/71a409ffaa151eb1f8e8):

#!/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

[Robert Nelson]

Thanks Jason!

Added that:
https://github.com/RobertCNelson/boot-scripts/commit/d75480ef2d4f6b6e415ca5297e193c5e83f9aa3f

It'll get pulled in as we update things.

[Eric Fort]

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

[Eric Fort]

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 <insert proper date> automatically power down the board upon completion, thus all 4 USRx LEDs will be off."

Eric

On Fri, May 16, 2014 at 7:53 AM, Robert Nelson <robert...@gmail.com> wrote:

--

[Jason Kridner]

On Thu, May 29, 2014 at 8:29 PM, Eric Fort <eric...@gmail.com> wrote:
> 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 <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.

[Eric Fort]

On Mon, Jun 2, 2014 at 10:23 AM, Jason Kridner <jkri...@beagleboard.org> wrote:

On Thu, May 29, 2014 at 8:29 PM, Eric Fort <eric...@gmail.com> wrote:
> 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 <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