On Tue, Oct 22, 2013 at 04:56:11PM +0200, Jonas Gorski wrote:
> On Tue, Oct 22, 2013 at 3:41 PM, Marcin Jurkowski <[email protected]> wrote:
> > This adds kernel support support for Sagemcom F@st 2704 wireless ADSL
> > router.
> > It's a BCM6328-based 802.11n wireless router with USB port and ADSL2+
> > modem equipped with 64 MiB RAM and 8 MiB flash.
> >
> > Signed-off-by: Marcin Jurkowski <[email protected]>
> > ---
> > .../brcm63xx/patches-3.10/803-board_fast2704.patch | 133
> > +++++++++++++++++++++
> > 1 file changed, 133 insertions(+)
> > create mode 100644
> > target/linux/brcm63xx/patches-3.10/803-board_fast2704.patch
> >
> > diff --git a/target/linux/brcm63xx/patches-3.10/803-board_fast2704.patch
> > b/target/linux/brcm63xx/patches-3.10/803-board_fast2704.patch
> > new file mode 100644
> > index 0000000..ba03fa8
> > --- /dev/null
> > +++ b/target/linux/brcm63xx/patches-3.10/803-board_fast2704.patch
>
> It should use the next free one in the boards range (500-549), currently 536.
I'll use 536 as index number.
What about patches on top of that? There are a few touching
board_bcm963xx.c. Leave them unchanged or refresh them?
> > @@ -0,0 +1,133 @@
> > +--- a/arch/mips/bcm63xx/boards/board_bcm963xx.c
> > ++++ b/arch/mips/bcm63xx/boards/board_bcm963xx.c
> > +@@ -1501,6 +1501,122 @@ static struct board_info __initdata boar
> > + },
> > + };
> > +
> > ++static struct board_info __initdata board_FAST2704V2 = {
> > ++ .name = "F@ST2704V2",
> > ++ .expected_cpu_id = 0x6328,
> > ++
> > ++ .has_uart0 = 1,
> > ++ .has_pci = 1,
> > ++ .has_ohci0 = 1,
> > ++ .has_ehci0 = 1,
> > ++ .has_usbd = 1,
>
> Are you sure about it having a USB Device/Type B port? According to
> the website it has two USB 2.0 host ports, not one host, one device.
The device I own actually has only one USB port. Maybe it's the previous
device revision (without V2) they're referring to on the website?
> > ++
> > ++ .has_enetsw = 1,
> > ++
> > ++ .enetsw = {
> > ++ .used_ports = {
> > ++ [0] = {
> > ++ .used = 1,
> > ++ .phy_id = 1,
> > ++ .name = "Port 1",
> > ++ },
> > ++ [1] = {
> > ++ .used = 1,
> > ++ .phy_id = 2,
> > ++ .name = "Port 2",
> > ++ },
> > ++ [2] = {
> > ++ .used = 1,
> > ++ .phy_id = 3,
> > ++ .name = "Port 3",
> > ++ },
> > ++ [3] = {
> > ++ .used = 1,
> > ++ .phy_id = 4,
> > ++ .name = "Port 4",
> > ++ },
> > ++ },
> > ++ },
> > ++
> > ++ .leds = {
> > ++ /* front LEDs */
> > ++ {
> > ++ .name = "F@ST2704V2:green:power",
> > ++ .gpio = 4,
> > ++ .active_low = 1,
> > ++ .default_trigger = "default-on",
> > ++ },
> > ++ {
> > ++ .name = "F@ST2704V2:red:power",
> > ++ .gpio = 5,
> > ++ .active_low = 1,
> > ++ },
> > ++ {
> > ++ .name = "F@ST2704V2:red:inet",
> > ++ .gpio = 2,
> > ++ .active_low = 1,
> > ++ },
> > ++ {
> > ++ .name = "F@ST2704V2:green:dsl",
> > ++ .gpio = 3,
> > ++ .active_low = 1,
> > ++ },
> > ++ {
> > ++ .name = "F@ST2704V2:green:inet",
> > ++ .gpio = 11,
> > ++ .active_low = 1,
> > ++ },
> > ++ {
> > ++ .name = "F@ST2704V2:green:usb",
> > ++ .gpio = 1,
> > ++ .active_low = 1,
> > ++ },
> > ++
> > ++ /* side button LEDs */
> > ++ {
> > ++ .name = "F@ST2704V2:green:wps",
> > ++ .gpio = 10,
> > ++ .active_low = 1,
> > ++ },
> > ++
> > ++ /* FIXME: can't control gpio0 line in "out" state, needs
> > further investigation */
> > ++ /*
> > ++ {
> > ++ .name = "F@ST2704V2:green:rfkill",
> > ++ .gpio = 0,
>
> From where do you have the info that this is gpio 0, if you didn't get
> it to work? I also tried to find a GPL tarball, but failed.
I managed to light LED but was unable to control line output voltage
once it was set to "out" state. Output voltage is ~2V and is constant,
regardless of output level set, which is rather strage. And I'm sure my
unit is not damaged as stock firmware properly switches between +3.3
and 0V.
This LED is definitely connected to gpio0 line. When the line enters
high-impedance (input) state, output voltage disappears and LED turns off.
> Assuming this is the wifi led, it should be named wifi. Also it might
> be just controlled by the wifi card directly, without any control from
> userspace.
It is not a wifi led. It's a LED under wifi toggle button on the side of
router. Wifi LED is located on the front panel and indeed controlled
directly by wifi phy.
As you pointed out below, the correct name for wifi toggle button on
this platform is "wlan" so it would be a good idea to rename this LED to
"wlan" too.
> > ++ .active_low = 1,
> > ++ },
> > ++ */
> > ++
> > ++ },
> > ++ .buttons = {
> > ++ {
> > ++ .desc = "reset",
> > ++ .gpio = 23,
> > ++ .active_low = 1,
> > ++ .type = EV_KEY,
> > ++ .code = KEY_RESTART,
> > ++ .debounce_interval =
> > BCM963XX_KEYS_DEBOUNCE_INTERVAL,
> > ++ },
> > ++ {
> > ++ .desc = "wps",
> > ++ .gpio = 24,
> > ++ .active_low = 1,
> > ++ .type = EV_KEY,
> > ++ .code = KEY_WPS_BUTTON,
> > ++ .debounce_interval =
> > BCM963XX_KEYS_DEBOUNCE_INTERVAL,
> > ++ },
> > ++ {
> > ++ .desc = "rfkill",
> > ++ .gpio = 15,
> > ++ .active_low = 1,
> > ++ .type = EV_KEY,
> > ++ .code = KEY_RFKILL,
>
> Common here is KEY_WLAN for this one.
OK, following this guideline key description should be changed to "wlan",
which is fine.
Now there's a question of /etc/rc.button/rfkill script. Is it correct to
report KEY_WLAN as "rfkill" hotplug event from button_hotplug module?
kr
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
