Patchwork [U-Boot,v2,5/5] bootm: Add the missing PREP stage to bootz and correct image handling

login
register
mail settings
Submitter Simon Glass
Date July 4, 2013, 8:26 p.m.
Message ID <1372969571-17043-5-git-send-email-sjg@chromium.org>
Download mbox | patch
Permalink /patch/256995/
State Accepted
Delegated to: Tom Rini
Headers show

Comments

Simon Glass - July 4, 2013, 8:26 p.m.
In the recent bootm refactor, the PREP stage was missing in the bootz
command. This causes unpredictable behaviour.

The use of a local variable means that the reset of cmd_bootm.c does not
in fact use the same image structure, so remove this.

Also manually set the OS type to Linux, since this is the only possibility
at present, and we need to select the right boot function.

Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v2:
- Remove local images variable
- Set OS type to Linux in all cases

 common/cmd_bootm.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
Tom Rini - July 8, 2013, 2:13 p.m.
On Thu, Jul 04, 2013 at 01:26:11PM -0700, Simon Glass wrote:
> In the recent bootm refactor, the PREP stage was missing in the bootz
> command. This causes unpredictable behaviour.
> 
> The use of a local variable means that the reset of cmd_bootm.c does not
> in fact use the same image structure, so remove this.
> 
> Also manually set the OS type to Linux, since this is the only possibility
> at present, and we need to select the right boot function.
> 
> Signed-off-by: Simon Glass <sjg@chromium.org>

With the whole series applied, I still see a hang at:
Kernel image @ 0x80200000 [ 0x000000 - 0x3d44a0 ]

Starting kernel ...

Perhaps something to do with how my DDR is not at 0x0 -> 256MiB but
0x80000000 -> 256MiB ?
robertcnelson@gmail.com - July 8, 2013, 2:17 p.m.
On Mon, Jul 8, 2013 at 9:13 AM, Tom Rini <trini@ti.com> wrote:
> On Thu, Jul 04, 2013 at 01:26:11PM -0700, Simon Glass wrote:
>> In the recent bootm refactor, the PREP stage was missing in the bootz
>> command. This causes unpredictable behaviour.
>>
>> The use of a local variable means that the reset of cmd_bootm.c does not
>> in fact use the same image structure, so remove this.
>>
>> Also manually set the OS type to Linux, since this is the only possibility
>> at present, and we need to select the right boot function.
>>
>> Signed-off-by: Simon Glass <sjg@chromium.org>
>
> With the whole series applied, I still see a hang at:
> Kernel image @ 0x80200000 [ 0x000000 - 0x3d44a0 ]
>
> Starting kernel ...
>
> Perhaps something to do with how my DDR is not at 0x0 -> 256MiB but
> 0x80000000 -> 256MiB ?


Tom, which board is that?

These 5 patches just on top of v2013.07-rc2, the panda (non es) (board
file) works, but Wand (device tree) is still locking up for me...

Panda (Board file boot)

load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
run mmcargs
bootz ${loadaddr}

Panda # load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
reading zImage
3413152 bytes read in 161 ms (20.2 MiB/s)
Panda # run mmcargs
Panda # bootz ${loadaddr}
Kernel image @ 0x82000000 [ 0x000000 - 0x3414a0 ]

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
[    0.000000] Booting Linux on physical CPU 0
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu

Wandboard (device tree boot)

load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file}
run mmcargs
bootz ${loadaddr} - ${fdt_addr}

Hit any key to stop autoboot:  0
=> load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
3464448 bytes read in 249 ms (13.3 MiB/s)
=> load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file}
23571 bytes read in 253 ms (90.8 KiB/s)
=> run mmcargs
=> bootz ${loadaddr} - ${fdt_addr}
Kernel image @ 0x12000000 [ 0x000000 - 0x34dd00 ]

Starting kernel ...
<lockup>

Regards,
Tom Rini - July 8, 2013, 2:22 p.m.
On Mon, Jul 08, 2013 at 09:17:10AM -0500, Robert Nelson wrote:

> On Mon, Jul 8, 2013 at 9:13 AM, Tom Rini <trini@ti.com> wrote:
> > On Thu, Jul 04, 2013 at 01:26:11PM -0700, Simon Glass wrote:
> >> In the recent bootm refactor, the PREP stage was missing in the bootz
> >> command. This causes unpredictable behaviour.
> >>
> >> The use of a local variable means that the reset of cmd_bootm.c does not
> >> in fact use the same image structure, so remove this.
> >>
> >> Also manually set the OS type to Linux, since this is the only possibility
> >> at present, and we need to select the right boot function.
> >>
> >> Signed-off-by: Simon Glass <sjg@chromium.org>
> >
> > With the whole series applied, I still see a hang at:
> > Kernel image @ 0x80200000 [ 0x000000 - 0x3d44a0 ]
> >
> > Starting kernel ...
> >
> > Perhaps something to do with how my DDR is not at 0x0 -> 256MiB but
> > 0x80000000 -> 256MiB ?
> 
> 
> Tom, which board is that?
> 
> These 5 patches just on top of v2013.07-rc2, the panda (non es) (board
> file) works, but Wand (device tree) is still locking up for me...
> 
> Panda (Board file boot)
> 
> load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
> run mmcargs
> bootz ${loadaddr}

Ah-ha!  It's an appended dtb vs not problem now.  I can boot my
beagelbone with with an appended dtb and bootz, but can't with separate.
Tom Rini - July 9, 2013, 5:01 p.m.
On Mon, Jul 08, 2013 at 10:22:13AM -0400, Tom Rini wrote:
> On Mon, Jul 08, 2013 at 09:17:10AM -0500, Robert Nelson wrote:
> 
> > On Mon, Jul 8, 2013 at 9:13 AM, Tom Rini <trini@ti.com> wrote:
> > > On Thu, Jul 04, 2013 at 01:26:11PM -0700, Simon Glass wrote:
> > >> In the recent bootm refactor, the PREP stage was missing in the bootz
> > >> command. This causes unpredictable behaviour.
> > >>
> > >> The use of a local variable means that the reset of cmd_bootm.c does not
> > >> in fact use the same image structure, so remove this.
> > >>
> > >> Also manually set the OS type to Linux, since this is the only possibility
> > >> at present, and we need to select the right boot function.
> > >>
> > >> Signed-off-by: Simon Glass <sjg@chromium.org>
> > >
> > > With the whole series applied, I still see a hang at:
> > > Kernel image @ 0x80200000 [ 0x000000 - 0x3d44a0 ]
> > >
> > > Starting kernel ...
> > >
> > > Perhaps something to do with how my DDR is not at 0x0 -> 256MiB but
> > > 0x80000000 -> 256MiB ?
> > 
> > 
> > Tom, which board is that?
> > 
> > These 5 patches just on top of v2013.07-rc2, the panda (non es) (board
> > file) works, but Wand (device tree) is still locking up for me...
> > 
> > Panda (Board file boot)
> > 
> > load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
> > run mmcargs
> > bootz ${loadaddr}
> 
> Ah-ha!  It's an appended dtb vs not problem now.  I can boot my
> beagelbone with with an appended dtb and bootz, but can't with separate.

OK, the BOOTM_STATE_FINDOTHER state code isn't working since we don't
have the rest of the header bits that the code checks for set.  I've
taken a few stabs at reworking things, but it's not working yet.  Simon,
do you have any ideas here?  I'm starting to wonder if we don't need to
revert things afterall and sort this out post release.
Simon Glass - July 9, 2013, 7 p.m.
Hi Tom,

On Tue, Jul 9, 2013 at 10:01 AM, Tom Rini <trini@ti.com> wrote:

> On Mon, Jul 08, 2013 at 10:22:13AM -0400, Tom Rini wrote:
> > On Mon, Jul 08, 2013 at 09:17:10AM -0500, Robert Nelson wrote:
> >
> > > On Mon, Jul 8, 2013 at 9:13 AM, Tom Rini <trini@ti.com> wrote:
> > > > On Thu, Jul 04, 2013 at 01:26:11PM -0700, Simon Glass wrote:
> > > >> In the recent bootm refactor, the PREP stage was missing in the
> bootz
> > > >> command. This causes unpredictable behaviour.
> > > >>
> > > >> The use of a local variable means that the reset of cmd_bootm.c
> does not
> > > >> in fact use the same image structure, so remove this.
> > > >>
> > > >> Also manually set the OS type to Linux, since this is the only
> possibility
> > > >> at present, and we need to select the right boot function.
> > > >>
> > > >> Signed-off-by: Simon Glass <sjg@chromium.org>
> > > >
> > > > With the whole series applied, I still see a hang at:
> > > > Kernel image @ 0x80200000 [ 0x000000 - 0x3d44a0 ]
> > > >
> > > > Starting kernel ...
> > > >
> > > > Perhaps something to do with how my DDR is not at 0x0 -> 256MiB but
> > > > 0x80000000 -> 256MiB ?
> > >
> > >
> > > Tom, which board is that?
> > >
> > > These 5 patches just on top of v2013.07-rc2, the panda (non es) (board
> > > file) works, but Wand (device tree) is still locking up for me...
> > >
> > > Panda (Board file boot)
> > >
> > > load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
> > > run mmcargs
> > > bootz ${loadaddr}
> >
> > Ah-ha!  It's an appended dtb vs not problem now.  I can boot my
> > beagelbone with with an appended dtb and bootz, but can't with separate.
>
> OK, the BOOTM_STATE_FINDOTHER state code isn't working since we don't
> have the rest of the header bits that the code checks for set.  I've
> taken a few stabs at reworking things, but it's not working yet.  Simon,
> do you have any ideas here?  I'm starting to wonder if we don't need to
> revert things afterall and sort this out post release.
>
>
Yes time is running short. I did post two reverts - I wonder if they are
effective for this problem?

Is the appended dtb with bootz the only problem remaining as far as we
know? If so then perhaps we are close.

I will see if I can get a Beaglebone today or failing that I should be able
to try bootz with appeneded dtb on another ARM board.

Regards,
Simon


> --
> Tom
>
Tom Rini - July 9, 2013, 7:05 p.m.
On Tue, Jul 09, 2013 at 12:00:00PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Tue, Jul 9, 2013 at 10:01 AM, Tom Rini <trini@ti.com> wrote:
> 
> > On Mon, Jul 08, 2013 at 10:22:13AM -0400, Tom Rini wrote:
> > > On Mon, Jul 08, 2013 at 09:17:10AM -0500, Robert Nelson wrote:
> > >
> > > > On Mon, Jul 8, 2013 at 9:13 AM, Tom Rini <trini@ti.com> wrote:
> > > > > On Thu, Jul 04, 2013 at 01:26:11PM -0700, Simon Glass wrote:
> > > > >> In the recent bootm refactor, the PREP stage was missing in the
> > bootz
> > > > >> command. This causes unpredictable behaviour.
> > > > >>
> > > > >> The use of a local variable means that the reset of cmd_bootm.c
> > does not
> > > > >> in fact use the same image structure, so remove this.
> > > > >>
> > > > >> Also manually set the OS type to Linux, since this is the only
> > possibility
> > > > >> at present, and we need to select the right boot function.
> > > > >>
> > > > >> Signed-off-by: Simon Glass <sjg@chromium.org>
> > > > >
> > > > > With the whole series applied, I still see a hang at:
> > > > > Kernel image @ 0x80200000 [ 0x000000 - 0x3d44a0 ]
> > > > >
> > > > > Starting kernel ...
> > > > >
> > > > > Perhaps something to do with how my DDR is not at 0x0 -> 256MiB but
> > > > > 0x80000000 -> 256MiB ?
> > > >
> > > >
> > > > Tom, which board is that?
> > > >
> > > > These 5 patches just on top of v2013.07-rc2, the panda (non es) (board
> > > > file) works, but Wand (device tree) is still locking up for me...
> > > >
> > > > Panda (Board file boot)
> > > >
> > > > load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
> > > > run mmcargs
> > > > bootz ${loadaddr}
> > >
> > > Ah-ha!  It's an appended dtb vs not problem now.  I can boot my
> > > beagelbone with with an appended dtb and bootz, but can't with separate.
> >
> > OK, the BOOTM_STATE_FINDOTHER state code isn't working since we don't
> > have the rest of the header bits that the code checks for set.  I've
> > taken a few stabs at reworking things, but it's not working yet.  Simon,
> > do you have any ideas here?  I'm starting to wonder if we don't need to
> > revert things afterall and sort this out post release.
> >
> >
> Yes time is running short. I did post two reverts - I wonder if they are
> effective for this problem?
> 
> Is the appended dtb with bootz the only problem remaining as far as we
> know? If so then perhaps we are close.
> 
> I will see if I can get a Beaglebone today or failing that I should be able
> to try bootz with appeneded dtb on another ARM board.

I've got a fix locally now, and I'm working on cleaning it up further.
The problem is that BOOTM_STATE_FINDOTHER would never work since we
aren't the "right" image types, so passed ramdisk and/or dtb didn't
work.  Another problem was that bootz was never consuming 'bootz', but
this was OK before.  I'll post a patch shortly.

My biggest worry right now is, what might show up broken next?  Anyone
out there easily able to boot a netbsd kernel or something?
robertcnelson@gmail.com - July 9, 2013, 7:05 p.m.
On Tue, Jul 9, 2013 at 2:00 PM, Simon Glass <sjg@chromium.org> wrote:
> Hi Tom,
>
> On Tue, Jul 9, 2013 at 10:01 AM, Tom Rini <trini@ti.com> wrote:
>>
>> On Mon, Jul 08, 2013 at 10:22:13AM -0400, Tom Rini wrote:
>> > On Mon, Jul 08, 2013 at 09:17:10AM -0500, Robert Nelson wrote:
>> >
>> > > On Mon, Jul 8, 2013 at 9:13 AM, Tom Rini <trini@ti.com> wrote:
>> > > > On Thu, Jul 04, 2013 at 01:26:11PM -0700, Simon Glass wrote:
>> > > >> In the recent bootm refactor, the PREP stage was missing in the
>> > > >> bootz
>> > > >> command. This causes unpredictable behaviour.
>> > > >>
>> > > >> The use of a local variable means that the reset of cmd_bootm.c
>> > > >> does not
>> > > >> in fact use the same image structure, so remove this.
>> > > >>
>> > > >> Also manually set the OS type to Linux, since this is the only
>> > > >> possibility
>> > > >> at present, and we need to select the right boot function.
>> > > >>
>> > > >> Signed-off-by: Simon Glass <sjg@chromium.org>
>> > > >
>> > > > With the whole series applied, I still see a hang at:
>> > > > Kernel image @ 0x80200000 [ 0x000000 - 0x3d44a0 ]
>> > > >
>> > > > Starting kernel ...
>> > > >
>> > > > Perhaps something to do with how my DDR is not at 0x0 -> 256MiB but
>> > > > 0x80000000 -> 256MiB ?
>> > >
>> > >
>> > > Tom, which board is that?
>> > >
>> > > These 5 patches just on top of v2013.07-rc2, the panda (non es) (board
>> > > file) works, but Wand (device tree) is still locking up for me...
>> > >
>> > > Panda (Board file boot)
>> > >
>> > > load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
>> > > run mmcargs
>> > > bootz ${loadaddr}
>> >
>> > Ah-ha!  It's an appended dtb vs not problem now.  I can boot my
>> > beagelbone with with an appended dtb and bootz, but can't with separate.
>>
>> OK, the BOOTM_STATE_FINDOTHER state code isn't working since we don't
>> have the rest of the header bits that the code checks for set.  I've
>> taken a few stabs at reworking things, but it's not working yet.  Simon,
>> do you have any ideas here?  I'm starting to wonder if we don't need to
>> revert things afterall and sort this out post release.
>>
>
> Yes time is running short. I did post two reverts - I wonder if they are
> effective for this problem?
>
> Is the appended dtb with bootz the only problem remaining as far as we know?
> If so then perhaps we are close.

Close.. It's the 'non appended dtb case'...

bootz ${loadaddr} - ${fdt_addr}

It's almost as if bootz doesn't have the location of the dtb binary in memory...

> I will see if I can get a Beaglebone today or failing that I should be able
> to try bootz with appeneded dtb on another ARM board.

Regards,
Simon Glass - July 9, 2013, 8:04 p.m.
Hi Tom,

On Tue, Jul 9, 2013 at 12:05 PM, Tom Rini <trini@ti.com> wrote:

> On Tue, Jul 09, 2013 at 12:00:00PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Tue, Jul 9, 2013 at 10:01 AM, Tom Rini <trini@ti.com> wrote:
> >
> > > On Mon, Jul 08, 2013 at 10:22:13AM -0400, Tom Rini wrote:
> > > > On Mon, Jul 08, 2013 at 09:17:10AM -0500, Robert Nelson wrote:
> > > >
> > > > > On Mon, Jul 8, 2013 at 9:13 AM, Tom Rini <trini@ti.com> wrote:
> > > > > > On Thu, Jul 04, 2013 at 01:26:11PM -0700, Simon Glass wrote:
> > > > > >> In the recent bootm refactor, the PREP stage was missing in the
> > > bootz
> > > > > >> command. This causes unpredictable behaviour.
> > > > > >>
> > > > > >> The use of a local variable means that the reset of cmd_bootm.c
> > > does not
> > > > > >> in fact use the same image structure, so remove this.
> > > > > >>
> > > > > >> Also manually set the OS type to Linux, since this is the only
> > > possibility
> > > > > >> at present, and we need to select the right boot function.
> > > > > >>
> > > > > >> Signed-off-by: Simon Glass <sjg@chromium.org>
> > > > > >
> > > > > > With the whole series applied, I still see a hang at:
> > > > > > Kernel image @ 0x80200000 [ 0x000000 - 0x3d44a0 ]
> > > > > >
> > > > > > Starting kernel ...
> > > > > >
> > > > > > Perhaps something to do with how my DDR is not at 0x0 -> 256MiB
> but
> > > > > > 0x80000000 -> 256MiB ?
> > > > >
> > > > >
> > > > > Tom, which board is that?
> > > > >
> > > > > These 5 patches just on top of v2013.07-rc2, the panda (non es)
> (board
> > > > > file) works, but Wand (device tree) is still locking up for me...
> > > > >
> > > > > Panda (Board file boot)
> > > > >
> > > > > load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
> > > > > run mmcargs
> > > > > bootz ${loadaddr}
> > > >
> > > > Ah-ha!  It's an appended dtb vs not problem now.  I can boot my
> > > > beagelbone with with an appended dtb and bootz, but can't with
> separate.
> > >
> > > OK, the BOOTM_STATE_FINDOTHER state code isn't working since we don't
> > > have the rest of the header bits that the code checks for set.  I've
> > > taken a few stabs at reworking things, but it's not working yet.
>  Simon,
> > > do you have any ideas here?  I'm starting to wonder if we don't need to
> > > revert things afterall and sort this out post release.
> > >
> > >
> > Yes time is running short. I did post two reverts - I wonder if they are
> > effective for this problem?
> >
> > Is the appended dtb with bootz the only problem remaining as far as we
> > know? If so then perhaps we are close.
> >
> > I will see if I can get a Beaglebone today or failing that I should be
> able
> > to try bootz with appeneded dtb on another ARM board.
>
> I've got a fix locally now, and I'm working on cleaning it up further.
> The problem is that BOOTM_STATE_FINDOTHER would never work since we
> aren't the "right" image types, so passed ramdisk and/or dtb didn't
> work.  Another problem was that bootz was never consuming 'bootz', but
> this was OK before.  I'll post a patch shortly.
>

OK great, thanks for looking at this.  I wonder if we can collect a set of
different use cases for bootz as a basis for test cases?


>
> My biggest worry right now is, what might show up broken next?  Anyone
> out there easily able to boot a netbsd kernel or something?
>

Yes, I am not really comfortable with this. I will see if I can write some
sandbox tests for the other image types today and post my results. I guess
this bootm code has built up over a long time and it is hard to know all
the ways it is used.

Regards,
Simon


> --
> Tom
>
Tom Rini - July 9, 2013, 9:19 p.m.
On Tue, Jul 09, 2013 at 01:04:58PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Tue, Jul 9, 2013 at 12:05 PM, Tom Rini <trini@ti.com> wrote:
> 
> > On Tue, Jul 09, 2013 at 12:00:00PM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Tue, Jul 9, 2013 at 10:01 AM, Tom Rini <trini@ti.com> wrote:
> > >
> > > > On Mon, Jul 08, 2013 at 10:22:13AM -0400, Tom Rini wrote:
> > > > > On Mon, Jul 08, 2013 at 09:17:10AM -0500, Robert Nelson wrote:
> > > > >
> > > > > > On Mon, Jul 8, 2013 at 9:13 AM, Tom Rini <trini@ti.com> wrote:
> > > > > > > On Thu, Jul 04, 2013 at 01:26:11PM -0700, Simon Glass wrote:
> > > > > > >> In the recent bootm refactor, the PREP stage was missing in the
> > > > bootz
> > > > > > >> command. This causes unpredictable behaviour.
> > > > > > >>
> > > > > > >> The use of a local variable means that the reset of cmd_bootm.c
> > > > does not
> > > > > > >> in fact use the same image structure, so remove this.
> > > > > > >>
> > > > > > >> Also manually set the OS type to Linux, since this is the only
> > > > possibility
> > > > > > >> at present, and we need to select the right boot function.
> > > > > > >>
> > > > > > >> Signed-off-by: Simon Glass <sjg@chromium.org>
> > > > > > >
> > > > > > > With the whole series applied, I still see a hang at:
> > > > > > > Kernel image @ 0x80200000 [ 0x000000 - 0x3d44a0 ]
> > > > > > >
> > > > > > > Starting kernel ...
> > > > > > >
> > > > > > > Perhaps something to do with how my DDR is not at 0x0 -> 256MiB
> > but
> > > > > > > 0x80000000 -> 256MiB ?
> > > > > >
> > > > > >
> > > > > > Tom, which board is that?
> > > > > >
> > > > > > These 5 patches just on top of v2013.07-rc2, the panda (non es)
> > (board
> > > > > > file) works, but Wand (device tree) is still locking up for me...
> > > > > >
> > > > > > Panda (Board file boot)
> > > > > >
> > > > > > load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
> > > > > > run mmcargs
> > > > > > bootz ${loadaddr}
> > > > >
> > > > > Ah-ha!  It's an appended dtb vs not problem now.  I can boot my
> > > > > beagelbone with with an appended dtb and bootz, but can't with
> > separate.
> > > >
> > > > OK, the BOOTM_STATE_FINDOTHER state code isn't working since we don't
> > > > have the rest of the header bits that the code checks for set.  I've
> > > > taken a few stabs at reworking things, but it's not working yet.
> >  Simon,
> > > > do you have any ideas here?  I'm starting to wonder if we don't need to
> > > > revert things afterall and sort this out post release.
> > > >
> > > >
> > > Yes time is running short. I did post two reverts - I wonder if they are
> > > effective for this problem?
> > >
> > > Is the appended dtb with bootz the only problem remaining as far as we
> > > know? If so then perhaps we are close.
> > >
> > > I will see if I can get a Beaglebone today or failing that I should be
> > able
> > > to try bootz with appeneded dtb on another ARM board.
> >
> > I've got a fix locally now, and I'm working on cleaning it up further.
> > The problem is that BOOTM_STATE_FINDOTHER would never work since we
> > aren't the "right" image types, so passed ramdisk and/or dtb didn't
> > work.  Another problem was that bootz was never consuming 'bootz', but
> > this was OK before.  I'll post a patch shortly.
>
> 
> OK great, thanks for looking at this.  I wonder if we can collect a set of
> different use cases for bootz as a basis for test cases?

Well, what happens on sandbox when you try and boot a kernel? :)  bootz
is any of:
kernel, kernel+ramdisk, kernel+ramdisk+fdt, kernel+fdt.

> > My biggest worry right now is, what might show up broken next?  Anyone
> > out there easily able to boot a netbsd kernel or something?
> 
> Yes, I am not really comfortable with this. I will see if I can write some
> sandbox tests for the other image types today and post my results. I guess
> this bootm code has built up over a long time and it is hard to know all
> the ways it is used.

Important, but I really want to see real-world booting in a case or two.
Unfortunately I don't have any ARM boards that work out of the box with
NetBSD.
robertcnelson@gmail.com - July 9, 2013, 9:24 p.m.
On Tue, Jul 9, 2013 at 4:19 PM, Tom Rini <trini@ti.com> wrote:
> On Tue, Jul 09, 2013 at 01:04:58PM -0700, Simon Glass wrote:
>> Hi Tom,
>>
>> On Tue, Jul 9, 2013 at 12:05 PM, Tom Rini <trini@ti.com> wrote:
>>
>> > On Tue, Jul 09, 2013 at 12:00:00PM -0700, Simon Glass wrote:
>> > > Hi Tom,
>> > >
>> > > On Tue, Jul 9, 2013 at 10:01 AM, Tom Rini <trini@ti.com> wrote:
>> > >
>> > > > On Mon, Jul 08, 2013 at 10:22:13AM -0400, Tom Rini wrote:
>> > > > > On Mon, Jul 08, 2013 at 09:17:10AM -0500, Robert Nelson wrote:
>> > > > >
>> > > > > > On Mon, Jul 8, 2013 at 9:13 AM, Tom Rini <trini@ti.com> wrote:
>> > > > > > > On Thu, Jul 04, 2013 at 01:26:11PM -0700, Simon Glass wrote:
>> > > > > > >> In the recent bootm refactor, the PREP stage was missing in the
>> > > > bootz
>> > > > > > >> command. This causes unpredictable behaviour.
>> > > > > > >>
>> > > > > > >> The use of a local variable means that the reset of cmd_bootm.c
>> > > > does not
>> > > > > > >> in fact use the same image structure, so remove this.
>> > > > > > >>
>> > > > > > >> Also manually set the OS type to Linux, since this is the only
>> > > > possibility
>> > > > > > >> at present, and we need to select the right boot function.
>> > > > > > >>
>> > > > > > >> Signed-off-by: Simon Glass <sjg@chromium.org>
>> > > > > > >
>> > > > > > > With the whole series applied, I still see a hang at:
>> > > > > > > Kernel image @ 0x80200000 [ 0x000000 - 0x3d44a0 ]
>> > > > > > >
>> > > > > > > Starting kernel ...
>> > > > > > >
>> > > > > > > Perhaps something to do with how my DDR is not at 0x0 -> 256MiB
>> > but
>> > > > > > > 0x80000000 -> 256MiB ?
>> > > > > >
>> > > > > >
>> > > > > > Tom, which board is that?
>> > > > > >
>> > > > > > These 5 patches just on top of v2013.07-rc2, the panda (non es)
>> > (board
>> > > > > > file) works, but Wand (device tree) is still locking up for me...
>> > > > > >
>> > > > > > Panda (Board file boot)
>> > > > > >
>> > > > > > load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
>> > > > > > run mmcargs
>> > > > > > bootz ${loadaddr}
>> > > > >
>> > > > > Ah-ha!  It's an appended dtb vs not problem now.  I can boot my
>> > > > > beagelbone with with an appended dtb and bootz, but can't with
>> > separate.
>> > > >
>> > > > OK, the BOOTM_STATE_FINDOTHER state code isn't working since we don't
>> > > > have the rest of the header bits that the code checks for set.  I've
>> > > > taken a few stabs at reworking things, but it's not working yet.
>> >  Simon,
>> > > > do you have any ideas here?  I'm starting to wonder if we don't need to
>> > > > revert things afterall and sort this out post release.
>> > > >
>> > > >
>> > > Yes time is running short. I did post two reverts - I wonder if they are
>> > > effective for this problem?
>> > >
>> > > Is the appended dtb with bootz the only problem remaining as far as we
>> > > know? If so then perhaps we are close.
>> > >
>> > > I will see if I can get a Beaglebone today or failing that I should be
>> > able
>> > > to try bootz with appeneded dtb on another ARM board.
>> >
>> > I've got a fix locally now, and I'm working on cleaning it up further.
>> > The problem is that BOOTM_STATE_FINDOTHER would never work since we
>> > aren't the "right" image types, so passed ramdisk and/or dtb didn't
>> > work.  Another problem was that bootz was never consuming 'bootz', but
>> > this was OK before.  I'll post a patch shortly.
>>
>>
>> OK great, thanks for looking at this.  I wonder if we can collect a set of
>> different use cases for bootz as a basis for test cases?
>
> Well, what happens on sandbox when you try and boot a kernel? :)  bootz
> is any of:
> kernel, kernel+ramdisk, kernel+ramdisk+fdt, kernel+fdt.
>
>> > My biggest worry right now is, what might show up broken next?  Anyone
>> > out there easily able to boot a netbsd kernel or something?
>>
>> Yes, I am not really comfortable with this. I will see if I can write some
>> sandbox tests for the other image types today and post my results. I guess
>> this bootm code has built up over a long time and it is hard to know all
>> the ways it is used.
>
> Important, but I really want to see real-world booting in a case or two.
> Unfortunately I don't have any ARM boards that work out of the box with
> NetBSD.

There 'seems' to be a pre-built freebsd arm port...

https://wiki.freebsd.org/FreeBSD/arm/BeagleBone

Regards,
robertcnelson@gmail.com - July 9, 2013, 9:39 p.m.
>> Important, but I really want to see real-world booting in a case or two.
>> Unfortunately I don't have any ARM boards that work out of the box with
>> NetBSD.
>
> There 'seems' to be a pre-built freebsd arm port...
>
> https://wiki.freebsd.org/FreeBSD/arm/BeagleBone

NM.. they are using the 'bootelf' command..

https://github.com/kientzle/crochet-freebsd/blob/master/board/BeagleBone/files/uboot_patch05.patch#L108

Regards,
Simon Glass - July 9, 2013, 9:44 p.m.
Hi Tom,

On Tue, Jul 9, 2013 at 2:19 PM, Tom Rini <trini@ti.com> wrote:

> On Tue, Jul 09, 2013 at 01:04:58PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Tue, Jul 9, 2013 at 12:05 PM, Tom Rini <trini@ti.com> wrote:
> >
> > > On Tue, Jul 09, 2013 at 12:00:00PM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Tue, Jul 9, 2013 at 10:01 AM, Tom Rini <trini@ti.com> wrote:
> > > >
> > > > > On Mon, Jul 08, 2013 at 10:22:13AM -0400, Tom Rini wrote:
> > > > > > On Mon, Jul 08, 2013 at 09:17:10AM -0500, Robert Nelson wrote:
> > > > > >
> > > > > > > On Mon, Jul 8, 2013 at 9:13 AM, Tom Rini <trini@ti.com> wrote:
> > > > > > > > On Thu, Jul 04, 2013 at 01:26:11PM -0700, Simon Glass wrote:
> > > > > > > >> In the recent bootm refactor, the PREP stage was missing in
> the
> > > > > bootz
> > > > > > > >> command. This causes unpredictable behaviour.
> > > > > > > >>
> > > > > > > >> The use of a local variable means that the reset of
> cmd_bootm.c
> > > > > does not
> > > > > > > >> in fact use the same image structure, so remove this.
> > > > > > > >>
> > > > > > > >> Also manually set the OS type to Linux, since this is the
> only
> > > > > possibility
> > > > > > > >> at present, and we need to select the right boot function.
> > > > > > > >>
> > > > > > > >> Signed-off-by: Simon Glass <sjg@chromium.org>
> > > > > > > >
> > > > > > > > With the whole series applied, I still see a hang at:
> > > > > > > > Kernel image @ 0x80200000 [ 0x000000 - 0x3d44a0 ]
> > > > > > > >
> > > > > > > > Starting kernel ...
> > > > > > > >
> > > > > > > > Perhaps something to do with how my DDR is not at 0x0 ->
> 256MiB
> > > but
> > > > > > > > 0x80000000 -> 256MiB ?
> > > > > > >
> > > > > > >
> > > > > > > Tom, which board is that?
> > > > > > >
> > > > > > > These 5 patches just on top of v2013.07-rc2, the panda (non es)
> > > (board
> > > > > > > file) works, but Wand (device tree) is still locking up for
> me...
> > > > > > >
> > > > > > > Panda (Board file boot)
> > > > > > >
> > > > > > > load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
> > > > > > > run mmcargs
> > > > > > > bootz ${loadaddr}
> > > > > >
> > > > > > Ah-ha!  It's an appended dtb vs not problem now.  I can boot my
> > > > > > beagelbone with with an appended dtb and bootz, but can't with
> > > separate.
> > > > >
> > > > > OK, the BOOTM_STATE_FINDOTHER state code isn't working since we
> don't
> > > > > have the rest of the header bits that the code checks for set.
>  I've
> > > > > taken a few stabs at reworking things, but it's not working yet.
> > >  Simon,
> > > > > do you have any ideas here?  I'm starting to wonder if we don't
> need to
> > > > > revert things afterall and sort this out post release.
> > > > >
> > > > >
> > > > Yes time is running short. I did post two reverts - I wonder if they
> are
> > > > effective for this problem?
> > > >
> > > > Is the appended dtb with bootz the only problem remaining as far as
> we
> > > > know? If so then perhaps we are close.
> > > >
> > > > I will see if I can get a Beaglebone today or failing that I should
> be
> > > able
> > > > to try bootz with appeneded dtb on another ARM board.
> > >
> > > I've got a fix locally now, and I'm working on cleaning it up further.
> > > The problem is that BOOTM_STATE_FINDOTHER would never work since we
> > > aren't the "right" image types, so passed ramdisk and/or dtb didn't
> > > work.  Another problem was that bootz was never consuming 'bootz', but
> > > this was OK before.  I'll post a patch shortly.
> >
> >
> > OK great, thanks for looking at this.  I wonder if we can collect a set
> of
> > different use cases for bootz as a basis for test cases?
>
> Well, what happens on sandbox when you try and boot a kernel? :)  bootz
> is any of:
> kernel, kernel+ramdisk, kernel+ramdisk+fdt, kernel+fdt.
>

Yes certainly there are limitations, but the test I have there so far does
check that all the data appears in the correct place in memory. That seems
to me most of the battle with bootm.


>
> > > My biggest worry right now is, what might show up broken next?  Anyone
> > > out there easily able to boot a netbsd kernel or something?
> >
> > Yes, I am not really comfortable with this. I will see if I can write
> some
> > sandbox tests for the other image types today and post my results. I
> guess
> > this bootm code has built up over a long time and it is hard to know all
> > the ways it is used.
>
> Important, but I really want to see real-world booting in a case or two.
> Unfortunately I don't have any ARM boards that work out of the box with
> NetBSD.
>

Me neither, unfortunately.

Regards,
Simon


>
> --
> Tom
>
Sughosh Ganu - July 10, 2013, 9:51 a.m.
hi Tom,

On Tue Jul 09, 2013 at 05:19:32PM -0400, Tom Rini wrote:

<snip>

> > Yes, I am not really comfortable with this. I will see if I can write some
> > sandbox tests for the other image types today and post my results. I guess
> > this bootm code has built up over a long time and it is hard to know all
> > the ways it is used.
> 
> Important, but I really want to see real-world booting in a case or two.
> Unfortunately I don't have any ARM boards that work out of the box with
> NetBSD.

I have netbsd running on hawkboard, but i do not boot it using the
bootm command, but use the go command instead. I will try to build a
netbsd image with the u-boot header and give it a try with bootm. Need
a day or two to check this out though.

-sughosh
Simon Glass - July 10, 2013, 10:08 a.m.
Hi Sughosh,

On Wed, Jul 10, 2013 at 2:51 AM, Sughosh Ganu <urwithsughosh@gmail.com>wrote:

> hi Tom,
>
> On Tue Jul 09, 2013 at 05:19:32PM -0400, Tom Rini wrote:
>
> <snip>
>
> > > Yes, I am not really comfortable with this. I will see if I can write
> some
> > > sandbox tests for the other image types today and post my results. I
> guess
> > > this bootm code has built up over a long time and it is hard to know
> all
> > > the ways it is used.
> >
> > Important, but I really want to see real-world booting in a case or two.
> > Unfortunately I don't have any ARM boards that work out of the box with
> > NetBSD.
>
> I have netbsd running on hawkboard, but i do not boot it using the
> bootm command, but use the go command instead. I will try to build a
> netbsd image with the u-boot header and give it a try with bootm. Need
> a day or two to check this out though.
>

Thanks, much appreciated.

Regards,
Simon
Simon Glass - July 10, 2013, 10:13 a.m.
Hi Tom,


On Tue, Jul 9, 2013 at 2:19 PM, Tom Rini <trini@ti.com> wrote:

> On Tue, Jul 09, 2013 at 01:04:58PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Tue, Jul 9, 2013 at 12:05 PM, Tom Rini <trini@ti.com> wrote:
> >
> > > On Tue, Jul 09, 2013 at 12:00:00PM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Tue, Jul 9, 2013 at 10:01 AM, Tom Rini <trini@ti.com> wrote:
> > > >
> > > > > On Mon, Jul 08, 2013 at 10:22:13AM -0400, Tom Rini wrote:
> > > > > > On Mon, Jul 08, 2013 at 09:17:10AM -0500, Robert Nelson wrote:
> > > > > >
> > > > > > > On Mon, Jul 8, 2013 at 9:13 AM, Tom Rini <trini@ti.com> wrote:
> > > > > > > > On Thu, Jul 04, 2013 at 01:26:11PM -0700, Simon Glass wrote:
> > > > > > > >> In the recent bootm refactor, the PREP stage was missing in
> the
> > > > > bootz
> > > > > > > >> command. This causes unpredictable behaviour.
> > > > > > > >>
> > > > > > > >> The use of a local variable means that the reset of
> cmd_bootm.c
> > > > > does not
> > > > > > > >> in fact use the same image structure, so remove this.
> > > > > > > >>
> > > > > > > >> Also manually set the OS type to Linux, since this is the
> only
> > > > > possibility
> > > > > > > >> at present, and we need to select the right boot function.
> > > > > > > >>
> > > > > > > >> Signed-off-by: Simon Glass <sjg@chromium.org>
> > > > > > > >
> > > > > > > > With the whole series applied, I still see a hang at:
> > > > > > > > Kernel image @ 0x80200000 [ 0x000000 - 0x3d44a0 ]
> > > > > > > >
> > > > > > > > Starting kernel ...
> > > > > > > >
> > > > > > > > Perhaps something to do with how my DDR is not at 0x0 ->
> 256MiB
> > > but
> > > > > > > > 0x80000000 -> 256MiB ?
> > > > > > >
> > > > > > >
> > > > > > > Tom, which board is that?
> > > > > > >
> > > > > > > These 5 patches just on top of v2013.07-rc2, the panda (non es)
> > > (board
> > > > > > > file) works, but Wand (device tree) is still locking up for
> me...
> > > > > > >
> > > > > > > Panda (Board file boot)
> > > > > > >
> > > > > > > load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
> > > > > > > run mmcargs
> > > > > > > bootz ${loadaddr}
> > > > > >
> > > > > > Ah-ha!  It's an appended dtb vs not problem now.  I can boot my
> > > > > > beagelbone with with an appended dtb and bootz, but can't with
> > > separate.
> > > > >
> > > > > OK, the BOOTM_STATE_FINDOTHER state code isn't working since we
> don't
> > > > > have the rest of the header bits that the code checks for set.
>  I've
> > > > > taken a few stabs at reworking things, but it's not working yet.
> > >  Simon,
> > > > > do you have any ideas here?  I'm starting to wonder if we don't
> need to
> > > > > revert things afterall and sort this out post release.
> > > > >
> > > > >
> > > > Yes time is running short. I did post two reverts - I wonder if they
> are
> > > > effective for this problem?
> > > >
> > > > Is the appended dtb with bootz the only problem remaining as far as
> we
> > > > know? If so then perhaps we are close.
> > > >
> > > > I will see if I can get a Beaglebone today or failing that I should
> be
> > > able
> > > > to try bootz with appeneded dtb on another ARM board.
> > >
> > > I've got a fix locally now, and I'm working on cleaning it up further.
> > > The problem is that BOOTM_STATE_FINDOTHER would never work since we
> > > aren't the "right" image types, so passed ramdisk and/or dtb didn't
> > > work.  Another problem was that bootz was never consuming 'bootz', but
> > > this was OK before.  I'll post a patch shortly.
> >
> >
> > OK great, thanks for looking at this.  I wonder if we can collect a set
> of
> > different use cases for bootz as a basis for test cases?
>
> Well, what happens on sandbox when you try and boot a kernel? :)  bootz
> is any of:
> kernel, kernel+ramdisk, kernel+ramdisk+fdt, kernel+fdt.
>

The test currently checks that the kernel/ramdisk/fdt appear in the right
place, and that U-Boot reports that it is booting the kernel from the right
address. That actually should cover bugs where things don't end up in the
right place, or are corrupted. Of course there are limitations with
automated tests like this, but I still think it will make it easier for the
next person who takes on a clean-up in this area of U-Boot.


>
> > > My biggest worry right now is, what might show up broken next?  Anyone
> > > out there easily able to boot a netbsd kernel or something?
> >
> > Yes, I am not really comfortable with this. I will see if I can write
> some
> > sandbox tests for the other image types today and post my results. I
> guess
> > this bootm code has built up over a long time and it is hard to know all
> > the ways it is used.
>
> Important, but I really want to see real-world booting in a case or two.
> Unfortunately I don't have any ARM boards that work out of the box with
> NetBSD.
>

Yes, me too. But in the meantime I have tried to do what I can here - spent
many happy hours reviewing the code carefully and writing a 'sandbox' test
for the following OSes:

['netbsd', 'lynxos', 'rtems', 'ose', 'plan9', 'vxworks', 'qnx', 'integrity']

I found that most of them have the same problem fixed by Andreas/Tom's
commit 2cb0e55, so I will prepare a patch for this.

Additionally, the vxworks arguments are incorrect (argc is one less than
expected). I will prepare a patch for this also.

Other than that, everything looks correct so far as I can tell, up to the
point where U-Boot actually jumps to the OS.

I will tidy up my tests and submit these also at some point. Coverage now
includes FIT and legacy images, with bootm commands and subcommands. For
the record there is still a lot of test code missing:


Regards,
Simon
Simon Glass - July 10, 2013, 10:15 a.m.
[snip]

I will tidy up my tests and submit these also at some point. Coverage now
> includes FIT and legacy images, with bootm commands and subcommands. For
> the record there is still a lot of test code missing:
>

(sorry, sent the last email by mistake - here is a list that I compiled
when writing the original tests)

       - hash algorithms - invalid hash/contents should be detected
       - signature algorithms - invalid sig/contents should be detected
       - compression
       - checking that errors are detected like:
            - image overwriting
            - missing images
            - invalid configurations
            - incorrect os/arch/type fields
            - empty data
            - images too large/small
            - invalid FDT (e.g. putting a random binary in instead)
       - default configuration selection
       - bootm command line parameters should have desired effect
       - run code coverage to make sure we are testing all the code
Sughosh Ganu - July 11, 2013, 6:03 a.m.
On Wed, Jul 10, 2013 at 3:21 PM, Sughosh Ganu <urwithsughosh@gmail.com>wrote:

> hi Tom,
>
> On Tue Jul 09, 2013 at 05:19:32PM -0400, Tom Rini wrote:
>
> <snip>
>
> > > Yes, I am not really comfortable with this. I will see if I can write
> some
> > > sandbox tests for the other image types today and post my results. I
> guess
> > > this bootm code has built up over a long time and it is hard to know
> all
> > > the ways it is used.
> >
> > Important, but I really want to see real-world booting in a case or two.
> > Unfortunately I don't have any ARM boards that work out of the box with
> > NetBSD.
>
> I have netbsd running on hawkboard, but i do not boot it using the
> bootm command, but use the go command instead. I will try to build a
> netbsd image with the u-boot header and give it a try with bootm. Need
> a day or two to check this out though.
>

Tried to boot netbsd with u-boot head 225fd8c5d45, and the boot fails. Was
able to boot netbsd with v2012.10 u-boot image. Btw, am i supposed to apply
any patch on top of the said commit.

hawkboard > bootm c3000000
## Booting kernel from Legacy Image at c3000000 ...
   Image Name:   Netbsd
   Image Type:   ARM NetBSD Kernel Image (uncompressed)
   Data Size:    2329152 Bytes = 2.2 MiB
   Load Address: c0200000
   Entry Point:  c0200000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK
subcommand not supported
hawkboard >

-sughosh
Simon Glass - July 11, 2013, 6:56 a.m.
Hi,
On Jul 10, 2013 11:04 PM, "Sughosh Ganu" <urwithsughosh@gmail.com> wrote:
>
> On Wed, Jul 10, 2013 at 3:21 PM, Sughosh Ganu <urwithsughosh@gmail.com
>wrote:
>
> > hi Tom,
> >
> > On Tue Jul 09, 2013 at 05:19:32PM -0400, Tom Rini wrote:
> >
> > <snip>
> >
> > > > Yes, I am not really comfortable with this. I will see if I can
write
> > some
> > > > sandbox tests for the other image types today and post my results. I
> > guess
> > > > this bootm code has built up over a long time and it is hard to know
> > all
> > > > the ways it is used.
> > >
> > > Important, but I really want to see real-world booting in a case or
two.
> > > Unfortunately I don't have any ARM boards that work out of the box
with
> > > NetBSD.
> >
> > I have netbsd running on hawkboard, but i do not boot it using the
> > bootm command, but use the go command instead. I will try to build a
> > netbsd image with the u-boot header and give it a try with bootm. Need
> > a day or two to check this out though.
> >
>
> Tried to boot netbsd with u-boot head 225fd8c5d45, and the boot fails. Was
> able to boot netbsd with v2012.10 u-boot image. Btw, am i supposed to
apply
> any patch on top of the said commit.

Yes please see the four commits I sent earlier today.

Regards,
Simon

>
> hawkboard > bootm c3000000
> ## Booting kernel from Legacy Image at c3000000 ...
>    Image Name:   Netbsd
>    Image Type:   ARM NetBSD Kernel Image (uncompressed)
>    Data Size:    2329152 Bytes = 2.2 MiB
>    Load Address: c0200000
>    Entry Point:  c0200000
>    Verifying Checksum ... OK
>    Loading Kernel Image ... OK
> OK
> subcommand not supported
> hawkboard >
>
> -sughosh
>
> _______________________________________________
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
Sughosh Ganu - July 12, 2013, 8:21 a.m.
hi,

On Wed Jul 10, 2013 at 11:56:30PM -0700, Simon Glass wrote:

> > > I have netbsd running on hawkboard, but i do not boot it using the
> > > bootm command, but use the go command instead. I will try to build a
> > > netbsd image with the u-boot header and give it a try with bootm. Need
> > > a day or two to check this out though.
> > >
> >
> > Tried to boot netbsd with u-boot head 225fd8c5d45, and the boot fails. Was
> > able to boot netbsd with v2012.10 u-boot image. Btw, am i supposed to
> apply
> > any patch on top of the said commit.
> 
> Yes please see the four commits I sent earlier today.

Tried after applying the series from Simon, and now the netbsd image
boots fine with the bootm command.

-sughosh
Simon Glass - July 12, 2013, 4:49 p.m.
Hi Sughosh,

On Fri, Jul 12, 2013 at 1:21 AM, Sughosh Ganu <urwithsughosh@gmail.com>wrote:

> hi,
>
> On Wed Jul 10, 2013 at 11:56:30PM -0700, Simon Glass wrote:
>
> > > > I have netbsd running on hawkboard, but i do not boot it using the
> > > > bootm command, but use the go command instead. I will try to build a
> > > > netbsd image with the u-boot header and give it a try with bootm.
> Need
> > > > a day or two to check this out though.
> > > >
> > >
> > > Tried to boot netbsd with u-boot head 225fd8c5d45, and the boot fails.
> Was
> > > able to boot netbsd with v2012.10 u-boot image. Btw, am i supposed to
> > apply
> > > any patch on top of the said commit.
> >
> > Yes please see the four commits I sent earlier today.
>
> Tried after applying the series from Simon, and now the netbsd image
> boots fine with the bootm command.
>

Thanks very much for testing this.

Regards,
Simon

Patch

diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index b89d6ad..6a635b0 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -1782,7 +1782,6 @@  static int bootz_start(cmd_tbl_t *cmdtp, int flag, int argc,
 
 int do_bootz(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 {
-	bootm_headers_t	images;
 	int ret;
 
 	if (bootz_start(cmdtp, flag, argc, argv, &images))
@@ -1794,8 +1793,10 @@  int do_bootz(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 	 */
 	bootm_disable_interrupts();
 
+	images.os.os = IH_OS_LINUX;
 	ret = do_bootm_states(cmdtp, flag, argc, argv,
-			      BOOTM_STATE_OS_FAKE_GO | BOOTM_STATE_OS_GO,
+			      BOOTM_STATE_OS_PREP | BOOTM_STATE_OS_FAKE_GO |
+			      BOOTM_STATE_OS_GO,
 			      &images, 1);
 
 	return ret;