[U-Boot-Users] [PATCH] Fix relocation problem with "new" get_dev() function

[U-Boot-Users] [PATCH] Fix relocation problem with "new" get_dev() function

[Stefan Roese]

This patch enables the "new" get_dev() function for block devices
introduced by Grant Likely to be used on systems that still suffer
from the relocation problems (manual relocation neede because of
problems with linker script).

Hopefully we can resolve this relocation issue soon for all platform
so we don't need this additional code anymore.

Signed-off-by: Stefan Roese <sr@denx.de>

---
commit 751bb57107d78978ae08e697c3deba816f5be091
tree 07d9ef94782dadb04203d8f46dd08da5d08a2aa7
parent d93e2212f962668b3dce091ff5edc33f2347fe37
author Stefan Roese <sr@denx.de> Tue, 20 Feb 2007 13:21:57 +0100
committer Stefan Roese <sr@denx.de> Tue, 20 Feb 2007 13:21:57 +0100

 disk/part.c |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/disk/part.c b/disk/part.c
index f1026c5..37bba77 100644
--- a/disk/part.c
+++ b/disk/part.c
@@ -64,13 +64,25 @@ static const struct block_drvr block_drvr[] = {
 	{ },
 };
 
+#ifndef CFG_FIXUP_RELOCATION
+DECLARE_GLOBAL_DATA_PTR;
+#endif
+
 block_dev_desc_t *get_dev(char* ifname, int dev)
 {
 	const struct block_drvr *drvr = block_drvr;
 
 	while (drvr->name) {
+#ifndef CFG_FIXUP_RELOCATION
+		block_dev_desc_t* (*reloc_get_dev)(int dev);
+
+		reloc_get_dev = drvr->get_dev + gd->reloc_off;
+		if (strncmp(ifname, drvr->name, strlen(drvr->name)) == 0)
+			return reloc_get_dev(dev);
+#else
 		if (strncmp(ifname, drvr->name, strlen(drvr->name)) == 0)
 			return drvr->get_dev(dev);
+#endif
 		drvr++;
 	}
 	return NULL;

[U-Boot-Users] [PATCH] Fix relocation problem with "new" get_dev() function

[Grant Likely]

On 2/20/07, Stefan Roese <sr@denx.de> wrote:
> This patch enables the "new" get_dev() function for block devices
> introduced by Grant Likely to be used on systems that still suffer
> from the relocation problems (manual relocation neede because of
> problems with linker script).
>
> Hopefully we can resolve this relocation issue soon for all platform
> so we don't need this additional code anymore.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
>
> ---
> +#ifndef CFG_FIXUP_RELOCATION
> +               block_dev_desc_t* (*reloc_get_dev)(int dev);
> +
> +               reloc_get_dev = drvr->get_dev + gd->reloc_off;
> +               if (strncmp(ifname, drvr->name, strlen(drvr->name)) == 0)
> +                       return reloc_get_dev(dev);
> +#else
>                 if (strncmp(ifname, drvr->name, strlen(drvr->name)) == 0)
>                         return drvr->get_dev(dev);
> +#endif

The changes look good, but I would drop the CFG_FIXUP_RELOCATION
macros for now.  Just fix it up unconditionally and let the patch that
actually fixes relocation add them back in.

I know it doesn't hurt anything to have them in now; but I think the
current relocation patch takes the wrong approach.  That patch assumes
that relocation is busted unless the board config says it isn't.
Since this is something that we want to fix correctly; I think it is
better to add a '#define CONFIG_RELOCATION_BROKEN' to all board
configs files now; and steadly remove them as different ports are
fixed.

At first glance this looks like a bad idea because it means every
board config file must be touched; but every config file needs to be
touched regardless.  Either:
a) touch every config file now (by adding the "IT'S BROKEN" define; or
b) touch every config file later (by removing the "IT'S FIXED" define
when all board ports are working and the hooks are no longer needed).

Thoughts?
g.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] [PATCH] Fix relocation problem with "new" get_dev() function

[Stefan Roese]

On Wednesday 21 February 2007 18:01, Grant Likely wrote:
> On 2/20/07, Stefan Roese <sr@denx.de> wrote:
> > This patch enables the "new" get_dev() function for block devices
> > introduced by Grant Likely to be used on systems that still suffer
> > from the relocation problems (manual relocation neede because of
> > problems with linker script).
> >
> > Hopefully we can resolve this relocation issue soon for all platform
> > so we don't need this additional code anymore.
> >
> > Signed-off-by: Stefan Roese <sr@denx.de>
> >
> > ---
> > +#ifndef CFG_FIXUP_RELOCATION
> > +               block_dev_desc_t* (*reloc_get_dev)(int dev);
> > +
> > +               reloc_get_dev = drvr->get_dev + gd->reloc_off;
> > +               if (strncmp(ifname, drvr->name, strlen(drvr->name)) == 0)
> > +                       return reloc_get_dev(dev);
> > +#else
> >                 if (strncmp(ifname, drvr->name, strlen(drvr->name)) == 0)
> >                         return drvr->get_dev(dev);
> > +#endif
>
> The changes look good, but I would drop the CFG_FIXUP_RELOCATION
> macros for now.  Just fix it up unconditionally and let the patch that
> actually fixes relocation add them back in.

Yes, that does make more sense for now. I'll update my version.

> I know it doesn't hurt anything to have them in now; but I think the
> current relocation patch takes the wrong approach.  That patch assumes
> that relocation is busted unless the board config says it isn't.
> Since this is something that we want to fix correctly; I think it is
> better to add a '#define CONFIG_RELOCATION_BROKEN' to all board
> configs files now; and steadly remove them as different ports are
> fixed.
>
> At first glance this looks like a bad idea because it means every
> board config file must be touched; but every config file needs to be
> touched regardless.  Either:
> a) touch every config file now (by adding the "IT'S BROKEN" define; or
> b) touch every config file later (by removing the "IT'S FIXED" define
> when all board ports are working and the hooks are no longer needed).
>
> Thoughts?

I like this approach, since it seems to be the "right way" to fix this 
problem. Any other ideas on this? Please speak up, since it's quite a big 
change.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
=====================================================================

[U-Boot-Users] [PATCH] Fix relocation problem with "new" get_dev() function

[Grant Likely]

On 2/21/07, Stefan Roese <sr@denx.de> wrote:
> On Wednesday 21 February 2007 18:01, Grant Likely wrote:
> > Since this is something that we want to fix correctly; I think it is
> > better to add a '#define CONFIG_RELOCATION_BROKEN' to all board
> > configs files now; and steadly remove them as different ports are
> > fixed.
> >
> > Thoughts?
>
> I like this approach, since it seems to be the "right way" to fix this
> problem. Any other ideas on this? Please speak up, since it's quite a big
> change.

I'll compose my reply in patch form...  :)

g.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] [PATCH] Fix relocation problem with "new"get_dev() function

[TXEMA LOPEZ]

Hi Grant,
I don?t know if your approach is a better solution if your final intention is to clean up the code from the C files of U-Boot where the relocation is done manually. I think this would be the final goal, so, if the BROKEN or FIXED defines are provisional and only for test proposes I think both are equally valid.

Regards,
Txema.
 -----Mensaje original-----
De: 	u-boot-users-bounces at lists.sourceforge.net [mailto:u-boot-users-bounces at lists.sourceforge.net]  En nombre de Grant Likely
Enviado el:	mi?rcoles, 21 de febrero de 2007 18:01
Para:	Stefan Roese
CC:	U-Boot-Users
Asunto:	Re: [U-Boot-Users] [PATCH] Fix relocation problem with "new"get_dev() function

At first glance this looks like a bad idea because it means every
board config file must be touched; but every config file needs to be
touched regardless.  Either:
a) touch every config file now (by adding the "IT'S BROKEN" define; or
b) touch every config file later (by removing the "IT'S FIXED" define
when all board ports are working and the hooks are no longer needed).

Thoughts?
g.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users