Patchwork [U-Boot,ANN] v2013.07-rc2

login
register
mail settings
Submitter robertcnelson@gmail.com
Date July 1, 2013, 8:44 p.m.
Message ID <CAOCHtYjD-v+XisPkDc2n9Rth73LqEuoB9070gBAKwcmxYQ-fLw@mail.gmail.com>
Download mbox | patch
Permalink /patch/256221/
State Not Applicable
Headers show

Comments

robertcnelson@gmail.com - July 1, 2013, 8:44 p.m.
On Fri, Jun 28, 2013 at 5:12 PM, Tom Rini <trini@ti.com> wrote:
> Hey all,
>
> I've tagged and pushed v2013.07-rc2.  A bit more over the place than I
> should have gone, but picked up a lot of things that have been
> outstanding for a while.  The big thing is a refactor of the boot loop.
> Everything should be working right now, but please test.  Related to
> this is the ability to have crytpographically signed images.  It's like
> secure boot in UEFI land, but hopefully without the kerfuffle.
>
> If you've got changes outstanding still, please start gently poking
> custodians with patchwork links.  I've got a good bit of stuff I need to
> deal with myself still, but please prod me all the same.

So, the bootm refactor ( 35fc84fa1ff51e15ecd3e464dac87eb105ffed30 )
also broke bootz/zImage...

Got it to atleast get past the "invalid OS" message via:


However it's still locking up at "Starting Kernel ..."

Regards,
Simon Glass - July 2, 2013, 7:39 a.m.
Hi Robert,

On Tue, Jul 2, 2013 at 5:44 AM, Robert Nelson <robertcnelson@gmail.com>wrote:

> On Fri, Jun 28, 2013 at 5:12 PM, Tom Rini <trini@ti.com> wrote:
> > Hey all,
> >
> > I've tagged and pushed v2013.07-rc2.  A bit more over the place than I
> > should have gone, but picked up a lot of things that have been
> > outstanding for a while.  The big thing is a refactor of the boot loop.
> > Everything should be working right now, but please test.  Related to
> > this is the ability to have crytpographically signed images.  It's like
> > secure boot in UEFI land, but hopefully without the kerfuffle.
> >
> > If you've got changes outstanding still, please start gently poking
> > custodians with patchwork links.  I've got a good bit of stuff I need to
> > deal with myself still, but please prod me all the same.
>
> So, the bootm refactor ( 35fc84fa1ff51e15ecd3e464dac87eb105ffed30 )
> also broke bootz/zImage...
>
> Got it to atleast get past the "invalid OS" message via:
>
> diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
> index 02a5013..a0b55ef 100644
> --- a/common/cmd_bootm.c
> +++ b/common/cmd_bootm.c
> @@ -1744,6 +1744,12 @@ static int bootz_start(cmd_tbl_t *cmdtp, int
> flag, int argc,
>         int ret;
>         void *zi_start, *zi_end;
>
> +       memset(images, 0, sizeof(bootm_headers_t));
> +
> +       boot_start_lmb(images);
> +
> +       images->os.os = IH_OS_LINUX;
> +
>         ret = do_bootm_states(cmdtp, flag, argc, argv, BOOTM_STATE_START,
>                               images, 1);
>
> However it's still locking up at "Starting Kernel ..."
>

What board is this please? I have only tested on x86, but perhaps have
missed something here.

Regards,
Simon
Andreas Bießmann - July 2, 2013, 10:37 a.m.
Hi,

On 07/01/2013 10:44 PM, Robert Nelson wrote:
> On Fri, Jun 28, 2013 at 5:12 PM, Tom Rini <trini@ti.com> wrote:
>> Hey all,
>>
>> I've tagged and pushed v2013.07-rc2.  A bit more over the place than I
>> should have gone, but picked up a lot of things that have been
>> outstanding for a while.  The big thing is a refactor of the boot loop.
>> Everything should be working right now, but please test.  Related to
>> this is the ability to have crytpographically signed images.  It's like
>> secure boot in UEFI land, but hopefully without the kerfuffle.
>>
>> If you've got changes outstanding still, please start gently poking
>> custodians with patchwork links.  I've got a good bit of stuff I need to
>> deal with myself still, but please prod me all the same.
> 
> So, the bootm refactor ( 35fc84fa1ff51e15ecd3e464dac87eb105ffed30 )
> also broke bootz/zImage...

and also bootm for uImage on avr32 ... will investigate it these days.

Best regards

Andreas Bießmann
robertcnelson@gmail.com - July 2, 2013, 11:41 a.m.
On Tue, Jul 2, 2013 at 2:39 AM, Simon Glass <sjg@chromium.org> wrote:
> Hi Robert,
>
> On Tue, Jul 2, 2013 at 5:44 AM, Robert Nelson <robertcnelson@gmail.com>
> wrote:
>>
>> On Fri, Jun 28, 2013 at 5:12 PM, Tom Rini <trini@ti.com> wrote:
>> > Hey all,
>> >
>> > I've tagged and pushed v2013.07-rc2.  A bit more over the place than I
>> > should have gone, but picked up a lot of things that have been
>> > outstanding for a while.  The big thing is a refactor of the boot loop.
>> > Everything should be working right now, but please test.  Related to
>> > this is the ability to have crytpographically signed images.  It's like
>> > secure boot in UEFI land, but hopefully without the kerfuffle.
>> >
>> > If you've got changes outstanding still, please start gently poking
>> > custodians with patchwork links.  I've got a good bit of stuff I need to
>> > deal with myself still, but please prod me all the same.
>>
>> So, the bootm refactor ( 35fc84fa1ff51e15ecd3e464dac87eb105ffed30 )
>> also broke bootz/zImage...
>>
>> Got it to atleast get past the "invalid OS" message via:
>>
>> diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
>> index 02a5013..a0b55ef 100644
>> --- a/common/cmd_bootm.c
>> +++ b/common/cmd_bootm.c
>> @@ -1744,6 +1744,12 @@ static int bootz_start(cmd_tbl_t *cmdtp, int
>> flag, int argc,
>>         int ret;
>>         void *zi_start, *zi_end;
>>
>> +       memset(images, 0, sizeof(bootm_headers_t));
>> +
>> +       boot_start_lmb(images);
>> +
>> +       images->os.os = IH_OS_LINUX;
>> +
>>         ret = do_bootm_states(cmdtp, flag, argc, argv, BOOTM_STATE_START,
>>                               images, 1);
>>
>> However it's still locking up at "Starting Kernel ..."
>
>
> What board is this please? I have only tested on x86, but perhaps have
> missed something here.

So far it looks like any arm board...  I was working on specifically
the imx6 quad core wandboard bringup.  But i've also verified it on
the Panda/Beagle too...  Alll 3 of these boards worked fine with
v2013.07-rc1...

Wandboard:

Boot Sequence: (device tree boot)
load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file}
bootz ${loadaddr} - ${fdt_addr}

U-Boot 2013.07-rc2-00001-g23c15c2-dirty (Jul 02 2013 - 06:33:59)

CPU:   Freescale i.MX6Q rev1.2 at 792 MHz
Reset cause: POR
Board: Wandboard
DRAM:  2 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   FEC [PRIME]
Warning: FEC using MAC address from net device

Hit any key to stop autoboot:  0
=> load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
4112496 bytes read in 307 ms (12.8 MiB/s)
=> load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file}
22150 bytes read in 126 ms (170.9 KiB/s)
=> bootz ${loadaddr} - ${fdt_addr}

Beagle xM:

Boot Sequence: (old board file boot)
fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
bootz ${loadaddr}

OMAP3 beagleboard.org # fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
reading zImage
3421392 bytes read in 246 ms (13.3 MiB/s)
OMAP3 beagleboard.org # bootz ${loadaddr}
data abort

    MAYBE you should read doc/README.arm-unaligned-accesses

pc : [<9ff8bf20>]	   lr : [<9ff5d2a8>]
sp : 9fef8bd8  ip : 9ffffff8	 fp : 9fef9760
r10: 9ffa6314  r9 : 9ffa7710	 r8 : 9fef8f30
r7 : 805434d0  r6 : 00020e61	 r5 : ffafefff  r4 : 9ff9c6e6
r3 : 00020e61  r2 : 003434d0	 r1 : 80200000  r0 : 9fef8cf0
Flags: nzcv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...

resetting ...

U-Boot SPL 2013.07-rc2-00001-g7c2cb8a-dirty (Jul 02 2013 - 06:14:53)

Regards,
robertcnelson@gmail.com - July 2, 2013, 11:43 a.m.
On Tue, Jul 2, 2013 at 6:41 AM, Robert Nelson <robertcnelson@gmail.com> wrote:
> On Tue, Jul 2, 2013 at 2:39 AM, Simon Glass <sjg@chromium.org> wrote:
>> Hi Robert,
>>
>> On Tue, Jul 2, 2013 at 5:44 AM, Robert Nelson <robertcnelson@gmail.com>
>> wrote:
>>>
>>> On Fri, Jun 28, 2013 at 5:12 PM, Tom Rini <trini@ti.com> wrote:
>>> > Hey all,
>>> >
>>> > I've tagged and pushed v2013.07-rc2.  A bit more over the place than I
>>> > should have gone, but picked up a lot of things that have been
>>> > outstanding for a while.  The big thing is a refactor of the boot loop.
>>> > Everything should be working right now, but please test.  Related to
>>> > this is the ability to have crytpographically signed images.  It's like
>>> > secure boot in UEFI land, but hopefully without the kerfuffle.
>>> >
>>> > If you've got changes outstanding still, please start gently poking
>>> > custodians with patchwork links.  I've got a good bit of stuff I need to
>>> > deal with myself still, but please prod me all the same.
>>>
>>> So, the bootm refactor ( 35fc84fa1ff51e15ecd3e464dac87eb105ffed30 )
>>> also broke bootz/zImage...
>>>
>>> Got it to atleast get past the "invalid OS" message via:
>>>
>>> diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
>>> index 02a5013..a0b55ef 100644
>>> --- a/common/cmd_bootm.c
>>> +++ b/common/cmd_bootm.c
>>> @@ -1744,6 +1744,12 @@ static int bootz_start(cmd_tbl_t *cmdtp, int
>>> flag, int argc,
>>>         int ret;
>>>         void *zi_start, *zi_end;
>>>
>>> +       memset(images, 0, sizeof(bootm_headers_t));
>>> +
>>> +       boot_start_lmb(images);
>>> +
>>> +       images->os.os = IH_OS_LINUX;
>>> +
>>>         ret = do_bootm_states(cmdtp, flag, argc, argv, BOOTM_STATE_START,
>>>                               images, 1);
>>>
>>> However it's still locking up at "Starting Kernel ..."
>>
>>
>> What board is this please? I have only tested on x86, but perhaps have
>> missed something here.
>
> So far it looks like any arm board...  I was working on specifically
> the imx6 quad core wandboard bringup.  But i've also verified it on
> the Panda/Beagle too...  Alll 3 of these boards worked fine with
> v2013.07-rc1...
>
> Wandboard:
>
> Boot Sequence: (device tree boot)
> load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
> load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file}
> bootz ${loadaddr} - ${fdt_addr}
>
> U-Boot 2013.07-rc2-00001-g23c15c2-dirty (Jul 02 2013 - 06:33:59)
>
> CPU:   Freescale i.MX6Q rev1.2 at 792 MHz
> Reset cause: POR
> Board: Wandboard
> DRAM:  2 GiB
> MMC:   FSL_SDHC: 0, FSL_SDHC: 1
> *** Warning - bad CRC, using default environment
>
> In:    serial
> Out:   serial
> Err:   serial
> Net:   FEC [PRIME]
> Warning: FEC using MAC address from net device
>
> Hit any key to stop autoboot:  0
> => load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
> 4112496 bytes read in 307 ms (12.8 MiB/s)
> => load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file}
> 22150 bytes read in 126 ms (170.9 KiB/s)
> => bootz ${loadaddr} - ${fdt_addr}
<hardlock>

Missed the important detail...

Regards,
Tom Rini - July 2, 2013, 12:34 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/02/2013 06:37 AM, Andreas Bießmann wrote:
> Hi,
> 
> On 07/01/2013 10:44 PM, Robert Nelson wrote:
>> On Fri, Jun 28, 2013 at 5:12 PM, Tom Rini <trini@ti.com> wrote:
>>> Hey all,
>>> 
>>> I've tagged and pushed v2013.07-rc2.  A bit more over the place
>>> than I should have gone, but picked up a lot of things that
>>> have been outstanding for a while.  The big thing is a refactor
>>> of the boot loop. Everything should be working right now, but
>>> please test.  Related to this is the ability to have
>>> crytpographically signed images.  It's like secure boot in UEFI
>>> land, but hopefully without the kerfuffle.
>>> 
>>> If you've got changes outstanding still, please start gently
>>> poking custodians with patchwork links.  I've got a good bit of
>>> stuff I need to deal with myself still, but please prod me all
>>> the same.
>> 
>> So, the bootm refactor ( 35fc84fa1ff51e15ecd3e464dac87eb105ffed30
>> ) also broke bootz/zImage...
> 
> and also bootm for uImage on avr32 ... will investigate it these
> days.

Hurk, I hope avr32 is the same problem Stefan found/fixed with
PowerPC, can you check / test that quickly?  See last patch to
arch/powerpc/lib/bootm.c.

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJR0sjcAAoJENk4IS6UOR1WfBkQAIXXb3O7/yAYv7hQ/YvcfZej
scftgdsmt0kCsAEsCx7Prmae2c5+0HKUADPNRSp6IVuU1aZNCbauT1o0mqDT2ieb
JaYDwLaMq5gozZ4HMnc5LyAWDFc6Kh1qqpUV+2hWlRy2ZLjWJ8/f4tEPJQ9ULVs0
t3TO+tpHPKYgg+vgpNePhQxuvphlP8NKpG7eVSuy7atkqWElAzekOtwTAtYFcIGv
h0XrAiPnv3WXHGMXfXLA5ABS+71HBOOtewAaSwG0QZ0h55pCRMc/GQ7WxSB2T03C
aNV25eCTH0i+LQjvL/8rriE8805yxD04klu//t/520z2ySCDy3DgpwAqnxuXW6+V
knATFhWyAsJjNJ2AKgrE+W2ffFcqoVGf+pZW3Da4StoCjHDaCCtp3DFMeqZ8g92I
ef+qd96nlYjO+okUf6+4wXgFz1KE5O78NgWLxvaOZ8E55b4hHUMnv0kiEnYpB9OD
pK6imnN/0w27Gakzp88kQVQnuu8yps/la/htqyXQMxdSa26OZm1iDFRqRuv2kQbP
8SnW4iVp7QEZZ408pbvMgnfIy/ACnqbxRF5dEm/2gvGZ6bPcJsIjv1BTyal9LYhI
qT7flTJGKcgHiVw4/ZszA2tA9zmSpgDN/T7uZp1KpmtIqXfZAgpeJTSwMdkF00z1
sOt9L3YLlzz1/OcDbh5P
=dySs
-----END PGP SIGNATURE-----
Andreas Bießmann - July 2, 2013, 12:56 p.m.
On 07/02/2013 02:34 PM, Tom Rini wrote:
> On 07/02/2013 06:37 AM, Andreas Bießmann wrote:
>> Hi,
> 
>> On 07/01/2013 10:44 PM, Robert Nelson wrote:
>>> On Fri, Jun 28, 2013 at 5:12 PM, Tom Rini <trini@ti.com> wrote:
>>>> Hey all,
>>>>
>>>> I've tagged and pushed v2013.07-rc2.  A bit more over the place
>>>> than I should have gone, but picked up a lot of things that
>>>> have been outstanding for a while.  The big thing is a refactor
>>>> of the boot loop. Everything should be working right now, but
>>>> please test.  Related to this is the ability to have
>>>> crytpographically signed images.  It's like secure boot in UEFI
>>>> land, but hopefully without the kerfuffle.
>>>>
>>>> If you've got changes outstanding still, please start gently
>>>> poking custodians with patchwork links.  I've got a good bit of
>>>> stuff I need to deal with myself still, but please prod me all
>>>> the same.
>>>
>>> So, the bootm refactor ( 35fc84fa1ff51e15ecd3e464dac87eb105ffed30
>>> ) also broke bootz/zImage...
> 
>> and also bootm for uImage on avr32 ... will investigate it these
>> days.
> 
> Hurk, I hope avr32 is the same problem Stefan found/fixed with
> PowerPC, can you check / test that quickly?  See last patch to
> arch/powerpc/lib/bootm.c.

got it: http://patchwork.ozlabs.org/patch/256393/

Let it settle some days, would you pick it directly or do you prefer a PR?

Best regards

Andreas Bießmann
Simon Glass - July 2, 2013, 2:15 p.m.
Hi Robert,

On Jul 2, 2013 8:41 PM, "Robert Nelson" <robertcnelson@gmail.com> wrote:
>
> On Tue, Jul 2, 2013 at 2:39 AM, Simon Glass <sjg@chromium.org> wrote:
> > Hi Robert,
> >
> > On Tue, Jul 2, 2013 at 5:44 AM, Robert Nelson <robertcnelson@gmail.com>
> > wrote:
> >>
> >> On Fri, Jun 28, 2013 at 5:12 PM, Tom Rini <trini@ti.com> wrote:
> >> > Hey all,
> >> >
> >> > I've tagged and pushed v2013.07-rc2.  A bit more over the place than
I
> >> > should have gone, but picked up a lot of things that have been
> >> > outstanding for a while.  The big thing is a refactor of the boot
loop.
> >> > Everything should be working right now, but please test.  Related to
> >> > this is the ability to have crytpographically signed images.  It's
like
> >> > secure boot in UEFI land, but hopefully without the kerfuffle.
> >> >
> >> > If you've got changes outstanding still, please start gently poking
> >> > custodians with patchwork links.  I've got a good bit of stuff I
need to
> >> > deal with myself still, but please prod me all the same.
> >>
> >> So, the bootm refactor ( 35fc84fa1ff51e15ecd3e464dac87eb105ffed30 )
> >> also broke bootz/zImage...
> >>
> >> Got it to atleast get past the "invalid OS" message via:
> >>
> >> diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
> >> index 02a5013..a0b55ef 100644
> >> --- a/common/cmd_bootm.c
> >> +++ b/common/cmd_bootm.c
> >> @@ -1744,6 +1744,12 @@ static int bootz_start(cmd_tbl_t *cmdtp, int
> >> flag, int argc,
> >>         int ret;
> >>         void *zi_start, *zi_end;
> >>
> >> +       memset(images, 0, sizeof(bootm_headers_t));
> >> +
> >> +       boot_start_lmb(images);
> >> +
> >> +       images->os.os = IH_OS_LINUX;
> >> +
> >>         ret = do_bootm_states(cmdtp, flag, argc, argv,
BOOTM_STATE_START,
> >>                               images, 1);
> >>
> >> However it's still locking up at "Starting Kernel ..."
> >
> >
> > What board is this please? I have only tested on x86, but perhaps have
> > missed something here.
>
> So far it looks like any arm board...  I was working on specifically
> the imx6 quad core wandboard bringup.  But i've also verified it on
> the Panda/Beagle too...  Alll 3 of these boards worked fine with
> v2013.07-rc1...
>
> Wandboard:
>
> Boot Sequence: (device tree boot)
> load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
> load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file}
> bootz ${loadaddr} - ${fdt_addr}
>
> U-Boot 2013.07-rc2-00001-g23c15c2-dirty (Jul 02 2013 - 06:33:59)
>
> CPU:   Freescale i.MX6Q rev1.2 at 792 MHz
> Reset cause: POR
> Board: Wandboard
> DRAM:  2 GiB
> MMC:   FSL_SDHC: 0, FSL_SDHC: 1
> *** Warning - bad CRC, using default environment
>
> In:    serial
> Out:   serial
> Err:   serial
> Net:   FEC [PRIME]
> Warning: FEC using MAC address from net device
>
> Hit any key to stop autoboot:  0
> => load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
> 4112496 bytes read in 307 ms (12.8 MiB/s)
> => load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file}
> 22150 bytes read in 126 ms (170.9 KiB/s)
> => bootz ${loadaddr} - ${fdt_addr}
>
> Beagle xM:
>
> Boot Sequence: (old board file boot)
> fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
> bootz ${loadaddr}
>
> OMAP3 beagleboard.org # fatload mmc ${mmcdev}:${mmcpart} ${loadaddr}
zImage
> reading zImage
> 3421392 bytes read in 246 ms (13.3 MiB/s)
> OMAP3 beagleboard.org # bootz ${loadaddr}
> data abort
>
>     MAYBE you should read doc/README.arm-unaligned-accesses
>
> pc : [<9ff8bf20>]          lr : [<9ff5d2a8>]
> sp : 9fef8bd8  ip : 9ffffff8     fp : 9fef9760
> r10: 9ffa6314  r9 : 9ffa7710     r8 : 9fef8f30
> r7 : 805434d0  r6 : 00020e61     r5 : ffafefff  r4 : 9ff9c6e6
> r3 : 00020e61  r2 : 003434d0     r1 : 80200000  r0 : 9fef8cf0
> Flags: nzcv  IRQs off  FIQs off  Mode SVC_32
> Resetting CPU ...
>
> resetting ...
>
> U-Boot SPL 2013.07-rc2-00001-g7c2cb8a-dirty (Jul 02 2013 - 06:14:53)

Thanks for the details. I will take a look later today US time.

Regards,
Simon

>
> Regards,
>
> --
> Robert Nelson
> http://www.rcn-ee.com/
Simon Glass - July 3, 2013, 1:52 p.m.
Hi Robert.

On Tue, Jul 2, 2013 at 11:15 PM, Simon Glass <sjg@chromium.org> wrote:

> Hi Robert,
>
> On Jul 2, 2013 8:41 PM, "Robert Nelson" <robertcnelson@gmail.com> wrote:
> >
> > On Tue, Jul 2, 2013 at 2:39 AM, Simon Glass <sjg@chromium.org> wrote:
> > > Hi Robert,
> > >
> > > On Tue, Jul 2, 2013 at 5:44 AM, Robert Nelson <robertcnelson@gmail.com
> >
> > > wrote:
> > >>
> > >> On Fri, Jun 28, 2013 at 5:12 PM, Tom Rini <trini@ti.com> wrote:
> > >> > Hey all,
> > >> >
> > >> > I've tagged and pushed v2013.07-rc2.  A bit more over the place
> than I
> > >> > should have gone, but picked up a lot of things that have been
> > >> > outstanding for a while.  The big thing is a refactor of the boot
> loop.
> > >> > Everything should be working right now, but please test.  Related to
> > >> > this is the ability to have crytpographically signed images.  It's
> like
> > >> > secure boot in UEFI land, but hopefully without the kerfuffle.
> > >> >
> > >> > If you've got changes outstanding still, please start gently poking
> > >> > custodians with patchwork links.  I've got a good bit of stuff I
> need to
> > >> > deal with myself still, but please prod me all the same.
> > >>
> > >> So, the bootm refactor ( 35fc84fa1ff51e15ecd3e464dac87eb105ffed30 )
> > >> also broke bootz/zImage...
> > >>
> > >> Got it to atleast get past the "invalid OS" message via:
> > >>
> > >> diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
> > >> index 02a5013..a0b55ef 100644
> > >> --- a/common/cmd_bootm.c
> > >> +++ b/common/cmd_bootm.c
> > >> @@ -1744,6 +1744,12 @@ static int bootz_start(cmd_tbl_t *cmdtp, int
> > >> flag, int argc,
> > >>         int ret;
> > >>         void *zi_start, *zi_end;
> > >>
> > >> +       memset(images, 0, sizeof(bootm_headers_t));
> > >> +
> > >> +       boot_start_lmb(images);
> > >> +
> > >> +       images->os.os = IH_OS_LINUX;
> > >> +
> > >>         ret = do_bootm_states(cmdtp, flag, argc, argv,
> BOOTM_STATE_START,
> > >>                               images, 1);
> > >>
> > >> However it's still locking up at "Starting Kernel ..."
> > >
> > >
> > > What board is this please? I have only tested on x86, but perhaps have
> > > missed something here.
> >
> > So far it looks like any arm board...  I was working on specifically
> > the imx6 quad core wandboard bringup.  But i've also verified it on
> > the Panda/Beagle too...  Alll 3 of these boards worked fine with
> > v2013.07-rc1...
> >
> > Wandboard:
> >
> > Boot Sequence: (device tree boot)
> > load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
> > load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file}
> > bootz ${loadaddr} - ${fdt_addr}
> >
> > U-Boot 2013.07-rc2-00001-g23c15c2-dirty (Jul 02 2013 - 06:33:59)
> >
> > CPU:   Freescale i.MX6Q rev1.2 at 792 MHz
> > Reset cause: POR
> > Board: Wandboard
> > DRAM:  2 GiB
> > MMC:   FSL_SDHC: 0, FSL_SDHC: 1
> > *** Warning - bad CRC, using default environment
> >
> > In:    serial
> > Out:   serial
> > Err:   serial
> > Net:   FEC [PRIME]
> > Warning: FEC using MAC address from net device
> >
> > Hit any key to stop autoboot:  0
> > => load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
> > 4112496 bytes read in 307 ms (12.8 MiB/s)
> > => load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file}
> > 22150 bytes read in 126 ms (170.9 KiB/s)
> > => bootz ${loadaddr} - ${fdt_addr}
> >
> > Beagle xM:
> >
> > Boot Sequence: (old board file boot)
> > fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
> > bootz ${loadaddr}
> >
> > OMAP3 beagleboard.org # fatload mmc ${mmcdev}:${mmcpart} ${loadaddr}
> zImage
> > reading zImage
> > 3421392 bytes read in 246 ms (13.3 MiB/s)
> > OMAP3 beagleboard.org # bootz ${loadaddr}
> > data abort
> >
> >     MAYBE you should read doc/README.arm-unaligned-accesses
> >
> > pc : [<9ff8bf20>]          lr : [<9ff5d2a8>]
> > sp : 9fef8bd8  ip : 9ffffff8     fp : 9fef9760
> > r10: 9ffa6314  r9 : 9ffa7710     r8 : 9fef8f30
> > r7 : 805434d0  r6 : 00020e61     r5 : ffafefff  r4 : 9ff9c6e6
> > r3 : 00020e61  r2 : 003434d0     r1 : 80200000  r0 : 9fef8cf0
> > Flags: nzcv  IRQs off  FIQs off  Mode SVC_32
> > Resetting CPU ...
> >
> > resetting ...
> >
> > U-Boot SPL 2013.07-rc2-00001-g7c2cb8a-dirty (Jul 02 2013 - 06:14:53)
>
> Thanks for the details. I will take a look later today US time.
>
Unfortunately due to my current location I don't have access to a good ARM
bootz target. I believe I have found a problem, and will send out some
patches for you to try/debug, although with tidying up a few things.

However until I can test them (several days) they are for interest only.

Regards,
Simon
Tom Rini - July 3, 2013, 1:56 p.m.
On Wed, Jul 03, 2013 at 10:52:18PM +0900, Simon Glass wrote:
> Hi Robert.
> 
> On Tue, Jul 2, 2013 at 11:15 PM, Simon Glass <sjg@chromium.org> wrote:
> 
> > Hi Robert,
> >
> > On Jul 2, 2013 8:41 PM, "Robert Nelson" <robertcnelson@gmail.com> wrote:
> > >
> > > On Tue, Jul 2, 2013 at 2:39 AM, Simon Glass <sjg@chromium.org> wrote:
> > > > Hi Robert,
> > > >
> > > > On Tue, Jul 2, 2013 at 5:44 AM, Robert Nelson <robertcnelson@gmail.com
> > >
> > > > wrote:
> > > >>
> > > >> On Fri, Jun 28, 2013 at 5:12 PM, Tom Rini <trini@ti.com> wrote:
> > > >> > Hey all,
> > > >> >
> > > >> > I've tagged and pushed v2013.07-rc2.  A bit more over the place
> > than I
> > > >> > should have gone, but picked up a lot of things that have been
> > > >> > outstanding for a while.  The big thing is a refactor of the boot
> > loop.
> > > >> > Everything should be working right now, but please test.  Related to
> > > >> > this is the ability to have crytpographically signed images.  It's
> > like
> > > >> > secure boot in UEFI land, but hopefully without the kerfuffle.
> > > >> >
> > > >> > If you've got changes outstanding still, please start gently poking
> > > >> > custodians with patchwork links.  I've got a good bit of stuff I
> > need to
> > > >> > deal with myself still, but please prod me all the same.
> > > >>
> > > >> So, the bootm refactor ( 35fc84fa1ff51e15ecd3e464dac87eb105ffed30 )
> > > >> also broke bootz/zImage...
> > > >>
> > > >> Got it to atleast get past the "invalid OS" message via:
> > > >>
> > > >> diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
> > > >> index 02a5013..a0b55ef 100644
> > > >> --- a/common/cmd_bootm.c
> > > >> +++ b/common/cmd_bootm.c
> > > >> @@ -1744,6 +1744,12 @@ static int bootz_start(cmd_tbl_t *cmdtp, int
> > > >> flag, int argc,
> > > >>         int ret;
> > > >>         void *zi_start, *zi_end;
> > > >>
> > > >> +       memset(images, 0, sizeof(bootm_headers_t));
> > > >> +
> > > >> +       boot_start_lmb(images);
> > > >> +
> > > >> +       images->os.os = IH_OS_LINUX;
> > > >> +
> > > >>         ret = do_bootm_states(cmdtp, flag, argc, argv,
> > BOOTM_STATE_START,
> > > >>                               images, 1);
> > > >>
> > > >> However it's still locking up at "Starting Kernel ..."
> > > >
> > > >
> > > > What board is this please? I have only tested on x86, but perhaps have
> > > > missed something here.
> > >
> > > So far it looks like any arm board...  I was working on specifically
> > > the imx6 quad core wandboard bringup.  But i've also verified it on
> > > the Panda/Beagle too...  Alll 3 of these boards worked fine with
> > > v2013.07-rc1...
> > >
> > > Wandboard:
> > >
> > > Boot Sequence: (device tree boot)
> > > load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
> > > load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file}
> > > bootz ${loadaddr} - ${fdt_addr}
> > >
> > > U-Boot 2013.07-rc2-00001-g23c15c2-dirty (Jul 02 2013 - 06:33:59)
> > >
> > > CPU:   Freescale i.MX6Q rev1.2 at 792 MHz
> > > Reset cause: POR
> > > Board: Wandboard
> > > DRAM:  2 GiB
> > > MMC:   FSL_SDHC: 0, FSL_SDHC: 1
> > > *** Warning - bad CRC, using default environment
> > >
> > > In:    serial
> > > Out:   serial
> > > Err:   serial
> > > Net:   FEC [PRIME]
> > > Warning: FEC using MAC address from net device
> > >
> > > Hit any key to stop autoboot:  0
> > > => load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
> > > 4112496 bytes read in 307 ms (12.8 MiB/s)
> > > => load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file}
> > > 22150 bytes read in 126 ms (170.9 KiB/s)
> > > => bootz ${loadaddr} - ${fdt_addr}
> > >
> > > Beagle xM:
> > >
> > > Boot Sequence: (old board file boot)
> > > fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
> > > bootz ${loadaddr}
> > >
> > > OMAP3 beagleboard.org # fatload mmc ${mmcdev}:${mmcpart} ${loadaddr}
> > zImage
> > > reading zImage
> > > 3421392 bytes read in 246 ms (13.3 MiB/s)
> > > OMAP3 beagleboard.org # bootz ${loadaddr}
> > > data abort
> > >
> > >     MAYBE you should read doc/README.arm-unaligned-accesses
> > >
> > > pc : [<9ff8bf20>]          lr : [<9ff5d2a8>]
> > > sp : 9fef8bd8  ip : 9ffffff8     fp : 9fef9760
> > > r10: 9ffa6314  r9 : 9ffa7710     r8 : 9fef8f30
> > > r7 : 805434d0  r6 : 00020e61     r5 : ffafefff  r4 : 9ff9c6e6
> > > r3 : 00020e61  r2 : 003434d0     r1 : 80200000  r0 : 9fef8cf0
> > > Flags: nzcv  IRQs off  FIQs off  Mode SVC_32
> > > Resetting CPU ...
> > >
> > > resetting ...
> > >
> > > U-Boot SPL 2013.07-rc2-00001-g7c2cb8a-dirty (Jul 02 2013 - 06:14:53)
> >
> > Thanks for the details. I will take a look later today US time.
>
> Unfortunately due to my current location I don't have access to a good ARM
> bootz target. I believe I have found a problem, and will send out some
> patches for you to try/debug, although with tidying up a few things.
> 
> However until I can test them (several days) they are for interest only.

Please post them ASAP, I'll see about picking them up and testing them
as well.  And if needed, I can get a Beaglebone of some color thrown
your way for future ease of testing bootz :)
robertcnelson@gmail.com - July 3, 2013, 2:04 p.m.
On Wed, Jul 3, 2013 at 8:52 AM, Simon Glass <sjg@chromium.org> wrote:
> Hi Robert.
>
> On Tue, Jul 2, 2013 at 11:15 PM, Simon Glass <sjg@chromium.org> wrote:
>>
>> Hi Robert,
>>
>> On Jul 2, 2013 8:41 PM, "Robert Nelson" <robertcnelson@gmail.com> wrote:
>> >
>> > On Tue, Jul 2, 2013 at 2:39 AM, Simon Glass <sjg@chromium.org> wrote:
>> > > Hi Robert,
>> > >
>> > > On Tue, Jul 2, 2013 at 5:44 AM, Robert Nelson
>> > > <robertcnelson@gmail.com>
>> > > wrote:
>> > >>
>> > >> On Fri, Jun 28, 2013 at 5:12 PM, Tom Rini <trini@ti.com> wrote:
>> > >> > Hey all,
>> > >> >
>> > >> > I've tagged and pushed v2013.07-rc2.  A bit more over the place
>> > >> > than I
>> > >> > should have gone, but picked up a lot of things that have been
>> > >> > outstanding for a while.  The big thing is a refactor of the boot
>> > >> > loop.
>> > >> > Everything should be working right now, but please test.  Related
>> > >> > to
>> > >> > this is the ability to have crytpographically signed images.  It's
>> > >> > like
>> > >> > secure boot in UEFI land, but hopefully without the kerfuffle.
>> > >> >
>> > >> > If you've got changes outstanding still, please start gently poking
>> > >> > custodians with patchwork links.  I've got a good bit of stuff I
>> > >> > need to
>> > >> > deal with myself still, but please prod me all the same.
>> > >>
>> > >> So, the bootm refactor ( 35fc84fa1ff51e15ecd3e464dac87eb105ffed30 )
>> > >> also broke bootz/zImage...
>> > >>
>> > >> Got it to atleast get past the "invalid OS" message via:
>> > >>
>> > >> diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
>> > >> index 02a5013..a0b55ef 100644
>> > >> --- a/common/cmd_bootm.c
>> > >> +++ b/common/cmd_bootm.c
>> > >> @@ -1744,6 +1744,12 @@ static int bootz_start(cmd_tbl_t *cmdtp, int
>> > >> flag, int argc,
>> > >>         int ret;
>> > >>         void *zi_start, *zi_end;
>> > >>
>> > >> +       memset(images, 0, sizeof(bootm_headers_t));
>> > >> +
>> > >> +       boot_start_lmb(images);
>> > >> +
>> > >> +       images->os.os = IH_OS_LINUX;
>> > >> +
>> > >>         ret = do_bootm_states(cmdtp, flag, argc, argv,
>> > >> BOOTM_STATE_START,
>> > >>                               images, 1);
>> > >>
>> > >> However it's still locking up at "Starting Kernel ..."
>> > >
>> > >
>> > > What board is this please? I have only tested on x86, but perhaps have
>> > > missed something here.
>> >
>> > So far it looks like any arm board...  I was working on specifically
>> > the imx6 quad core wandboard bringup.  But i've also verified it on
>> > the Panda/Beagle too...  Alll 3 of these boards worked fine with
>> > v2013.07-rc1...
>> >
>> > Wandboard:
>> >
>> > Boot Sequence: (device tree boot)
>> > load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
>> > load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file}
>> > bootz ${loadaddr} - ${fdt_addr}
>> >
>> > U-Boot 2013.07-rc2-00001-g23c15c2-dirty (Jul 02 2013 - 06:33:59)
>> >
>> > CPU:   Freescale i.MX6Q rev1.2 at 792 MHz
>> > Reset cause: POR
>> > Board: Wandboard
>> > DRAM:  2 GiB
>> > MMC:   FSL_SDHC: 0, FSL_SDHC: 1
>> > *** Warning - bad CRC, using default environment
>> >
>> > In:    serial
>> > Out:   serial
>> > Err:   serial
>> > Net:   FEC [PRIME]
>> > Warning: FEC using MAC address from net device
>> >
>> > Hit any key to stop autoboot:  0
>> > => load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
>> > 4112496 bytes read in 307 ms (12.8 MiB/s)
>> > => load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file}
>> > 22150 bytes read in 126 ms (170.9 KiB/s)
>> > => bootz ${loadaddr} - ${fdt_addr}
>> >
>> > Beagle xM:
>> >
>> > Boot Sequence: (old board file boot)
>> > fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
>> > bootz ${loadaddr}
>> >
>> > OMAP3 beagleboard.org # fatload mmc ${mmcdev}:${mmcpart} ${loadaddr}
>> > zImage
>> > reading zImage
>> > 3421392 bytes read in 246 ms (13.3 MiB/s)
>> > OMAP3 beagleboard.org # bootz ${loadaddr}
>> > data abort
>> >
>> >     MAYBE you should read doc/README.arm-unaligned-accesses
>> >
>> > pc : [<9ff8bf20>]          lr : [<9ff5d2a8>]
>> > sp : 9fef8bd8  ip : 9ffffff8     fp : 9fef9760
>> > r10: 9ffa6314  r9 : 9ffa7710     r8 : 9fef8f30
>> > r7 : 805434d0  r6 : 00020e61     r5 : ffafefff  r4 : 9ff9c6e6
>> > r3 : 00020e61  r2 : 003434d0     r1 : 80200000  r0 : 9fef8cf0
>> > Flags: nzcv  IRQs off  FIQs off  Mode SVC_32
>> > Resetting CPU ...
>> >
>> > resetting ...
>> >
>> > U-Boot SPL 2013.07-rc2-00001-g7c2cb8a-dirty (Jul 02 2013 - 06:14:53)
>>
>> Thanks for the details. I will take a look later today US time.
>
> Unfortunately due to my current location I don't have access to a good ARM
> bootz target. I believe I have found a problem, and will send out some
> patches for you to try/debug, although with tidying up a few things.
>
> However until I can test them (several days) they are for interest only.

Sure, no problem... Other then a long drive tonight, I'll have net
access over the 4th..  It's just 'too' easy to pack a beaglebone black
where ever i go. ;)

Regards,

Patch

diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 02a5013..a0b55ef 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -1744,6 +1744,12 @@  static int bootz_start(cmd_tbl_t *cmdtp, int
flag, int argc,
        int ret;
        void *zi_start, *zi_end;

+       memset(images, 0, sizeof(bootm_headers_t));
+
+       boot_start_lmb(images);
+
+       images->os.os = IH_OS_LINUX;
+
        ret = do_bootm_states(cmdtp, flag, argc, argv, BOOTM_STATE_START,
                              images, 1);