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

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

[Tom Rini]

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.

Thanks all!

-- 
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/20130628/6557143b/attachment.pgp>

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

[Robert Nelson]

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 ..."

Regards,

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

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

[Simon Glass]

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

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

[Andreas Bießmann]

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

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

[Dirk Eibach]

Hi Andy,

> 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.

my series "[PATCH v7 0/5] Add gdsys ControlCenter Digital board" is
still missing.

You can find it here:
http://patchwork.ozlabs.org/patch/254751/
http://patchwork.ozlabs.org/patch/254749/
http://patchwork.ozlabs.org/patch/254748/
http://patchwork.ozlabs.org/patch/254750/
http://patchwork.ozlabs.org/patch/254754/

Cheers
Dirk

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

[Robert Nelson]

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,

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

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

[Robert Nelson]

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,

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

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

[Tom Rini]

-----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-----

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

[Andreas Bießmann]

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

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

[Simon Glass]

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/

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

[Simon Glass]

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

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

[Tom Rini]

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 :)

-- 
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/20130703/a76e9d88/attachment.pgp>

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

[Robert Nelson]

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,

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

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

[Tom Rini]

On Tue, Jul 02, 2013 at 01:38:43PM +0200, Dirk Eibach wrote:
> Hi Andy,
> 
> > 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.
> 
> my series "[PATCH v7 0/5] Add gdsys ControlCenter Digital board" is
> still missing.
> 
> You can find it here:
> http://patchwork.ozlabs.org/patch/254751/
> http://patchwork.ozlabs.org/patch/254749/
> http://patchwork.ozlabs.org/patch/254748/
> http://patchwork.ozlabs.org/patch/254750/
> http://patchwork.ozlabs.org/patch/254754/

Sorry, this got lost in the noise of the bootm changes.  Both the 4xx
series and 85xx series were posted before the merge window closed.
Andy, Stefan, do you want to pick these up, or do you want me to, or are
there changes needed still?  Thanks!

-- 
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/20130715/db0114a8/attachment.pgp>

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

[Stefan Roese]

Hi Tom,

On 07/15/2013 11:05 PM, Tom Rini wrote:
>>> 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.
>>
>> my series "[PATCH v7 0/5] Add gdsys ControlCenter Digital board" is
>> still missing.
>>
>> You can find it here:
>> http://patchwork.ozlabs.org/patch/254751/
>> http://patchwork.ozlabs.org/patch/254749/
>> http://patchwork.ozlabs.org/patch/254748/
>> http://patchwork.ozlabs.org/patch/254750/
>> http://patchwork.ozlabs.org/patch/254754/
> 
> Sorry, this got lost in the noise of the bootm changes.  Both the 4xx
> series and 85xx series were posted before the merge window closed.
> Andy, Stefan, do you want to pick these up, or do you want me to, or are
> there changes needed still?  Thanks!

Dirk refers to the FSL/85xx series here. The 4xx series is postponed to
after the release as it depends on the I2C rework from Heiko. We agreed
upon Heiko pushing the I2C rework very early in the merge window. Then
Dirk's 4xx series can go in (I'll pull it).

Thanks,
Stefan

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

[Dirk Eibach]

Hi Tom,

my 4xx series depends on Heikos I2C update, which he did not manage to
get ready in this release cycle. But he promised he will push it when
the next merge window opens :)
The 85xx series should be ready to go.

Cheers
Dirk

2013/7/15 Tom Rini <trini@ti.com>:
> On Tue, Jul 02, 2013 at 01:38:43PM +0200, Dirk Eibach wrote:
>> Hi Andy,
>>
>> > 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.
>>
>> my series "[PATCH v7 0/5] Add gdsys ControlCenter Digital board" is
>> still missing.
>>
>> You can find it here:
>> http://patchwork.ozlabs.org/patch/254751/
>> http://patchwork.ozlabs.org/patch/254749/
>> http://patchwork.ozlabs.org/patch/254748/
>> http://patchwork.ozlabs.org/patch/254750/
>> http://patchwork.ozlabs.org/patch/254754/
>
> Sorry, this got lost in the noise of the bootm changes.  Both the 4xx
> series and 85xx series were posted before the merge window closed.
> Andy, Stefan, do you want to pick these up, or do you want me to, or are
> there changes needed still?  Thanks!
>
> --
> Tom

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

[Fleming Andy-AFLEMING]

On Jul 16, 2013, at 1:56, "Dirk Eibach" <dirk.eibach@gdsys.cc> wrote:

> Hi Tom,
> 
> my 4xx series depends on Heikos I2C update, which he did not manage to
> get ready in this release cycle. But he promised he will push it when
> the next merge window opens :)
> The 85xx series should be ready to go.

Ok, I'll put this in today

Andy

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

[Lubomir Popov]

Hi Tom, Marek,

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.

What about Michael's patch

http://patchwork.ozlabs.org/patch/250290/

It is a bug fix actually (and happens to affect two of our boards ;) ).

Thanks,
Lubo