[U-Boot] [PATCH 0/5] Add device tree support for VxWorks

[myan <miao.yan@windriver.com>]

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