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,