Sorry, I don't think I realized you were going to be using the EVM. I thought you had your own hardware... That being the case it is probably a better idea to use the version of UBL specifically created for the EVM. A few more data points:
- There are several differences on the EVMs. I haven't done a precise comparison, but at a minimum we see the input clocks are different and it looks like there's a difference related to some of the video devices on the board too (THS8200).
- I compared the clock settings you mentioned. I agree with the change you made for PLL1_Mult. That matches up with the numbers in the other package. The code is structured slightly different, i.e. they use the raw value (29) which gets programmed into the register while the code you're currently using has the multipler (i.e. PLLM+1) and it subtracts one when writing to the register.
- There are differences between PLL1Div4_ratio in the two code bases. Both appear to be within spec, though I'm not sure what other things in the software might potentially rely on that frequency. So likely better to go with the version that was validated specifically on DM6467T.
- For the DDR settings, I didn't get a chance to see if both EVMs are using the exact same device. Let's assume that's the case for a moment. If you simply want to slow down the clock then all the parameters would still be correct with the one exception of the refresh interval. The register value for that one would need to be reduced, because otherwise with the longer clock period you will have too much time between refresh intervals. Everything else would simply become more conservative and can be left alone.
So in the end I expect you can take either path though neither one is perfect. With the new knowledge that you're using the EVM I think I would recommend trying to use the version that was tested for the EVM (flash-utilis-dm646x). At least in that scenario the only thing we're "fighting" is the installation of perl. If you go the other route there may be a bunch of run-time dependencies that will be tougher to debug.
Sorry to change direction midstream. I hope you didn't spend too much time going down the other path!