Hello Wolfgang,
I think this is not a good idea, for two reasons.
First, it means the behaviour of the "bootm" command is not consistent - with FDT address passed as argument it behaves one way, without it behaves different.
Second, You may want to support images that have the FDT attached or embedded or similar - maybe not now, but I bet such requests will pop up. You cannot do this in your code.
I understand this. The only reason that I did this way is that I am afraid of breaking existing 'bootm' users, but I just searched the mailing, seems that VxWorks volume is rather low, maybe it's OK to separate the two without hurting anyone.
If there is no way to inquire from the image itself wether it is one with FDT support or not (we might even assign a new IH_OS_ type for the new ones?), then it would probably be better to make "bootm" support only the new FDT aware images, and keep "bootvx" as compatibility command to boot older images.
I don't prefer to add a new OS type. It is still VxWorks after all, and with the fact that I am not allowed to disclose any information of the new version (not GA yet) makes it harder to come up with a meaningful name like IH_OS_VXWORKS_xxx. I would prefer to do it as you said, just making 'bootm' work with new versions and keeping 'bootvx' for the older ones. This makes things a lot easier.
On the other hand - what exactly is the difference between both boot ways to start an image? Does the additional address passed for the FDT really hurt old style images, so do we need the differentiation at all?
90% of the 'do_bootvx' function is about bootline setup (storing bootline to random memory locations that totally depend on individual BSP), which doesn't apply to the new kernel (in fact, if not doing right, it will likely result in memory corruption and hang the board). And I don't see a reliable way to distinguish the new and old kernels at runtime. Mixing them would make the code hard to maintain. I'd rather see them separated so we could focus on supporting the new one.
Miao