On Tue, Jul 9, 2013 at 2:00 PM, Simon Glass sjg@chromium.org wrote:
Hi Tom,
On Tue, Jul 9, 2013 at 10:01 AM, Tom Rini trini@ti.com wrote:
On Mon, Jul 08, 2013 at 10:22:13AM -0400, Tom Rini wrote:
On Mon, Jul 08, 2013 at 09:17:10AM -0500, Robert Nelson wrote:
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}
Ah-ha! It's an appended dtb vs not problem now. I can boot my beagelbone with with an appended dtb and bootz, but can't with separate.
OK, the BOOTM_STATE_FINDOTHER state code isn't working since we don't have the rest of the header bits that the code checks for set. I've taken a few stabs at reworking things, but it's not working yet. Simon, do you have any ideas here? I'm starting to wonder if we don't need to revert things afterall and sort this out post release.
Yes time is running short. I did post two reverts - I wonder if they are effective for this problem?
Is the appended dtb with bootz the only problem remaining as far as we know? If so then perhaps we are close.
Close.. It's the 'non appended dtb case'...
bootz ${loadaddr} - ${fdt_addr}
It's almost as if bootz doesn't have the location of the dtb binary in memory...
I will see if I can get a Beaglebone today or failing that I should be able to try bootz with appeneded dtb on another ARM board.
Regards,