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 _______________________________________________ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
