On Wednesday 08 February 2012 09:53 PM, Wolfgang Denk wrote:
Dear Aneesh V,
In message4F328B41.2050008@ti.com you wrote:
But since then I changed my mind due to some other factors:
- Difficulty in debugging. I use JTAG debuggers. The workarounds
available are still painful and not many people know about it.
We use JTAG debuggers all day, and have been doing so for well over 10 years. All development of PPCBoot nad U-Boot has been done withJTAG debuggers. Relocation has never been a real problem here.
Reasinf the manual may help - this is documented in detail there.
This is not a good reason to reconsider.
- On FPGA platform, it was adding a considerable delay (I don't have
the exact number, but that will be in minutes). The u-boot was already scaled down and was doing minimal stuff, but this one could not be removed easily. That's when I created that patch.
What exactly are you talking about here that "was adding a considerable delay" - the memory copy ? Are you really sure about that?
I didn't measure it part by part, but removing relocation gave a noticeable speed-up, this platform is several orders of magnitude slower than the real silicon. So, that should not be surprising.
- Un-necessary complexity without any benefit for our platform. I
Maintaining different configurations of the code that behave differently, that can cause different types of addressing, compile and link and debug issues is also adding complexity. Using a single, well tested approach is one of the benefits even for your platform.
Fair enough. But will the new INITCALL framework help? I haven't really followed the discussions on it. But if, as Graeme claims, all relocation stuff is collected in one place and is easily pluggable then maintainability is not a problem, right?
Maybe, I should stop the arguments now and wait till that framework is a reality.
best regards, Aneesh