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

[Robert Nelson]

On Tue, Jul 9, 2013 at 2:00 PM, Simon Glass <sjg at chromium.org> wrote:
> Hi Tom,
>
> On Tue, Jul 9, 2013 at 10:01 AM, Tom Rini <trini at 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 at 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 at 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,

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