[U-Boot] [PATCH 0/5] Add device tree support for VxWorks
myan
miao.yan at windriver.com
Tue Sep 17 09:44:28 CEST 2013
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
More information about the U-Boot
mailing list