[U-Boot] [ANN] v2013.07-rc2
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!
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,
Hi Robert,
On Tue, Jul 2, 2013 at 5:44 AM, Robert Nelson robertcnelson@gmail.comwrote:
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
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,
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,
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-accessespc : [<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/
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-accessespc : [<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
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-accessespc : [<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 :)
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-accessespc : [<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,
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
-----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
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
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
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!
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
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
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
participants (7)
-
Andreas Bießmann -
Dirk Eibach -
Fleming Andy-AFLEMING -
Robert Nelson -
Simon Glass -
Stefan Roese -
Tom Rini