On Mon, Jul 8, 2013 at 9:13 AM, Tom Rini trini@ti.com wrote:
On Thu, Jul 04, 2013 at 01:26:11PM -0700, Simon Glass wrote:
In the recent bootm refactor, the PREP stage was missing in the bootz command. This causes unpredictable behaviour.
The use of a local variable means that the reset of cmd_bootm.c does not in fact use the same image structure, so remove this.
Also manually set the OS type to Linux, since this is the only possibility at present, and we need to select the right boot function.
Signed-off-by: Simon Glass sjg@chromium.org
With the whole series applied, I still see a hang at: Kernel image @ 0x80200000 [ 0x000000 - 0x3d44a0 ]
Starting kernel ...
Perhaps something to do with how my DDR is not at 0x0 -> 256MiB but 0x80000000 -> 256MiB ?
Tom, which board is that?
These 5 patches just on top of v2013.07-rc2, the panda (non es) (board file) works, but Wand (device tree) is still locking up for me...
Panda (Board file boot)
load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage run mmcargs bootz ${loadaddr}
Panda # load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage reading zImage 3413152 bytes read in 161 ms (20.2 MiB/s) Panda # run mmcargs Panda # bootz ${loadaddr} Kernel image @ 0x82000000 [ 0x000000 - 0x3414a0 ]
Starting kernel ...
Uncompressing Linux... done, booting the kernel. [ 0.000000] Booting Linux on physical CPU 0 [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu
Wandboard (device tree boot)
load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file} run mmcargs bootz ${loadaddr} - ${fdt_addr}
Hit any key to stop autoboot: 0 => load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage 3464448 bytes read in 249 ms (13.3 MiB/s) => load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file} 23571 bytes read in 253 ms (90.8 KiB/s) => run mmcargs => bootz ${loadaddr} - ${fdt_addr} Kernel image @ 0x12000000 [ 0x000000 - 0x34dd00 ]
Starting kernel ... <lockup>
Regards,