From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rafal Jaworowski Date: Mon, 04 Aug 2008 15:30:08 +0200 Subject: [U-Boot-Users] [PATCH] API: Optimize signature searching scheme in the glue layer. In-Reply-To: <20080804125020.894F624848@gemini.denx.de> References: <20080804125020.894F624848@gemini.denx.de> Message-ID: <48970460.2040701@semihalf.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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