Dear Myan,
In message 5237BB0B.1000309@windriver.com you wrote:
Hello Wolfgang,
You intend to 1) just keep the existing 'bootvx' command for compatibility with older VxWorks versions, and 2) use plain 'bootm' for new versions, like we do for other OSes?
Yes, this is what I intended to implement, sorry for not being more clear. The pesdo-code is like this:
int do_bootm_vxworks(bootm_headers_t *images) { if (images->ft_addr) do_bootvx_fdt(images); else do_bootvx(NULL, 0, 0, NULL); }
So 'bootm' works with new versions of VxWorks if device tree blob is provided, otherwise it falls back to 'bootvx'.
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.
The original idea was to separate 'bootvx' from 'bootm' entirely, but I am not sure how many users out there that depend on the old behavior, so I am inclined to keep it and not break 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.
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?
Best regards,
Wolfgang Denk