Wolfgang Denk wrote:
In message 12178539203180-git-send-email-raj@semihalf.com you wrote:
De-hard code the range in RAM we search for API signature, which might not be uniform accross architectures and board configurations. Instead use current global_data pointer as a hint to narrow down the range the [malloc'ed] signature could reside.
Which is the exact rationale of this? Note that the GD pointer can point basicly anywhere - some part of dual ported RAM, SRAM, OCM, ...
The idea was to discover the proximity of where to look for the API signature in run-time and only search within some range around it. This way we'd drop static definitions of the search range.
The assumption was that global data should be close enough to U-Boot's malloc area (where the signature is stored) and this works for us on PPC and ARM. Do you see any problems with this approach in general i.e. can it really happen that after relocation we end up with global data stored at distant location than other U-Boot data?
kind regards, Rafal