On Jan 23, 2009, at 8:33 PM, Michael Buesch wrote:
On Friday 23 January 2009 20:18:52 Francesco Gringoli wrote:
Nothing. Why do we need to have different names?
Well, I was only considering a question raised by John, we can surely
maintain these names.
I guess I missed that. What was the question?
Note that proprietary and open firmwares are in separate
directories, so
I don't see why we should rename them.
Renaming firmware is a huge pain. We did it several times in the
past and
I really want to avoid it. It creates a major confusion for users
for some months.
Sorry sorry sorry and sorry again... it was a Larry question, not
John's... pardon me
-- Is using the Broadcom names for the firmware the best course of
-- action? What if the opensource firmware files were named something
-- like "os-ucode5.fw", etc. and b43 were coded to check for those files
-- first? It would then fall back to the standard firmware if the
-- opensource version is not found.
However, it's not a problem maintaining these names.
- detection of the opensource firmware capabilities: are you really
sure we cannot use a shm location that the bcm proprietary firmware
uses for some other purpose?
Yes, well. You're not intermixing an earlier discussion into this,
where
you didn't indicate opensource capabilities to the kernel.
If you indicate OS capabilities, you can use whatever offset you
want, of course.
Excellent. We will modify the firmware accordingly and encode the
options.
Thanks. Would be nice if you could also do the corresponding driver
patch.
Ok, it should be simple.
- tx header layout: the opensource firmware is now using the old
memory layout in the tx header (<351). Do you think switching to
410
format is mandatory now or we can concentrate on the other tasks?
Yes, the old format is deprecated and will be removed soon.
Ok, first task in the todo list!
Well, doesn't need to the the first one. Just note that support for
this is
scheduled to be removed in summer 2008. So if any problems show up
(broadcom
releases yet another API, for example), I will immediately remove it.
Well, it's the first because it's the easiest :-)
Ok, thanks for the hint. I will check,
There are a few things we're not yet sure about.
For example the operand for the GPR number got an additional bit.
But we're not sure if the real number of GPRs also was doubled in
the hardware.
There are a few FIXMEs in the code for this...
I think this simply has to be tested by trial and error.
Thanks, I will surely check this.
Cheers,
-FG
--
Greetings, Michael.
-------
Francesco Gringoli, PhD - Assistant Professor
Dept. of Electrical Engineering for Automation
University of Brescia
via Branze, 38
25123 Brescia
ITALY
Ph: ++39.030.3715843
FAX: ++39.030.380014
WWW: http://www.ing.unibs.it/~gringoli
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
