On 01/01/14 06:50, Ma Haijun wrote:
The only difference is below, and Tim Fletcher's is the larger one
$ diff *.dts
587a588
                        ts-attached = <0x0>;
Seem the problem is that there is no enough reserved space to add the
required nodes.

After some investigation, I've found a bug in the u-boot's PSCI code. Since
this feature is introduced by  Marc Zyngier, I add him to the cc list.

Currently, PSCI's fdt node is added in bootm's go subcommand by
armv7_update_dt, but I think the proper place is the prep command.
There are 2 reasons for my proposed change.
1. It is not compatible with falcon's spl command, which expect everything
is ready at prep stage, this may be not a big issue, because falcon boot
mode  is not enabled on sunxi7i boards, and the PSCI patch currently does
not take falcon mode into consideration anyway.
2. It cannot reliably add the nodes as in Tim Fletcher's case.

Currently, u-boot basically does these things to setup fdt:
boot_relocate_fdt reserves CONFIG_SYS_FDT_PAD extra bytes, which should be
enough for all fdt changes.
image_setup_libfdt  do the necessary changes, and call fdt_resize to shrink
to  its actual size plus some bytes for its internal use, plus paddings to
page boundary.
Then armv7_update_dt calls fdt_resize again (??), add add PSCI nodes to the
tree.
That means armv7_update_dt works by chance: if there is not enough padding,
it will fail.

I think armv7_update_dt should be invoked in image_setup_libfdt. There are
already some arch/board specific hooks in it, namely arch_fixup_memory_node
and ft_board_setup, maybe we can add another one, or just use one of them.
And the fdt_resize call in armv7_update_dt should be removed.

Thanks for looking into this, means I'm not going totally mad :)

Just as another data point I have done a full rebuild from a fresh checkout of Hans's latest github tree and I have the same -38 error.

The u-boot environment that I am using is the standard one from the next tree that Hans maintains, and having done a env default ; env save I still get only a single CPU.

Is there anything that you would like me to try in terms of making my u-boot env bigger / smaller to see if we can confirm the bug?

--
Tim Fletcher <[email protected]>

--
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to