[U-Boot-Users] [PATCH] Functions added to extern for stand alone programs

[U-Boot-Users] [PATCH] Functions added to extern for stand alone programs

[Jeff Mann]

[PATCH] Functions added to extern for stand alone programs
 
This patch contains updated to the extern files for stand alone
programs:
-Functions have been added to the extern list
-Function order has been modified to group related function together. 
-XF_VERSION  increased to 4
-Function netboot_common changed from static to extern

The patch file is attached

This is the second patch

This feature does not seem to fall into any category in the list of
U-Boot Custodians, so I guess it goes to you, Wolfgang. 

The patch file is attached. 

-Jeffrey Mann
-------------- next part --------------
A non-text attachment was scrubbed...
Name: add_extern_func.patch
Type: application/octet-stream
Size: 7086 bytes
Desc: add_extern_func.patch
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070509/e5310660/attachment.obj 

[U-Boot-Users] [PATCH] Functions added to extern for stand alone programs

[Wolfgang Denk]

In message <1628E43D99629C46988BE46087A3FBB997B7A9@ep-01.EmbeddedPlanet.local> you wrote:
> 
> [PATCH] Functions added to extern for stand alone programs
...
> Content-Transfer-Encoding: base64
> Content-Description: add_extern_func.patch
> Content-Disposition: attachment;
> 	filename=add_extern_func.patch"
> 
> RnJvbSAyMDBhZWNiZjJiM2NlYzA0ZDA5M2RkZGRlMWViNWQxNDA1YmE1ZGVhIE1vbiBTZXAgMTcg
> MDA6MDA6MDAgMjAwMQpGcm9tOiByb290IDxyb290QHVidW50dS4obm9uZSk+CkRhdGU6IFdlZCwg
> OSBNYXkgMjAwNyAxMjo1NjozNSAtMDQwMApTdWJqZWN0OiBbUEFUQ0hdIEZ1bmN0aW9ucyBhZGRl
...

Please post plain text.

...
+#if defined (CONFIG_4xx)	|| defined (CONFIG_MPC5xxx) || defined (CONFIG_74xx_7xx) || \
+    defined (CONFIG_74x)	|| defined (CONFIG_75x)	    || defined (CONFIG_74xx)	 || \
+    defined (CONFIG_MPC8220)|| defined (CONFIG_MPC85xx)	|| defined (CONFIG_MPC86xx)	 || \
+    defined (CONFIG_MPC83XX)
+	gd->jt[XF_out8] = (void *) out8;
+	gd->jt[XF_in8] = (void *) in8;
+	gd->jt[XF_in16] = (void *) in16;
+	gd->jt[XF_out16] = (void *) out16;
+	gd->jt[XF_in32] = (void *) in32;
+	gd->jt[XF_out32] = (void *) out32;
+#endif
+#if (CONFIG_COMMANDS & CFG_CMD_NET)
+	gd->jt[XF_netboot_common] = (void *) netboot_common;
+#endif
+	gd->jt[XF_strcmp] = (void *) strcmp;
+#if (CONFIG_COMMANDS & CFG_CMD_NAND)
+	gd->jt[XF_do_nand] = (void *) do_nand;
+#endif
+#if (CONFIG_COMMANDS & CFG_CMD_DATE)
+	gd->jt[XF_rtc_get] = (void *) rtc_get;
+	gd->jt[XF_do_date] = (void *) do_date;
+#endif
 #if (CONFIG_COMMANDS & CFG_CMD_I2C)
 	gd->jt[XF_i2c_write] = (void *) i2c_write;
 	gd->jt[XF_i2c_read] = (void *) i2c_read;
+	gd->jt[XF_i2c_probe] = (void *) i2c_probe;
 #endif	/* CFG_CMD_I2C */
+#if (CONFIG_COMMANDS & CFG_CMD_USB)
+	gd->jt[XF_usb_init] = (void *) usb_init;
+	gd->jt[XF_usb_stop] = (void *) usb_stop;
+#endif
+#if !defined(CFG_NO_FLASH)
+	gd->jt[XF_flash_write] = (void *) flash_write;
+#endif
+#if (CONFIG_COMMANDS & CFG_CMD_FLASH)
+	gd->jt[XF_do_protect] = (void *) do_protect;
+	gd->jt[XF_do_flerase] = (void *) do_flerase;
+#endif
 }

This #ifdef maze is too much even for my  standards.  And  that  does
mean something.

Is there anybody out there with an idea how to avoid that?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,    CEO: 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
If something is different, it's either better or worse,  and  usually
both.                                                    - Larry Wall

[U-Boot-Users] [PATCH] Functions added to extern for stand alone programs

[Amnon Cohen]

my gut feeling is that

        gd->jt[XF_foo]  = foo;

should happen at the end of the file which defines foo.
This would remove the need for external definitions and ifdef mazes.
But it would require some sort of jt_init function to be called in each file.
This could be done using some linker magic (like module initialization
in the kernel, or cli functions in u-boot)...

- Amnon


On 5/9/07, Wolfgang Denk <wd@denx.de> wrote:
> In message <1628E43D99629C46988BE46087A3FBB997B7A9@ep-01.EmbeddedPlanet.local> you wrote:
> >
> > [PATCH] Functions added to extern for stand alone programs
> ...
> > Content-Transfer-Encoding: base64
> > Content-Description: add_extern_func.patch
> > Content-Disposition: attachment;
> >       filename=add_extern_func.patch"
> >
> > RnJvbSAyMDBhZWNiZjJiM2NlYzA0ZDA5M2RkZGRlMWViNWQxNDA1YmE1ZGVhIE1vbiBTZXAgMTcg
> > MDA6MDA6MDAgMjAwMQpGcm9tOiByb290IDxyb290QHVidW50dS4obm9uZSk+CkRhdGU6IFdlZCwg
> > OSBNYXkgMjAwNyAxMjo1NjozNSAtMDQwMApTdWJqZWN0OiBbUEFUQ0hdIEZ1bmN0aW9ucyBhZGRl
> ...
>
> Please post plain text.
>
> ...
> +#if defined (CONFIG_4xx)       || defined (CONFIG_MPC5xxx) || defined (CONFIG_74xx_7xx) || \
> +    defined (CONFIG_74x)       || defined (CONFIG_75x)     || defined (CONFIG_74xx)     || \
> +    defined (CONFIG_MPC8220)|| defined (CONFIG_MPC85xx)        || defined (CONFIG_MPC86xx)      || \
> +    defined (CONFIG_MPC83XX)
> +       gd->jt[XF_out8] = (void *) out8;
> +       gd->jt[XF_in8] = (void *) in8;
> +       gd->jt[XF_in16] = (void *) in16;
> +       gd->jt[XF_out16] = (void *) out16;
> +       gd->jt[XF_in32] = (void *) in32;
> +       gd->jt[XF_out32] = (void *) out32;
> +#endif
> +#if (CONFIG_COMMANDS & CFG_CMD_NET)
> +       gd->jt[XF_netboot_common] = (void *) netboot_common;
> +#endif
> +       gd->jt[XF_strcmp] = (void *) strcmp;
> +#if (CONFIG_COMMANDS & CFG_CMD_NAND)
> +       gd->jt[XF_do_nand] = (void *) do_nand;
> +#endif
> +#if (CONFIG_COMMANDS & CFG_CMD_DATE)
> +       gd->jt[XF_rtc_get] = (void *) rtc_get;
> +       gd->jt[XF_do_date] = (void *) do_date;
> +#endif
>  #if (CONFIG_COMMANDS & CFG_CMD_I2C)
>         gd->jt[XF_i2c_write] = (void *) i2c_write;
>         gd->jt[XF_i2c_read] = (void *) i2c_read;
> +       gd->jt[XF_i2c_probe] = (void *) i2c_probe;
>  #endif /* CFG_CMD_I2C */
> +#if (CONFIG_COMMANDS & CFG_CMD_USB)
> +       gd->jt[XF_usb_init] = (void *) usb_init;
> +       gd->jt[XF_usb_stop] = (void *) usb_stop;
> +#endif
> +#if !defined(CFG_NO_FLASH)
> +       gd->jt[XF_flash_write] = (void *) flash_write;
> +#endif
> +#if (CONFIG_COMMANDS & CFG_CMD_FLASH)
> +       gd->jt[XF_do_protect] = (void *) do_protect;
> +       gd->jt[XF_do_flerase] = (void *) do_flerase;
> +#endif
>  }
>
> This #ifdef maze is too much even for my  standards.  And  that  does
> mean something.
>
> Is there anybody out there with an idea how to avoid that?
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,    CEO: 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
> If something is different, it's either better or worse,  and  usually
> both.                                                    - Larry Wall
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>

[U-Boot-Users] [PATCH] Functions added to extern for stand alone programs

[Jeff Mann]

> > Content-Transfer-Encoding: base64
I apologize, I KNOW I selected 'plain text'. 

> my gut feeling is that
> 
>         gd->jt[XF_foo]  = foo;
> 
>should happen at the end of the file which defines foo.
> This would remove the need for external definitions and ifdef mazes.
> But it would require some sort of jt_init function to be 
> called in each file.
> This could be done using some linker magic (like module 
> initialization in the kernel, or cli functions in u-boot)...

I suppose that is one solution. "Linker magic" is beyond me, but would
be very clean.

> > This #ifdef maze is too much even for my  standards.  And  
> that  does 
> > mean something.

I didn't think it was that maze-like. The ifdefs are NOT nested, and I
gouped all of the functions with the same ifdefs together in a reaonable
order. Also, the ifdefs were removed from _exports.h and exports.h
because they are not needed there, only when initializing the jump table
in exports.c. But yes, that leads to a lot of them. I was just thinking
about this and I was going to propose something else, but I think that
by splitting up the jump table initialization, it gets even messier. 

-JM

[U-Boot-Users] [PATCH] Functions added to extern for stand alone programs

[Håvard Skinnemoen]

On 5/10/07, Wolfgang Denk <wd@denx.de> wrote:
> +#if (CONFIG_COMMANDS & CFG_CMD_FLASH)
> +       gd->jt[XF_do_protect] = (void *) do_protect;
> +       gd->jt[XF_do_flerase] = (void *) do_flerase;
> +#endif
>  }
>
> This #ifdef maze is too much even for my  standards.  And  that  does
> mean something.
>
> Is there anybody out there with an idea how to avoid that?

The cond_syscall() macro in the Linux kernel might be worth stealing.
How about something like this?

#define cond_extern(name) asm(".weak\t" #name "\n\t.set\t" #name ",
unimpl_extern")

static int unimpl_extern(void)
{
        return -ENOSYS; /* or something more appropriate */
}

cond_extern(do_protect);
cond_extern(do_flerase);

Haavard

[U-Boot-Users] [PATCH] Functions added to extern for stand alone programs

[Jeffrey Mann]

> >
> > This #ifdef maze is too much even for my  standards.  And  that  does
> > mean something.
> >
> > Is there anybody out there with an idea how to avoid that?
>
> The cond_syscall() macro in the Linux kernel might be worth stealing.
> How about something like this?
>
> #define cond_extern(name) asm(".weak\t" #name "\n\t.set\t" #name ",
> unimpl_extern")

I do not understand what this does. Does it work?

> static int unimpl_extern(void)
> {
>         return -ENOSYS; /* or something more appropriate */
> }

How is this different that using the dummy function?

> cond_extern(do_protect);
> cond_extern(do_flerase);
>

-Jeff

[U-Boot-Users] [PATCH] Functions added to extern for stand alone programs

[Wolfgang Denk]

In message <e68c55e80705231251s678d3e59g2db9ed3da3fce830@mail.gmail.com> you wrote:
>
> > #define cond_extern(name) asm(".weak\t" #name "\n\t.set\t" #name ",
> > unimpl_extern")
> 
> I do not understand what this does. Does it work?

Yes, it does. See file: gcc.info,  node: Function Attributes,
section: 5.24 Declaring Attributes of Functions

> > static int unimpl_extern(void)
> > {
> >         return -ENOSYS; /* or something more appropriate */
> > }
> 
> How is this different that using the dummy function?

The main difference is that with "normal"  functions  you  must  make
sure  that the dummy function does not get compiled / linked when you
implement a real function. "Weak" are simply overwritten if any  user
provides  another  (real) function with the same name. No #ifdef mess
any more :-)

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
I'm a programmer: I don't buy software, I write it.
                                                  -- Tom Christiansen

[U-Boot-Users] [PATCH] Functions added to extern for stand alone programs

[Jeffrey Mann]

> >
> > > #define cond_extern(name) asm(".weak\t" #name "\n\t.set\t" #name ",
> > > unimpl_extern")
> >
> > I do not understand what this does. Does it work?
>
> Yes, it does. See file: gcc.info,  node: Function Attributes,
> section: 5.24 Declaring Attributes of Functions
>
> > > static int unimpl_extern(void)
> > > {
> > >         return -ENOSYS; /* or something more appropriate */
> > > }
> >
> > How is this different that using the dummy function?
>
> The main difference is that with "normal"  functions  you  must  make
> sure  that the dummy function does not get compiled / linked when you
> implement a real function. "Weak" are simply overwritten if any  user
> provides  another  (real) function with the same name. No #ifdef mess
> any more :-)



So in practice, it would look something like this?:

void jumptable_init (void)
{
        int i;

        gd->jt = (void **) malloc (XF_MAX * sizeof (void *));
        for (i = 0; i < XF_MAX; i++)
                gd->jt[i] = (void *) dummy;

#define EXPORT_FUNC(name) asm(".weak\t" #name "\n\t.set\t" #name ", dummy");
#include <_exports.h>
#undef EXPORT_FUNC

        gd->jt[XF_get_version] = (void *) get_version;
        gd->jt[XF_malloc] = (void *) malloc;
        gd->jt[XF_free] = (void *) free;
        gd->jt[XF_getenv] = (void *) getenv;
        gd->jt[XF_setenv] = (void *) setenv;
        gd->jt[XF_get_timer] = (void *) get_timer;
        gd->jt[XF_simple_strtoul] = (void *) simple_strtoul;
        gd->jt[XF_udelay] = (void *) udelay;
        gd->jt[XF_install_hdlr] = (void *) irq_install_handler;
        gd->jt[XF_free_hdlr] = (void *) irq_free_handler;
        gd->jt[XF_i2c_write] = (void *) i2c_write;
        gd->jt[XF_i2c_read] = (void *) i2c_read;
      ........

}



it could't really be that simple, could it? I bet my sintax is wrong,
and I still do not compleatly understand how the compiler intreprets
"weak" and "set". But I can see how this would work.

-Jeff

[U-Boot-Users] [PATCH] Functions added to extern for stand alone programs

[Wolfgang Denk]

In message <e68c55e80705231347w76d86bf8o1a1f6001e93f3f72@mail.gmail.com> you wrote:
>
> it could't really be that simple, could it? I bet my sintax is wrong,

Maybe.

> and I still do not compleatly understand how the compiler intreprets
> "weak" and "set". But I can see how this would work.

I never used this assembler trickery before myself. So far, I only
played with the C variant of it. Like that:

-> cat foo.c
#include <stdio.h>

int func(int, int);

int main (void)
{
        int i = func (2, 7);

        printf ("i = %d\n", i);

        return 0;
}
-> cat func.c
#include <stdio.h>

int __func (int a, int b)
{
        printf ("Default func called: %d + %d\n", a, b);

        return (a + b);
}

int func(int a, int b) __attribute__ ((weak, alias ("__func")));
-> cat private.c 
#include <stdio.h>

int func (int a, int b)
{
        printf ("Private func called: %d * %d\n", a, b);

        return (a * b);
}
-> gcc -c *.c
-> gcc -o foo foo.o func.o
-> ./foo
Default func called: 2 + 7
i = 9
-> gcc -o bar foo.o func.o private.o
-> ./bar
Private func called: 2 * 7
i = 14



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
It is a human characteristic to love little  animals,  especially  if
they're attractive in some way.
	-- McCoy, "The Trouble with Tribbles", stardate 4525.6

[U-Boot-Users] [PATCH] Functions added to extern for stand alone programs

[Jeff Mann]

> 
> On 5/24/07, Wolfgang Denk <wd@denx.de> wrote:
> > I never used this assembler trickery before myself. So far, I only 
> > played with the C variant of it. Like that:
> 
> I just tried to imitate the cond_syscall() macro in the Linux kernel.
> Your C variant is perhaps better than the asm trickery --
> cond_syscall() is defined in asm/unistd.h so I suppose it 
> might be arch-specific. The attribute syntax is of course 
> gcc-specific, but u-boot doesn't support other compilers 
> anyway, does it?
> 

The problem I ran into with the C variant was with type conflicts of the function declarations and argument conflicts that I could not find a clean solution to. Without these type conflicts it would have worked.

-Jeff