[U-Boot] Problem with stand-alone apps
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
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).
From: Tom Rini [mailto:tom.rini@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
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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
From: James Chargin [mailto:jimccrown@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
participants (3)
-
ANDY KENNEDY -
James Chargin -
Tom Rini