Hi Michael,

In bnx2_fw.h I see the following:

static u32 bnx2_RXP_b06FwBss[(0x13dc/4) + 1] = { 0x0 };

static struct fw_info bnx2_rxp_fw_06 = {
...
        .bss                            = bnx2_RXP_b06FwBss,
...
};

I grepped for the usage of .bss member (grepped for '[.>]bss[^_]')
and it is used only here:

        if (fw->bss) {
                int j;

                for (j = 0; j < (fw->bss_len/4); j++, offset += 4) {
                        REG_WR_IND(bp, offset, fw->bss[j]);
                }
        }

If I understand it correctly, you read zero words one by one from
bnx2_RXP_b06FwBss and writing them into the card. This is very
suboptimal usage of nearly 5k of kernel unswappable memory.

Do you plan to fix it?

Do you have any plans to switch to request_firmware() interface,
which will allow you to avoid keeping firmware in unswappable kernel
memory and thus free ~80k?

$ size bnx2.o
   text    data     bss     dec     hex filename
  52255   81551    6360  140166   22386 bnx2.o
--
vda
-

[ message continues ]

We can compress all the different sections of the firmware.  Currently,
we only compress the biggest chunks and the rest are uncompressed.
These zeros should compress to almost nothing.  But I agree that the

Matching the correct version of the firmware with the driver is the main
issue.


-

[ message continues ]

From: "Michael Chan" <mchan@broadcom.com>

I don't like it because it means people have to setup full initrd's
in order to do network booting with such network cards.

But the days of my opinion mattering on that issue are long gone,
the momentum is just too greatly behind using request_firmware()
across the board, so there is no reason for bnx2 to be any different.
-

[ message continues ]

The bnx2 firmware changes quite frequently.  A new driver quite often
requires new firmware to work correctly.  Splitting them up makes things
difficult for the user.

The firmware in tg3 is a lot more mature and I don't expect it to
change.  I think tg3 is better suited for using request_firmware().

-

[ message continues ]

From: "Michael Chan" <mchan@broadcom.com>

Like I said, I think neither should change and the driver should
-

[ message continues ]

Michael, doesn't a functional-yet-suboptimal firmware exist ? I mean,
just the same principle as we all have kernels, boot CDs, statically
built tools, etc... which run everywhere. If you have such a beast,
maybe it would be a good start to have it in the kernel, and provide
the users with the ability to upgrade the firmware once the system
is able to do more complex things.

Just a thought...

Regards,
Willy

-

[ message continues ]

From: Willy Tarreau <w@1wt.eu>

So let's save 60K instead of 80K.

I mean, the entire discussion is just plain silly :)
-

[ message continues ]

That's not for this reason I said this. Michael said the firmware needs
to be updated somewhat often. What I was wondering was if it was not
possible to stick to a stable one (and hopefully small) so that the
driver could require less frequent updates. Sorry if it's not the main

yes, possibly :-)

Cheers,
Willy

-

[ message continues ]

The bnx2 chip requires a lot of firmware to begin with, so it won't save
much space no matter what version is used in the kernel.  We update the
firmware to fix bugs and sometimes to add new features.  New features
often require matching changes in the driver.  For example, we're
planning to add S/G support for jumbo rx frames and this requires
changes in both driver and firmware.

It's possible to make the driver work with multiple firmware versions,
but that adds complexity to enable/disable certain features.  Testing
also becomes more difficult as it has to cover different combinations.


-

[ message continues ]

Is that a suggestion that the driver work differently when built as a 
module or built in? I've seen that behavior many time over the years, 
but it usually not deliberate. ;-)

-- 
Bill Davidsen <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
-

[ message continues ]

From: Bill Davidsen <davidsen@tmr.com>

Absolutely.

-

[ message continues ]

sounds reasonable.

I see that bnx2 has support for unpacking gzipped binary blobs,
and it it the only such net driver (maybe the only such driver
in the entire tree, I didn't check).

This can be very useful for all other firmware images in other drivers.

Last night I prepared a patch which basically separates unpacking
function from bnx2-related code. Can you run-test attached patch?

Meanwhile I will prepare follow-on patch which actually moves this
function out of the driver and into lib/*.

Size difference:

# size */bn*.o
   text    data     bss     dec     hex filename
  54884   81689    6424  142997   22e95 net/bnx2.o
  55276   81823    6424  143523   230a3 net.org/bnx2.o

Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
--
vda
[ message continues ]

On Wed, 2007-09-19 at 09:30 +0100, Denys Vlasenko wrote:
+       /* gzip header (1f,8b,08... 10 bytes total + possible asciz filename)
+        * is stripped, 32-bit unpacked size (LE) is prepended instead */
+       sz = *zbuf++;
+       sz = (sz << 8) + *zbuf++;
+       sz = (sz << 8) + *zbuf++;
+       sz = (sz << 8) + *zbuf++;

I don't have a problem with removing the gzip header.  It doesn't
contain very useful information other than a valid header for sanity
check.  But I don't think we need to arbitrarily add the unpacked size
in front of the gzipped data.  The driver knows the size (e.g. the size
of RAM on the chip) and should pass it to the call.  The driver should
also allocate the memory for the unpacked data instead of allocating the
memory inside the call and freeing it by the caller.  For example, the
driver may need to use pci_alloc_consistent() if the firmware is to be
DMA'ed to the chip.

Other than that, everything else looks fine.  Thanks.

-

[ message continues ]

Are you saying that you successfully run-tested it?
--
vda
-

[ message continues ]

I've only reviewed the code.  Let's resolve these issues first before
testing the code.

-

[ message continues ]

Please test these two patches.
I updated them according to your comments.
--
vda
[ message continues ]

I've only tested patch #1.  It worked after some minor modifications


rc will always be Z_STREAM_END in this case since we provide a big
enough gunzip_buf for the whole blob.

-

[ message continues ]

well thanks that would help us a lot,
we have to strip the firmware for Debian for the upcoming Lenny release.
as the shipping exception for the previous 2 releases will not be granted
again. so a separate firmware would be great. also afaik only some boards
need it. it is a pressing need for us as tg3 with stripped firmware of
course doesn't build.

-- 
maks
-

[ message continues ]

From: maximilian attems <max@stro.at>

Why do you "have to"?  The vendor has given you explicit rights
to distribute it:

 * Firmware is:
 *	Derived from proprietary unpublished source code,
 *	Copyright (C) 2000-2003 Broadcom Corporation.
 *
 *	Permission is hereby granted for the distribution of this firmware
 *	data in hexadecimal or equivalent format, provided this copyright
 *	notice is accompanying it.

This whole firmware stripping thing in debian is beyond rediculious
and only serves to hurt users.
-

[ message continues ]

hello dave,

i appreciate a lot your opinon, but please cool down.
this is not a four spin on your beloved pipe. :)


afair the trouble is that it does not give permission to change
unlike some other gpl or bsd licensed blob.

i'm not of the d-legal department,
but seeing free firmwares would be cool.

-- 
maks

-

[ message continues ]

klibc could help with that, if there is interest in exploring that
avenue again.

	-hpa
-

[ message continues ]

From: "H. Peter Anvin" <hpa@zytor.com>

I appreciate the effort you put into klibc and the offer to
make initrd's easier to build.

But the point is that the initrd shouldn't be necessary in the first
place.  There becomes zero point in building these drivers statically
into the kernel, which many of us do specifically to avoid module
loading, initrds, and all that fuss.  Because the driver is totally
crippled even though it's been fully built into the main kernel image.

I mean, it's so incredibly stupid and makes kernel development that
much more difficult.

Every new dependency, be it requiring initrd or something else,
is one more barrier added to kernel development.

I really pine for the days where everything was so simple, and initrd
and modules were the odd ball cases, most developers built everything
into their kernel image.
-

[ message continues ]

Well, what I was referring to here, of course, was the initramfs
integrated in the kernel image, so it all comes out of the kernel build
tree and produces a single bootable image.  The fact that part of it
contains userspace code is in that way invisible.

That was kind of the point here, and the only reason for pushing klibc
into the kernel build tree at all.  Under the "distros use external
initrd anyway" school of thought, whatever libc used for that can be
external anyway.

	-hpa
-

[ message continues ]

From: "H. Peter Anvin" <hpa@zytor.com>

Sounds good to me :)
-

[ message continues ]

Except there seems to be great resistance to include userland code in the
kernel as demonstrated at last KS. Or this is maybe just a single vocal
person and the topic were brought up late?

Anyway - if we again consider klibc I will do my best to make the
build stuff as smooth as possible.

	Sam
-

[ message continues ]

At least as of the last merged tree it was very smooth indeed, thanks to
your help.

	-hpa
-

[ message continues ]

<nitpicking mode on>
currently klibc has tendency to rebuild a bit too much if you
touch some part of it, seen in usr/utils
for the main klibc i agree that it makes sense

-- 
maks
-

[ message continues ]

Could you give a concrete example?

	-hpa
-

[ message continues ]

max@dual:~/src/klibc$ touch usr/utils/mount_main.c
max@dual:~/src/klibc$ make
  KLIBCCC usr/utils/mount_main.o
  KLIBCLD usr/utils/static/halt
  LN      usr/utils/static/reboot
  LN      usr/utils/static/poweroff
  KLIBCLD usr/utils/shared/halt
  LN      usr/utils/shared/reboot
  LN      usr/utils/shared/poweroff
  KLIBCLD usr/utils/static/chroot
  KLIBCLD usr/utils/static/dd
  <snipp>

-- 
maks
-

[ message continues ]

Hi Maks.


I do not recall the details at the moment but I recall I had to
do this tradeoff for some reasons.
I do not say it is not fixable but when I did the static-y support
I recall I took a shortcut or two under the assumption that everything
build by klibc was anyway so simple that compiling a bit too much was no harm.

Too buried with other stuff right now.
But feel free to poke me in roughly a month and I will take a deeper look.

	Sam
-

[ message continues ]

You don't need to store and fetch zeros at all. You *know* that
they are zeros, right? So do this:

-                         REG_WR_IND(bp, offset, fw->bss[j]);
+                         REG_WR_IND(bp, offset, 0);

--
vda
-

[ message continues ]

Good point.  We can do that.  Looking at the file, there are other non-
zero data that can be compressed to save some more room.

-

[ message continues ]