[U-Boot] Problem with stand-alone apps

[U-Boot] Problem with stand-alone apps

[ANDY KENNEDY]

All,

In an effort to play by the rules, we created a stand alone app that
handles breaking the boot process with bootdelay set to 0.  We require
a special key sequence to break into the boot process to ensure security,
and to ensure we do not interrupt the boot process with stray key strokes.
We are seeing strange behavior from our applet.  There are several API
calls that we make from within the app that seem to make our processor
go into a code violation error (even something as simple as a printf).

It seems that things were working better in 2010.12.  We chose to move
to 2013.04 for some additional fixes that we saw were pushed in by
Freescale.  BTW, this is also similar to my previous e-mail thread that
I started a month or so ago in which I stated there was general flakiness.
We are reasonably confidant that our timing for our NOR flash is correct.
Likewise, for our DDR3.  Both of these sets of parameters were done with
the aid of Freescale themselves (given the tool they were using this is
unlikely).

Anyone else use the stand alone applications in 2013.04 successfully?

Thanks,
Andy

[U-Boot] Problem with stand-alone apps

[Tom Rini]

On Wed, Aug 28, 2013 at 03:07:47PM +0000, ANDY KENNEDY wrote:

> All,
> 
> In an effort to play by the rules, we created a stand alone app that
> handles breaking the boot process with bootdelay set to 0.  We require
> a special key sequence to break into the boot process to ensure security,
> and to ensure we do not interrupt the boot process with stray key strokes.
> We are seeing strange behavior from our applet.  There are several API
> calls that we make from within the app that seem to make our processor
> go into a code violation error (even something as simple as a printf).

Unrelated, do CONFIG_AUTOBOOT_STOP_STR and similar not provide what you
need here?  See doc/README.autoboot

> It seems that things were working better in 2010.12.  We chose to move
> to 2013.04 for some additional fixes that we saw were pushed in by
> Freescale.  BTW, this is also similar to my previous e-mail thread that
> I started a month or so ago in which I stated there was general flakiness.
> We are reasonably confidant that our timing for our NOR flash is correct.
> Likewise, for our DDR3.  Both of these sets of parameters were done with
> the aid of Freescale themselves (given the tool they were using this is
> unlikely).
> 
> Anyone else use the stand alone applications in 2013.04 successfully?

Unaligned access problems?  A hacky way to check this would be to either
use an older compiler (such as ELDK 5.2.x or 5.1) or make u-boot built
entirely with -mno-unaligned-access (kludge this in, in
arch/arm/config.mk).

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130828/30ed9186/attachment.pgp>

[U-Boot] Problem with stand-alone apps

[James Chargin]

On 08/28/2013 08:07 AM, ANDY KENNEDY wrote:
> All,
>
> In an effort to play by the rules, we created a stand alone app that
> handles breaking the boot process with bootdelay set to 0.  We require
> a special key sequence to break into the boot process to ensure security,
> and to ensure we do not interrupt the boot process with stray key strokes.
> We are seeing strange behavior from our applet.  There are several API
> calls that we make from within the app that seem to make our processor
> go into a code violation error (even something as simple as a printf).

I'm using a much older version of U-Boot (2010.12) for the P1022. I was 
seeing some flakiness a while back. My problems were solved when I 
started using "bootm" to start my stand alone application, rather than 
"go". I don't know if this might be your problem but I thought it better 
to provide an attempt at help rather than nothing.

This change was prompted by an extended mailing list discussion starting 
with an email from York Sun on 19Mar2013 (Message-ID: 
<1363724992-9803-1-git-send-email-yorksun@freescale.com>).

I added some short sections to the wiki about my experiences. See 
http://www.denx.de/wiki/view/DULG/UBootStandalone#Section_5.12.3.

Jim

>
> It seems that things were working better in 2010.12.  We chose to move
> to 2013.04 for some additional fixes that we saw were pushed in by
> Freescale.  BTW, this is also similar to my previous e-mail thread that
> I started a month or so ago in which I stated there was general flakiness.
> We are reasonably confidant that our timing for our NOR flash is correct.
> Likewise, for our DDR3.  Both of these sets of parameters were done with
> the aid of Freescale themselves (given the tool they were using this is
> unlikely).
>
> Anyone else use the stand alone applications in 2013.04 successfully?
>
> Thanks,
> Andy
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
>

-- 
Jim Chargin
AJA Video Systems                       jimc at aja.com
(530) 271-3334                          http://www.aja.com

[U-Boot] Problem with stand-alone apps

[ANDY KENNEDY]

> From: James Chargin [mailto:jimccrown at gmail.com]
> On 08/28/2013 08:07 AM, ANDY KENNEDY wrote:
> > All,
> >
> > In an effort to play by the rules, we created a stand alone app that
> > handles breaking the boot process with bootdelay set to 0.  We require
> > a special key sequence to break into the boot process to ensure security,
> > and to ensure we do not interrupt the boot process with stray key strokes.
> > We are seeing strange behavior from our applet.  There are several API
> > calls that we make from within the app that seem to make our processor
> > go into a code violation error (even something as simple as a printf).
> 
> I'm using a much older version of U-Boot (2010.12) for the P1022. I was
> seeing some flakiness a while back. My problems were solved when I
> started using "bootm" to start my stand alone application, rather than
> "go". I don't know if this might be your problem but I thought it better
> to provide an attempt at help rather than nothing.

Jim, thanks that works.  There are some annoyances about using the bootm.
For example, we are trusting in the return code of our app.  Bootm obscures
this from us so we had to get creative on it and use env vars to pass
around return codes.  Somewhat a pain in the rear, but still, we have
something that works now.

So, another question back to the group is this:  When one builds a
stand-alone application and wraps it into a uImage, the Image has some
cool features added to it (e.g. CRC32).  What else does the mkimage header
provide?  My theory is that the code being copied out of the NOR flash
needs to be zeroed for some space AFTER the image.  Is this correct?

Andy

[U-Boot] Problem with stand-alone apps

[ANDY KENNEDY]

> From: Tom Rini [mailto:tom.rini at gmail.com] On Behalf Of Tom Rini
> 
> On Wed, Aug 28, 2013 at 03:07:47PM +0000, ANDY KENNEDY wrote:
> 
> > All,
> >
> > In an effort to play by the rules, we created a stand alone app that
> > handles breaking the boot process with bootdelay set to 0.  We require
> > a special key sequence to break into the boot process to ensure security,
> > and to ensure we do not interrupt the boot process with stray key strokes.
> > We are seeing strange behavior from our applet.  There are several API
> > calls that we make from within the app that seem to make our processor
> > go into a code violation error (even something as simple as a printf).
> 
> Unrelated, do CONFIG_AUTOBOOT_STOP_STR and similar not provide what you
> need here?  See doc/README.autoboot

Yeah, that would _almost_ work, but not.  I need to do something like:

If no boot, switch mux else boot.  I don't think that will work with
CONFIG_AUTOBOOT_STOP_STR.  It is close, but not exactly what we need.

Our configuration is multiple processor, one serial console.  Thus, there is
one processor that is fixed as a receiver, the rest only see/send traffic
when the multiplexor is set to that processor.  So, If the user is attempting
to break into one of the OTHER devices, and presses a stray
CONFIG_AUTOBOOT_STOP_STR then the system would stop unexpectedly.

Unfortunately, front panel space is a premium on our system :\.

Thanks for the info, though!

Andy