[U-Boot-Users] [PATCH] API: Optimize signature searching scheme in the glue layer.

[U-Boot-Users] [PATCH] API: Optimize signature searching scheme in the glue layer.

[Rafal Jaworowski]

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.

Signed-off-by: Rafal Czubak <rcz@semihalf.com>
Signed-off-by: Rafal Jaworowski <raj@semihalf.com>
---
 api_examples/crt0.S |   17 +++++++++++------
 api_examples/glue.c |   17 ++++++++++++-----
 api_examples/glue.h |    6 +++---
 3 files changed, 26 insertions(+), 14 deletions(-)

diff --git a/api_examples/crt0.S b/api_examples/crt0.S
index 8d4f706..80b7297 100644
--- a/api_examples/crt0.S
+++ b/api_examples/crt0.S
@@ -24,14 +24,16 @@
  */
 
 #if defined(CONFIG_PPC)
-
 	.text
 
 	.globl _start
 _start:
+	/* Store global data ptr as a hint for U-Boot address range */
+	lis	%r11, gd_ptr at ha
+	addi	%r11, %r11, gd_ptr at l
+	stw	%r2, 0(%r11)
 	b	main
 
-
 	.globl syscall
 syscall:
 	lis	%r11, syscall_ptr at ha
@@ -39,12 +41,15 @@ syscall:
 	lwz	%r11, 0(%r11)
 	mtctr	%r11
 	bctr
-
+#else
+#error No support for this arch!
+#endif
 
 	.globl syscall_ptr
 syscall_ptr:
 	.align	4
 	.long	0
-#else
-#error No support for this arch!
-#endif
+
+	.globl gd_ptr
+gd_ptr:
+	.long	0
diff --git a/api_examples/glue.c b/api_examples/glue.c
index 2bf47ae..7218b86 100644
--- a/api_examples/glue.c
+++ b/api_examples/glue.c
@@ -1,5 +1,5 @@
 /*
- * (C) Copyright 2007 Semihalf
+ * (C) Copyright 2007-2008 Semihalf
  *
  * Written by: Rafal Jaworowski <raj@semihalf.com>
  *
@@ -57,16 +57,23 @@ static int valid_sig(struct api_signature *sig)
  *
  * returns 1/0 depending on found/not found result
  */
-int api_search_sig(struct api_signature **sig) {
-
+int api_search_sig(struct api_signature **sig)
+{
 	unsigned char *sp;
+	uint32_t start = 0, end = 0;
 
 	if (sig == NULL)
 		return 0;
 
-	sp = (unsigned char *)API_SEARCH_START;
+	if (gd_ptr == NULL)
+		return 0;
+
+	/* Global data ptr helps to narrow down the search range */
+	start = (uint32_t)gd_ptr & ~(API_SEARCH_LEN - 1);
+	end = start + API_SEARCH_LEN - API_SIG_MAGLEN;
 
-	while ((sp + (int)API_SIG_MAGLEN) < (unsigned char *)API_SEARCH_END) {
+	sp = (unsigned char *)start;
+	while ((sp + API_SIG_MAGLEN) < (unsigned char *)end) {
 		if (!memcmp(sp, API_SIG_MAGIC, API_SIG_MAGLEN)) {
 			*sig = (struct api_signature *)sp;
 			if (valid_sig(*sig))
diff --git a/api_examples/glue.h b/api_examples/glue.h
index a82f783..76cb580 100644
--- a/api_examples/glue.h
+++ b/api_examples/glue.h
@@ -30,11 +30,11 @@
 #ifndef _API_GLUE_H_
 #define _API_GLUE_H_
 
-#define API_SEARCH_START	(255 * 1024 * 1024)	/* start@1MB below top RAM */
-#define API_SEARCH_END		(256 * 1024 * 1024 - 1)	/* ...and search to the end */
+#define API_SEARCH_LEN	(2 * 1024 * 1024)	/* 2MB search range */
 
 int	syscall(int, int *, ...);
-void *	syscall_ptr;
+extern void *syscall_ptr;
+extern gd_t *gd_ptr;
 
 int	api_search_sig(struct api_signature **sig);
 
-- 
1.5.2.2

[U-Boot-Users] [PATCH] API: Optimize signature searching scheme in the glue layer.

[Wolfgang Denk]

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, ...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Man is the best computer we can put aboard a spacecraft ...  and  the
only one that can be mass produced with unskilled labor.
                                                 -- Wernher von Braun

[U-Boot-Users] [PATCH] API: Optimize signature searching scheme in the glue layer.

[Rafal Jaworowski]

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

[U-Boot-Users] [PATCH] API: Optimize signature searching scheme in the glue layer.

[Wolfgang Denk]

In message <48970460.2040701@semihalf.com> you wrote:
>
> 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.

I think this is pretty unreliable.

> 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?

I don't know exactly what other architectures are doing. In any case,
you try to build logic on some implementation as  it  happens  to  be
right  now,  but  since  this  is  nowhere  an  officially documented
interface - it can change any time without warning. To be  honest,  I
am  not even sure if the GD data get copied to RAM on PowerPC, and if
so, if it's done on all of them.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Put your Nose to the Grindstone!
                 -- Amalgamated Plastic Surgeons and Toolmakers, Ltd.