Discussion:
Prism54 development update
Sebastien
2005-08-31 12:37:53 UTC
Permalink
Hello list !

First, Jean Baptiste and I are working on low-level hardware reverse
engineering, in order to write a new firmware from scratch. The project is
named "FreeMAC" ; the motivations are :
- having high quality wireless hardware, with high quality drivers, running on
100%-free software
- making the firmware compatible with all the chipsets, regardless the chipset
was designed for FullMAC or SoftMAC (including GW3887 and ISL3886 with the
NET2280 hack). As far as I know, the only hardware difference between a
FullMAC and a SoftMAC chipset is that a SoftMAC chipset has half the memory
capacity of a FullMAC chipset. The other differences - that made the Prism54
driver unusable - seem only because the SoftMAC firmware protocol is
radically different than the FullMAC protocol.
- implementing new wireless protocols, such as WDS and WPA, with no further
protocol reverse engineering
- being more resistant to possible future protocol and hardware changes - if
Prism54 didn't rely on FullMAC that much, support for the 3886 and 3887 would
have been much more easy (probably as simple as cutting down the firmware
code and offloading operations to the host).
- official information suggests that the radio interface of these chipsets is
very flexible, making them wonderful devices for tinkering with the ISM
bands. I don't know how far we could go with this (I don't have a lot of info
about the radio for now), but for instance making a 802.11/Bluetooth combo
out of an unmodified Conexant wireless card might not be impossible.
- wireless cards are cheap and nice ARM developement boards, featuring a
powerful ARM9 core clocked at 30MHz.
- I find learning how the device works very instructive.

It can be argued that "by the time this happens the technology these cards use
will probably be extremely outdated since guessing how > 2000
registers/instructions work by trial and error is pretty
painful" (http://prism54.org/~mcgrof/firmware/). But :
- No major hardware changes seem to have been made between the first Prism
Indigo (3877) and the latest Prism Cohiba (3887).
- There aren't 2000 registers. They are less than 100, and organized by blocks
according to their purpose, which makes guessing easier. Moreover, the 3886
has mechanisms (PCI memory window, ...) which eases reverse engineering.
Finally, trial and error is not the only solution, we can run the official
firmware in an ARM emulator with the hardware registers mapped to the
physical device, and their access logged. We have enough knowledge about the
chipset for acheiving this by now.
- The instruction set and coprocessor interface are those of the ARM 946E,
which is heavily documented. The GNU ARM toolchain supports it very well - by
the time I'm writing this, the FreeMAC firmware compiles with GCC without any
problem. It's still far for being usable by normal users, though (for now,
this is mainly a command line interface giving access to the hardware and
other developer stuff).

That's pretty much my opinion, of course ; comments and criticism are welcome.

Everyone's invited to join and contribute to this project. We've set up wiki
pages at the temporary adress http://jbnote.free.fr/islsm/. I'll port ISLLDR
- a quickhack driver for FreeBSD giving access to the FreeMAC command line,
which will be eventually merged in p54u - to Linux, so that everyone can
tinker with his device. Please note that the hardware is very robust, it it
very unlikely that you fry something - my Siemens Gigaset has already been
written almost everything to every hardware register, and it's still working.


Another good news is that we've learnt a lot from hardware reverse
engineering, allowing us to understand better how the SoftMAC firmware works.
I will spare you the technical details for now unless anyone's interested -
this concerns mainly the "SoftMAC addresses" and the interrupt system.
At short term, this will allow us to fix most failures of the SoftMAC drivers.


Finally, we may take the management of the prism54.org website and use it as a
home page for the SoftMAC drivers and the FreeMAC project. The FullMAC
section will still be available, of course. This is going on with Luis.

Regards,
Sebastien
z***@zooko.com
2005-08-31 12:44:37 UTC
Permalink
Hooray!

Good for you.

I really want fully Free Software, fully working wireless.

Regards,

Zooko
Denis Vlasenko
2005-08-31 13:32:12 UTC
Permalink
[resend after subscribe to ml]
Hello list!
First, Jean Baptiste and I are working on low-level hardware reverse
engineering, in order to write a new firmware from scratch. The project is
- having high quality wireless hardware, with high quality drivers, running on
100%-free software
- making the firmware compatible with all the chipsets, regardless the chipset
was designed for FullMAC or SoftMAC (including GW3887 and ISL3886 with the
NET2280 hack). As far as I know, the only hardware difference between a
FullMAC and a SoftMAC chipset is that a SoftMAC chipset has half the memory
capacity of a FullMAC chipset. The other differences - that made the Prism54
driver unusable - seem only because the SoftMAC firmware protocol is
radically different than the FullMAC protocol.
- implementing new wireless protocols, such as WDS and WPA, with no further
protocol reverse engineering
This could (should) be achieved with...
- being more resistant to possible future protocol and hardware changes - if
Prism54 didn't rely on FullMAC that much, support for the 3886 and 3887 would
have been much more easy (probably as simple as cutting down the firmware
code and offloading operations to the host).
^^^^^^^^^^^^^^^^^^^^^
exactly this!

Actually, what is the minimum needed from a wireless card?

* ability to tx an arbitrary packet at given rate/modulation
(automatic retry and/or rate fallback is nice but not 100% reqd)
* ability to autonomously tx very low level control stuff
like sending ACKs (it's time critical)
* tune into given channel
* rx packets
* DMA packets to/from host via PCI / transfer data over USB / whatever
* anything else?

Beacons, association, even WEP and scanning - all can be done by host OS.
This also will give us nice well debugged common 802.11 stack.

Thus bare minimum firmware can be rather dumb (and thus easier to write/debug).
Maybe we (wireless crowd, not just Prism54 project) should aim
exactly to such "bare minimum fw" approach?
- official information suggests that the radio interface of these chipsets is
very flexible, making them wonderful devices for tinkering with the ISM
bands. I don't know how far we could go with this (I don't have a lot of info
about the radio for now), but for instance making a 802.11/Bluetooth combo
out of an unmodified Conexant wireless card might not be impossible.
- wireless cards are cheap and nice ARM developement boards, featuring a
powerful ARM9 core clocked at 30MHz.
- I find learning how the device works very instructive.
It can be argued that "by the time this happens the technology these cards use
will probably be extremely outdated since guessing how > 2000
registers/instructions work by trial and error is pretty
- No major hardware changes seem to have been made between the first Prism
Indigo (3877) and the latest Prism Cohiba (3887).
- There aren't 2000 registers. They are less than 100, and organized by blocks
according to their purpose, which makes guessing easier. Moreover, the 3886
has mechanisms (PCI memory window, ...) which eases reverse engineering.
Finally, trial and error is not the only solution, we can run the official
firmware in an ARM emulator with the hardware registers mapped to the
physical device, and their access logged. We have enough knowledge about the
chipset for acheiving this by now.
- The instruction set and coprocessor interface are those of the ARM 946E,
which is heavily documented. The GNU ARM toolchain supports it very well - by
the time I'm writing this, the FreeMAC firmware compiles with GCC without any
problem. It's still far for being usable by normal users, though (for now,
this is mainly a command line interface giving access to the hardware and
other developer stuff).
That's pretty much my opinion, of course ; comments and criticism are welcome.
Everyone's invited to join and contribute to this project. We've set up wiki
pages at the temporary adress http://jbnote.free.fr/islsm/. I'll port ISLLDR
- a quickhack driver for FreeBSD giving access to the FreeMAC command line,
which will be eventually merged in p54u - to Linux, so that everyone can
tinker with his device. Please note that the hardware is very robust, it it
very unlikely that you fry something - my Siemens Gigaset has already been
written almost everything to every hardware register, and it's still working.
Another good news is that we've learnt a lot from hardware reverse
engineering, allowing us to understand better how the SoftMAC firmware works.
I will spare you the technical details for now unless anyone's interested -
this concerns mainly the "SoftMAC addresses" and the interrupt system.
At short term, this will allow us to fix most failures of the SoftMAC drivers.
Finally, we may take the management of the prism54.org website and use it as a
home page for the SoftMAC drivers and the FreeMAC project. The FullMAC
section will still be available, of course. This is going on with Luis.
I will try to look into it when (if?) I'll get bored with acx project.

Cheers!
--
vda
Maximilian Engelhardt
2005-09-04 21:03:48 UTC
Permalink
Post by Denis Vlasenko
This could (should) be achieved with...
Post by Sebastien
- being more resistant to possible future protocol and hardware changes - if
Prism54 didn't rely on FullMAC that much, support for the 3886 and 3887 would
have been much more easy (probably as simple as cutting down the firmware
code and offloading operations to the host).
^^^^^^^^^^^^^^^^^^^^^
exactly this!
Actually, what is the minimum needed from a wireless card?
* ability to tx an arbitrary packet at given rate/modulation
(automatic retry and/or rate fallback is nice but not 100% reqd)
* ability to autonomously tx very low level control stuff
like sending ACKs (it's time critical)
* tune into given channel
* rx packets
* DMA packets to/from host via PCI / transfer data over USB / whatever
* anything else?
Beacons, association, even WEP and scanning - all can be done by host OS.
This also will give us nice well debugged common 802.11 stack.
Thus bare minimum firmware can be rather dumb (and thus easier to write/debug).
Maybe we (wireless crowd, not just Prism54 project) should aim
exactly to such "bare minimum fw" approach?
I disagree with this. I think the firmware should to as much as possible
to avoid CPU load. On the one hand this gives greater performance, on
the other hand it can perhaps save some power on laptops. And if we have
a fully open source firmware we will be able to implement everything we
want.
I don't think building and minimum firmware is wrong, I'm sure it will
be very good for debugging (as you mentioned above), but I think a
"bigger" firmware should be used by a final driver for my above
mentioned reasons.

Maxi
Denis Vlasenko
2005-09-05 05:13:03 UTC
Permalink
Post by Maximilian Engelhardt
Post by Denis Vlasenko
This could (should) be achieved with...
Post by Sebastien
- being more resistant to possible future protocol and hardware changes - if
Prism54 didn't rely on FullMAC that much, support for the 3886 and 3887 would
have been much more easy (probably as simple as cutting down the firmware
code and offloading operations to the host).
^^^^^^^^^^^^^^^^^^^^^
exactly this!
Actually, what is the minimum needed from a wireless card?
* ability to tx an arbitrary packet at given rate/modulation
(automatic retry and/or rate fallback is nice but not 100% reqd)
* ability to autonomously tx very low level control stuff
like sending ACKs (it's time critical)
* tune into given channel
* rx packets
* DMA packets to/from host via PCI / transfer data over USB / whatever
* anything else?
Beacons, association, even WEP and scanning - all can be done by host OS.
This also will give us nice well debugged common 802.11 stack.
Thus bare minimum firmware can be rather dumb (and thus easier to write/debug).
Maybe we (wireless crowd, not just Prism54 project) should aim
exactly to such "bare minimum fw" approach?
I disagree with this. I think the firmware should to as much as possible
to avoid CPU load. On the one hand this gives greater performance, on
the other hand it can perhaps save some power on laptops. And if we have
a fully open source firmware we will be able to implement everything we
want.
I agree that WEP/AES in firmware for bulk data may make some difference
and may make sense, other things would not.

Do you seriously expect using CPU for sending 10 beacons per second
will even be visible in you favorite system load meter?
Maybe on 100MHz PentiumI it (barely) will be, but on anything
more sane it would not.

After all, people had difficulties detecting impact of HZ=1000
versus HZ=100, and that's nearly thousand additional interrupts
per second. Here we talk about tens of interrupts per sec.
--
vda
Maximilian Engelhardt
2005-09-06 20:24:05 UTC
Permalink
Post by Denis Vlasenko
Post by Maximilian Engelhardt
I disagree with this. I think the firmware should to as much as possible
to avoid CPU load. On the one hand this gives greater performance, on
the other hand it can perhaps save some power on laptops. And if we have
a fully open source firmware we will be able to implement everything we
want.
I agree that WEP/AES in firmware for bulk data may make some difference
and may make sense, other things would not.
Do you seriously expect using CPU for sending 10 beacons per second
will even be visible in you favorite system load meter?
Maybe on 100MHz PentiumI it (barely) will be, but on anything
more sane it would not.
After all, people had difficulties detecting impact of HZ=1000
versus HZ=100, and that's nearly thousand additional interrupts
per second. Here we talk about tens of interrupts per sec.
OK, perhaps it will note make much difference on an (modern) laptop, but
there are also users running prism54 on an embedded device.

Also it would be nice to run prism54 as AP without additional software,
but only if it runs as a full-featured ap and not not some mixture of
either limited firmware ap or full featured software ap. In this case I
think a software ap only would be the only good solution.

Perhaps it also depends on the development of the ieee80211 stack now in
next mainline kernel and what things can/must be done to integrate
prism54 with this stack the best way. But I still think that at least
everything, that can be done in firmware without any feature loss or
limit should be done in firmware.
Other things will surely need additional discussion how far it makes
sense or not to integrate them in the firmware, but that's too far away
at the moment to discuss it the way it should be.

Maxi
Denis Vlasenko
2005-09-08 14:28:01 UTC
Permalink
Post by Maximilian Engelhardt
Post by Denis Vlasenko
Do you seriously expect using CPU for sending 10 beacons per second
will even be visible in you favorite system load meter?
Maybe on 100MHz PentiumI it (barely) will be, but on anything
more sane it would not.
After all, people had difficulties detecting impact of HZ=1000
versus HZ=100, and that's nearly thousand additional interrupts
per second. Here we talk about tens of interrupts per sec.
OK, perhaps it will note make much difference on an (modern) laptop, but
there are also users running prism54 on an embedded device.
Also it would be nice to run prism54 as AP without additional software,
but only if it runs as a full-featured ap and not not some mixture of
either limited firmware ap or full featured software ap. In this case I
think a software ap only would be the only good solution.
Perhaps it also depends on the development of the ieee80211 stack now in
next mainline kernel and what things can/must be done to integrate
prism54 with this stack the best way. But I still think that at least
everything, that can be done in firmware without any feature loss or
limit should be done in firmware.
s/firmware/firmwares of prism54,acx,atheros,ralink,etc,etc/

It's bug^Wcode duplication.
Post by Maximilian Engelhardt
Other things will surely need additional discussion how far it makes
sense or not to integrate them in the firmware, but that's too far away
at the moment to discuss it the way it should be.
--
vda

Jean-Baptiste Note
2005-08-31 20:51:56 UTC
Permalink
Dear list,
Post by Sebastien
That's pretty much my opinion, of course ; comments and criticism are welcome.
Just a comment, for the list (you pretty much know where i stand
Sebastien !), about what i'm doing when i get time : we have a
decompressed, disassembled firmware. Reading ASM is not fun, but ARM asm
is doable; nothing like the x86 crap. So we pretty much can understand
what happens inside the firmware when sending it some packets; I tend to
think that this is the only way we can understand how to talk to the
internal peripherals.

As a proof-of-concept, i've somewhat commented the code of the
uncompressed and disassembled firmware. Two days of work yielded the DMA
tx and rx interface (put to good use in freemac), the internal eeprom
interface (i2c bus through GPIO registers) and the start of the frame
decoding functions (which are to be followed through to understand how
to communicate properly with the softmac firmware, as well as how to
control the radio and such).

results to be found in raw mode at :
http://jbnote.free.fr/islsm/doku.php?id=re:disassembly_2_4_3_4

There's much to be done, and low-hanging fruits to reap...

Everyone's invited !

JB
Denis Vlasenko
2005-09-01 06:45:53 UTC
Permalink
Post by Jean-Baptiste Note
Dear list,
Post by Sebastien
That's pretty much my opinion, of course ; comments and criticism are welcome.
Just a comment, for the list (you pretty much know where i stand
Sebastien !), about what i'm doing when i get time : we have a
decompressed, disassembled firmware. Reading ASM is not fun, but ARM asm
is doable; nothing like the x86 crap. So we pretty much can understand
<joke> GRRRR what did you just say? x86 asm crap? My religious feelings
just got insulted </joke>

Well, I'd say people tend to think that asm dialect which they learned first
is neat and easy to understand, and all other CPUs are hair-raising
crawling horrors. It's not true in reality, but I (an x86 asm guy)
do read ia64/sparc/whatever asm from kernel source when there aren't
any good scary movies on TV. It looks impossible to understand.

My favorites are memcpy routines.
Post by Jean-Baptiste Note
what happens inside the firmware when sending it some packets; I tend to
think that this is the only way we can understand how to talk to the
internal peripherals.
As a proof-of-concept, i've somewhat commented the code of the
uncompressed and disassembled firmware. Two days of work yielded the DMA
tx and rx interface (put to good use in freemac), the internal eeprom
interface (i2c bus through GPIO registers) and the start of the frame
decoding functions (which are to be followed through to understand how
to communicate properly with the softmac firmware, as well as how to
control the radio and such).
http://jbnote.free.fr/islsm/doku.php?id=re:disassembly_2_4_3_4
There's much to be done, and low-hanging fruits to reap...
Everyone's invited !
/me start firefox
--
vda
Continue reading on narkive:
Loading...