On Wednesday 08 February 2012 09:53 PM, Wolfgang Denk wrote:
Dear Aneesh V,
In message<4f328b41.2050...@ti.com> you wrote:
But since then I changed my mind due to some other factors:
1. 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.
2. 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.
3. 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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
