[U-Boot-Users] Code duplication...

[U-Boot-Users] Code duplication...

[Robin Getz]

I was looking to try to prune the code size of U-Boot down a bit, and noticed with:

rgetz at imhotep:~/u-boot> bfin-elf-nm u-boot | grep " [tT] " | awk '{ print $3}' | sort |  uniq -c | grep -v " 1 "

      3 ___fswab16   (12 bytes each)
      6 ___fswab32   (36 bytes each)
      2 _NetCopyIP   ( 6 bytes each)
      2 _NetWriteIP  (22 bytes each)
      2 _zalloc      (12 bytes each)
      2 _zfree       ( 6 bytes each)

because these functions are included in .h files, as functions:

include/linux/byteorder/swab.h

static __inline__ __attribute__((const)) __u16 __fswab16(__u16 x)
{
        return __arch__swab16(x);
}

And when compiling with gcc -Os, __inline__  is a suggestion, not a requirement.

From:
http://gcc.gnu.org/onlinedocs/gcc-4.2.0/gcc/Function-Attributes.html

always_inline
    Generally, functions are not inlined unless optimization is specified. 
    For functions declared inline, this attribute inlines the function even 
    if no optimization level was specified. 

http://gcc.gnu.org/onlinedocs/gcc-4.2.0/gcc/Inline.html#Inline makes the suggestion:

The combination of inline and extern has almost the effect of a macro. The way 
to use it is to put a function definition in a header file with these 
keywords, and put another copy of the definition (lacking inline and 
extern) in a library file. The definition in the header file will cause 
most calls to the function to be inlined. If any uses of the function
remain, they will refer to the single copy in the library.

Today - they get included in every .o file which includes it, and when the link happens, duplicates are not removed.

For grep ___fswab16 * -R, I get
Binary file net/bootp.o matches
Binary file net/tftp.o matches
Binary file net/net.o matches

and bfin-elf-objdump -d net/libnet.a | grep "___fswab16>:" tells me:

00000000 <___fswab16>:
00000000 <___fswab16>:
00000000 <___fswab16>:

it was included 3 times from the three .o files.

First question is - does anyone see the same thing on their platform - or is it something wonky with my toolchain.

Next question is - for a savings of 250 bytes, does anyone care?

-Robin

[U-Boot-Users] Code duplication...

[Wolfgang Denk]

Dear Robin,

in message <200706221732.15501.rgetz@blackfin.uclinux.org> you wrote:
> 
> First question is - does anyone see the same thing on their platform - or is it something wonky with my toolchain.

Yes, I see the same thing on PPC etc.

> Next question is - for a savings of 250 bytes, does anyone care?

Yes, I do.

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
The human mind ordinarily operates at only ten percent of its capaci-
ty - the rest is overhead for the operating system.

[U-Boot-Users] Code duplication...

[Kim Phillips]

On Fri, 22 Jun 2007 17:32:15 -0400
Robin Getz <rgetz@blackfin.uclinux.org> wrote:

> First question is - does anyone see the same thing on their platform - or is it something wonky with my toolchain.

NetCopyIP and NetWriteIP are duped on mpc83xx.

> Next question is - for a savings of 250 bytes, does anyone care?
> 
"bean by bean the bag fills" (or empties in this case :).

Kim

[U-Boot-Users] Code duplication...

[Håvard Skinnemoen]

On 6/22/07, Robin Getz <rgetz@blackfin.uclinux.org> wrote:
> And when compiling with gcc -Os, __inline__  is a suggestion, not a requirement.

It's a suggestion no matter if you use -Os or not. But -Os makes the
inlining limits so low that it actually tends to increase the size of
the program...

I haven't looked specifically at u-boot, but I've seen the same issue
in other projects I've been running on avr32. Tweaking the limits
using --param max-inline-insns-single and --param
max-inline-insns-auto often makes the code smaller and faster.

IIRC, a limit somewhere between 16 and 32 yields good results when
optimizing for size. The optimum value may be architecture-dependent
of course...

> First question is - does anyone see the same thing on their platform - or is it something wonky with my toolchain.

Yes, I think it's a general problem.

> Next question is - for a savings of 250 bytes, does anyone care?

Saving 250 bytes _and_ making the code run faster sounds like a good
deal to me :-)

Haavard

[U-Boot-Users] MPC8439E + Marvell 888E1111 (blah!)

[David Hawkins]

Hi all,

I'm designing an MPC8349E-based board. I'll be
working on the PCB layout starting next week.

To minimize my porting effort for both U-Boot and
Linux, I decided to copy the MPC8349E-MDS-PB reference
design and use the Marvell 888E1111 gigabit transceiver
for the network interface.

I find that the Marvell chipset documents are proprietary
and require the signing of an NDA to access.

Now, I can go ahead and do this, but it offends my sense
of 'openness'. I plan to release the design of the board
and all its software when I'm done, so it irks me to
select a datasheet that is hidden.

I haven't looked at all the Freescale reference boards,
so its possible there are different GbE transceivers on
other boards.

I know that I could probably use any number of
chipsets, however, my original intent was to
minimize my software effort.

I anyone has a recommendation for an alternative
I'd be interested in hearing about it. Unfortunately
I do need the speed of GbE, so 100Mbit interfaces
won't cut-it.

Freescale guys; Kim, Timur, any other reference
designs that perhaps I should take a look at.

Network guys; whats a popular interface that I shouldn't
have any trouble getting to work with the 8349E?

I'll go track down the ITX board documents and see
what it has on it ...

Cheers!
Dave

[U-Boot-Users] MPC8439E + Marvell 888E1111 (blah!)

[David Hawkins]

> 
> Freescale guys; Kim, Timur, any other reference
> designs that perhaps I should take a look at.
> 
> Network guys; whats a popular interface that I shouldn't
> have any trouble getting to work with the 8349E?
> 
> I'll go track down the ITX board documents and see
> what it has on it ...

So it looks like the ITX uses a Vitesse VSC8201, which
has a nice web page with all the documents! Yeah.

http://www.vitesse.com/products/product.php?number=VSC8201

Anyone have anything good, or bad to say about these
parts, any other options I should consider?

Thanks!
Dave

[U-Boot-Users] MPC8439E + Marvell 888E1111 (blah!)

[David Hawkins]

> 
> So it looks like the ITX uses a Vitesse VSC8201, which
> has a nice web page with all the documents! Yeah.
> 
> http://www.vitesse.com/products/product.php?number=VSC8201
> 
> Anyone have anything good, or bad to say about these
> parts, any other options I should consider?

I typed too soon, it looks like I was wrong about the NDA.
Vitesse also requires an NDA on record for some of their
documents.

In addition, the Vitesse part would to be too large for
the space I have on the PCB ... you can see the Marvel
part here in a dump from the Allegro PCB tool;

http://www.ovro.caltech.edu/~dwh/carma_board/allegro.pdf

Just too many darn FPGAs on this cPCI board :)

Ah well, I might have to just use the Marvell part.

Sorry for the noise :)
Dave

[U-Boot-Users] MPC8439E + Marvell 888E1111 (blah!)

[Andy Fleming]

On 6/22/07, David Hawkins <dwh@ovro.caltech.edu> wrote:
> Hi all,
>
> I'm designing an MPC8349E-based board. I'll be
> working on the PCB layout starting next week.
>
> To minimize my porting effort for both U-Boot and
> Linux, I decided to copy the MPC8349E-MDS-PB reference
> design and use the Marvell 888E1111 gigabit transceiver
> for the network interface.

You might want to look at the ITX design.  It's simpler.  The MDS/PB
design is fairly modular, and might be more complicated than what you
want.  But obviously, you would be the best judge of what you want
your board to do.


>
> I find that the Marvell chipset documents are proprietary
> and require the signing of an NDA to access.

Yeah, that seems to be a trend for PHY manufacturers.  Don't read this
as an endorsement (I've not used it before), but
http://www.national.com/pf/DP/DP83865.html is supported in u-boot, and
looks like you can get the documentation with no restrictions (I
downloaded the docs just a second ago).

Also, you don't need to worry too much about which PHY you use from a
software standpoint.  Many PHYs follow the 802.11 spec, and both
u-boot and Linux have generic drivers which are used by default for
unknown PHYs.  I frequently forget to enable my PHY driver in my
kernel builds, and almost never have a problem.

So you might just need to find a PHY, and make sure it doesn't require
any special initialization or configuration.  Most PHYs should fall
into that category.

And even if it does, the tsec/gianfar drivers for the ethernet on the
83xx have good (I think) infrastructure for using different PHYs, and
the average PHY driver requires very little in the way of code.

Andy

[U-Boot-Users] MPC8439E + Marvell 888E1111 (blah!)

[David Hawkins]

Hi Andy,

>> To minimize my porting effort for both U-Boot and
>> Linux, I decided to copy the MPC8349E-MDS-PB reference
>> design and use the Marvell 888E1111 gigabit transceiver
>> for the network interface.
> 
> You might want to look at the ITX design.  It's simpler.  The MDS/PB
> design is fairly modular, and might be more complicated than what you
> want.  But obviously, you would be the best judge of what you want
> your board to do.
>>
>> I find that the Marvell chipset documents are proprietary
>> and require the signing of an NDA to access.
> 
> Yeah, that seems to be a trend for PHY manufacturers.

After looking for alternatives, I started to get that feeling.

> Don't read this as an endorsement (I've not used it before), but
> http://www.national.com/pf/DP/DP83865.html is supported in u-boot, and
> looks like you can get the documentation with no restrictions (I
> downloaded the docs just a second ago).

Great! I can learn a little more about these types of parts.

> Also, you don't need to worry too much about which PHY you use from a
> software standpoint.  Many PHYs follow the 802.11 spec, and both
> u-boot and Linux have generic drivers which are used by default for
> unknown PHYs.  I frequently forget to enable my PHY driver in my
> kernel builds, and almost never have a problem.

Ok, good to know. I'd figured that was probably the case from
just general reading of PHY related questions/answers on the list.

> So you might just need to find a PHY, and make sure it doesn't require
> any special initialization or configuration.  Most PHYs should fall
> into that category.
> 
> And even if it does, the tsec/gianfar drivers for the ethernet on the
> 83xx have good (I think) infrastructure for using different PHYs, and
> the average PHY driver requires very little in the way of code.

Thanks! Just the sort of useful feedback I wanted :)

Its always a bit of a tradeoff; copying the design of a known-good
system (i.e., one that can be compared to when things don't work on
your new board!), and component features.

For example, the size of Marvell part on the MDS reference board
(BGA package) is 10mmx14mm, whereas the National part in a PQFP
package is 17x23mm. The Marvell part can take a 125MHz clock, but
the National can only use 25MHz. It turns out that I have use
for 125MHz elsewhere on my board ...

Out of interest, how does signing an NDA to get a data sheet
affect one's ability to write open-source software for the part?
For example, I'll need to sign an NDA to get the electrical and
mechanical characteristics of the Marvell part ... but then
I'd be hard-pressed not to look at the software features of
the device wouldn't I :) . Of course, the fact that the driver
already exists for this part means that the dilemma has already
been faced by someone else.

I guess I'll look at the terms of the NDA and see if it says
anything in there.

Ah well, back to my schematics then :)

Thanks,
Dave

[U-Boot-Users] Code duplication...

[Robin Getz]

On Fri 22 Jun 2007 18:16, Wolfgang Denk pondered:
> Robin Getz wrote:
> > Next question is - for a savings of 250 bytes, does anyone care?
> 
> Yes, I do.

Does that mean you want to fix it, or want a patch? (Either is OK with me).

-Robin

[U-Boot-Users] Code duplication...

[Stefan Roese]

Hi Robin,

On Monday 25 June 2007, Robin Getz wrote:
> > > Next question is - for a savings of 250 bytes, does anyone care?
> >
> > Yes, I do.
>
> Does that mean you want to fix it, or want a patch? (Either is OK with me).

Please send a patch to fix this code duplication problem.

Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot-Users] Code duplication...

[Wolfgang Denk]

In message <200706250033.36796.rgetz@blackfin.uclinux.org> you wrote:
> On Fri 22 Jun 2007 18:16, Wolfgang Denk pondered:
> > Robin Getz wrote:
> > > Next question is - for a savings of 250 bytes, does anyone care?
> > 
> > Yes, I do.
> 
> Does that mean you want to fix it, or want a patch? (Either is OK with me).

I'd appreciate a patch.

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
Speed of a tortoise breaking the sound barrier         = 1 Machturtle

[U-Boot-Users] MPC8439E + Marvell 888E1111 (blah!)

[Timur Tabi]

David Hawkins wrote:

> So it looks like the ITX uses a Vitesse VSC8201, which
> has a nice web page with all the documents! Yeah.
> 
> http://www.vitesse.com/products/product.php?number=VSC8201

The ITX has the 8201 and the 7385.  The 7385 is proprietary.  However, the ITX-GP only has 
the 8201.

> Anyone have anything good, or bad to say about these
> parts, any other options I should consider?

I wrote the U-Boot code to support these boards, and the networking stuff was pretty much 
99% done with existing code, so the 8201 looks like it's very well supported.

Also, I personally think the ITX's board header file is nicer than the one for the 
8349EMDS.  :-)

-- 
Timur Tabi
Linux Kernel Developer @ Freescale