Wolfgang Denk wrote: > In message <[EMAIL PROTECTED]> 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 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
