v2013.07-rc2

U-Boot Tom Rini 7 participants 17 messages Jun 28, 2013 – Jul 16, 2013

Share & tools

Tom Rini

author

2013-06-28 22:12 UTC #0 lore raw

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!

Signature · 8 lines

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>

Robert Nelson

2013-07-01 20:44 UTC #1 lore raw

Quoted 9 lines · 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.

Quoted 3 lines

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:

common/cmd_bootm.c +0 -0

index 02a5013..a0b55ef 100644
@@ -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,

Signature · 2 lines

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

Simon Glass

2013-07-02 07:39 UTC #2 lore raw

Hi Robert,

Quoted 37 lines · Robert Nelson

Quoted 9 lines · 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.
Quoted 3 lines
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:
common/cmd_bootm.c +6 -0
index 02a5013..a0b55ef 100644
@@ -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);

Quoted 2 lines

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

Robert Nelson

2013-07-02 11:41 UTC #3 lore raw

Quoted 42 lines · Simon Glass

Hi Robert,
Quoted 38 lines · Robert Nelson
Quoted 9 lines · 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.
Quoted 3 lines
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:
common/cmd_bootm.c +6 -0
index 02a5013..a0b55ef 100644
@@ -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);

Quoted 5 lines

Quoted 1 line
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,

Signature · 2 lines

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

Robert Nelson

2013-07-02 11:43 UTC #4 lore raw

Quoted 76 lines · Robert Nelson

Quoted 42 lines · Simon Glass
Hi Robert,
Quoted 38 lines · Robert Nelson
Quoted 9 lines · 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.
Quoted 3 lines
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:
common/cmd_bootm.c +6 -0
index 02a5013..a0b55ef 100644
@@ -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);
Quoted 5 lines
Quoted 1 line
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

Quoted 6 lines

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}

Missed the important detail...

Regards,

Signature · 2 lines

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

Simon Glass

2013-07-02 14:15 UTC #5 lore raw

In reply to Robert Nelson

Hi Robert,

Quoted 11 lines · Robert Nelson

Quoted 9 lines · Simon Glass
Hi Robert,
Quoted 5 lines · Robert Nelson
Quoted 3 lines · Tom Rini
Hey all,
I've tagged and pushed v2013.07-rc2. A bit more over the place than

Quoted 2 lines

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
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.

Quoted 2 lines

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Everything should be working right now, but please test. Related to this is the ability to have crytpographically signed images. It's

Quoted 4 lines

Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
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

Quoted 16 lines

Quoted 16 lines
Quoted 16 lines
Quoted 1 line
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:
common/cmd_bootm.c +0 -0
index 02a5013..a0b55ef 100644
@@ -1744,6 +1744,12 @@ static int bootz_start(cmd_tbl_t *cmdtp, int
 flag, int argc,
        int ret;
        void *zi_start, *zi_end;
 

Quoted 7 lines

Quoted 7 lines
common/cmd_bootm.c static int bootz_start(cmd_tbl_t *cmdtp, int · line 1754
Quoted 7 lines
common/cmd_bootm.c +6 -0
+       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,

Quoted 42 lines

Quoted 7 lines
Quoted 3 lines
common/cmd_bootm.c +0 -0
                              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}

Quoted 7 lines

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

Quoted 15 lines

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

Quoted 3 lines

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

Quoted 6 lines

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

Simon Glass

2013-07-03 13:52 UTC #6 lore raw

Hi Robert.

Quoted 116 lines · Simon Glass

Hi Robert,
Quoted 4 lines · Robert Nelson
Quoted 2 lines · Simon Glass
Hi Robert,
Quoted 8 lines
Quoted 8 lines
On Tue, Jul 2, 2013 at 5:44 AM, Robert Nelson <[email protected]
Quoted 5 lines · wrote:
Quoted 3 lines · Tom Rini
Hey all,
I've tagged and pushed v2013.07-rc2. A bit more over the place
than I
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
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.
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Everything should be working right now, but please test. Related to this is the ability to have crytpographically signed images. It's
like
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
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
Quoted 16 lines
Quoted 16 lines
Quoted 16 lines
Quoted 1 line
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:
common/cmd_bootm.c +0 -0
index 02a5013..a0b55ef 100644
@@ -1744,6 +1744,12 @@ static int bootz_start(cmd_tbl_t *cmdtp, int
 flag, int argc,
        int ret;
        void *zi_start, *zi_end;
 
Quoted 7 lines
Quoted 7 lines
common/cmd_bootm.c static int bootz_start(cmd_tbl_t *cmdtp, int · line 1754
Quoted 7 lines
common/cmd_bootm.c +6 -0
+       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,
Quoted 42 lines
Quoted 7 lines
Quoted 3 lines
common/cmd_bootm.c +0 -0
                              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}
Quoted 7 lines
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
Quoted 15 lines
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 ...

Quoted 6 lines

Quoted 3 lines
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

author

2013-07-03 13:56 UTC #7 lore raw

Quoted 124 lines · Simon Glass

Hi Robert.
Quoted 120 lines · Simon Glass
Hi Robert,
Quoted 4 lines · Robert Nelson
Quoted 2 lines · Simon Glass
Hi Robert,
Quoted 8 lines
Quoted 8 lines
On Tue, Jul 2, 2013 at 5:44 AM, Robert Nelson <[email protected]
Quoted 5 lines · wrote:
Quoted 3 lines · Tom Rini
Hey all,
I've tagged and pushed v2013.07-rc2. A bit more over the place
than I
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
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.
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Everything should be working right now, but please test. Related to this is the ability to have crytpographically signed images. It's
like
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
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
Quoted 16 lines
Quoted 16 lines
Quoted 16 lines
Quoted 1 line
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:
common/cmd_bootm.c +0 -0
index 02a5013..a0b55ef 100644
@@ -1744,6 +1744,12 @@ static int bootz_start(cmd_tbl_t *cmdtp, int
 flag, int argc,
        int ret;
        void *zi_start, *zi_end;
 
Quoted 7 lines
Quoted 7 lines
common/cmd_bootm.c static int bootz_start(cmd_tbl_t *cmdtp, int · line 1754
Quoted 7 lines
common/cmd_bootm.c +6 -0
+       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,
Quoted 42 lines
Quoted 7 lines
Quoted 3 lines
common/cmd_bootm.c +0 -0
                              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}
Quoted 7 lines
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
Quoted 18 lines
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)

Quoted 7 lines

Quoted 1 line
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 :)

Signature · 8 lines

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>

Robert Nelson

2013-07-03 14:04 UTC #8 lore raw

In reply to Simon Glass

Quoted 125 lines · Simon Glass

Hi Robert.
Quoted 122 lines · Simon Glass
Hi Robert,
Quoted 117 lines · Robert Nelson
Quoted 49 lines · Simon Glass
Hi Robert,
Quoted 44 lines · Robert Nelson
Quoted 13 lines · 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.
Quoted 4 lines
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:
common/cmd_bootm.c +6 -0
index 02a5013..a0b55ef 100644
@@ -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);
Quoted 5 lines
Quoted 1 line
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)

Quoted 7 lines

Quoted 1 line
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,

Signature · 2 lines

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

Andreas Bießmann

2013-07-02 10:37 UTC #9 lore raw

In reply to Robert Nelson

Hi,

Quoted 10 lines · Robert Nelson

Quoted 9 lines · 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.

Quoted 6 lines

Quoted 3 lines
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

Tom Rini

author

2013-07-02 12:34 UTC #10 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 19 lines · Andreas Bie?mann

Hi,
Quoted 16 lines · Robert Nelson
Quoted 14 lines · 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.

Quoted 5 lines

Quoted 2 lines
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

2013-07-02 12:56 UTC #11 lore raw

Quoted 23 lines · Tom Rini

Quoted 21 lines · Andreas Bie?mann
Hi,
Quoted 18 lines · Robert Nelson
Quoted 10 lines · 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.
Quoted 4 lines
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...

Quoted 6 lines

Quoted 2 lines
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

Dirk Eibach

2013-07-02 11:38 UTC #12 lore raw

In reply to Tom Rini

Hi Andy,

Quoted 3 lines

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

Tom Rini

author

2013-07-15 21:05 UTC #13 lore raw

Quoted 9 lines · Dirk Eibach

Hi Andy,
Quoted 3 lines
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.

Quoted 6 lines

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!

Signature · 8 lines

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>

Stefan Roese

2013-07-16 06:10 UTC #14 lore raw

Hi Tom,

Quoted 14 lines · Tom Rini

Quoted 7 lines
Quoted 3 lines
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.
Quoted 6 lines
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/

Quoted 4 lines

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

Dirk Eibach

2013-07-16 06:55 UTC #15 lore raw

In reply to Tom Rini

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 <[email protected]>:

Quoted 24 lines · Dirk Eibach

Quoted 9 lines
Hi Andy,
Quoted 3 lines
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.
Quoted 6 lines
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

Fleming Andy-AFLEMING

2013-07-16 14:21 UTC #16 lore raw

Quoted 6 lines · 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.

Ok, I'll put this in today

Andy