In message 200509041336.52311.pantelis.antoniou@gmail.com you wrote:
Where is this done? I don't see it. And "after" does not help - an old kernel is still expecting it right at the address pointed to by r3.
A new kernel detects a OF flat tree by the magic signature, and fallbacks to bd_t in that case.
Yes - but what about old kernels?
- CONFIG_OF_FLAT_TREE is not defined; we pass a bd_t to the kernel, and everything is as before. Only kernels expecting an bd_t can be booted.
No, newer kernels detect that the OF tree is missing and use the bd_t as before.
OK. So an old version of U-Boot is compatible with old and new kernels. At least for some transition period. Good.
- CONFIG_OF_FLAT_TREE is defined; we pass an OF tree to the kernel. No backward compatibility is provided: kernels expecting an bd_t will crash miserably. Only kernels expecting an OF tree can be booted.
There is a reason for that. As you well know as per the ppc64 docs
No matter what the reason is... It is an indispensable practical requirement that we will have to be able to install a version of U-Boot on a certain hardware which can boot both old and new kernels.
Yes, but I don't see where the "transition period" is implemented.
I would expect that (when CONFIG_OF_FLAT_TREE is enabled) there is an environment variable that allows to switch between boot interfaces (similar to the clock_in_mhz variable), so that one and the same U-Boot image can boot both older and newer kernels?
Am I missing something?
OK, that's reasonable.
Can you please implement that?
No. A pre-build blob does not contain the full environment. The specs are clear; at least the chosen node must reflect current settings.
It was one of Ben's major arguments in this debate that we might leave out of this OFT building code and just load a small binary blob; IIRC he was talking about less than 0.5 kB ...
Combined patch follows.
Thanks.
...
+#if defined(CONFIG_MPC5xxx)
- BDM(mbar_base),
+#endif
...
+#if defined(CONFIG_MPC5xxx)
- BDM(ipbfreq),
- BDM(pcifreq),
+#endif
Did you just miss this (in which case I will clean it up), or is there any technical reason for not combining these two groups into one?
Best regards,
Wolfgang Denk