| Message ID | 20141213182237.GA28818@chris |
|---|---|
| State | RFC |
| Headers | show |
On Sat, Dec 13, 2014 at 1:22 PM, Chris Green <cl@isbd.net> wrote: > This patch is the same as the Routerboard 951G fix, I've built this > and tested it on my rb-2011uias-2hnd. However we should check that it > also works on other/older RB2011 routers which did work OK with the > unpatched code. I'll do that some time around 29 or 30 Dec. -- Soren Harward stharward@gmail.com
On Sun, Dec 14, 2014 at 4:41 PM, Soren Harward <stharward@gmail.com> wrote: > On Sat, Dec 13, 2014 at 1:22 PM, Chris Green <cl@isbd.net> wrote: >> This patch is the same as the Routerboard 951G fix, I've built this >> and tested it on my rb-2011uias-2hnd. However we should check that it >> also works on other/older RB2011 routers which did work OK with the >> unpatched code. > > I'll do that some time around 29 or 30 Dec. I finally had a chance to test this patch. I built three separate images from r43800, with ath79_eth0_pll_data.pll_1000 as 0x06000000 (the current default value), 0x3e000000, and 0x6f000000. I netbooted each of them in turn. All three values seem to work fine with my router: ten pings to my laptop (hooked up on Eth1) didn't drop any packets. I'm attaching my dmesg just in case someone who understands the boot process of these devices better than I do can maybe figure out what the difference is between my [working] machine and everyone else's [non-working] machines.
On Thu, Jan 1, 2015 at 10:45 PM, Soren Harward <stharward@gmail.com> wrote: > I'm attaching my dmesg just in case someone who understands the boot > process of these devices better than I do can maybe figure out what > the difference is between my [working] machine and everyone else's > [non-working] machines. Actually, now that I think about it, the answer may be as simple as that I've got a RB2011UiAS-RM (doesn't have wireless), as opposed to the RB2011UiAS-2HnD (has wireless).
On Thu, Jan 01, 2015 at 10:51:11PM -0500, Soren Harward wrote: > On Thu, Jan 1, 2015 at 10:45 PM, Soren Harward <stharward@gmail.com> wrote: > > I'm attaching my dmesg just in case someone who understands the boot > > process of these devices better than I do can maybe figure out what > > the difference is between my [working] machine and everyone else's > > [non-working] machines. > > Actually, now that I think about it, the answer may be as simple as > that I've got a RB2011UiAS-RM (doesn't have wireless), as opposed to > the RB2011UiAS-2HnD (has wireless). > Could be just that. My RB2011UiAS-2HnD seems OK with both 0x3e000000 and 0x6f000000 to the extent that all the wired ethernet ports work whereas with 0x06000000 the five Gigabit ports don't work. The WiFi works with 0x06000000, I haven't spcifically checked it with the other values, I'll try and do that today or over the weekend.
On Fri, Jan 02, 2015 at 09:40:07AM +0000, Chris Green wrote: > On Thu, Jan 01, 2015 at 10:51:11PM -0500, Soren Harward wrote: > > On Thu, Jan 1, 2015 at 10:45 PM, Soren Harward <stharward@gmail.com> wrote: > > > I'm attaching my dmesg just in case someone who understands the boot > > > process of these devices better than I do can maybe figure out what > > > the difference is between my [working] machine and everyone else's > > > [non-working] machines. > > > > Actually, now that I think about it, the answer may be as simple as > > that I've got a RB2011UiAS-RM (doesn't have wireless), as opposed to > > the RB2011UiAS-2HnD (has wireless). > > > Could be just that. > > My RB2011UiAS-2HnD seems OK with both 0x3e000000 and 0x6f000000 to the > extent that all the wired ethernet ports work whereas with 0x06000000 > the five Gigabit ports don't work. > > The WiFi works with 0x06000000, I haven't spcifically checked it with > the other values, I'll try and do that today or over the weekend. > OK, first setup. I've set the value to 0x3e000000 in mach_rb2011.c in a Barrier Breaker 14.07 build. Everything seems to work correctly, both the Gigabit ports and the WiFi. While I'm here, how do I build a ....sysupgrade.bin image? I'm getting tired of doing bootp/tftp installs!
On Fri, Jan 2, 2015 at 8:24 AM, Chris Green <cl@isbd.net> wrote: > While I'm here, how do I build a ....sysupgrade.bin image? I'm getting > tired of doing bootp/tftp installs! AFAIK, MikroTik's don't have a sysupgrade path, probably because of strong variability in flash layout among the dozens of RouterBoard/MT devices. Yeah, it's not an ideal situation, but it's what we've got unless sysupgrade becomes a whole lot smarter.
On Fri, Jan 02, 2015 at 09:35:26PM -0500, Soren Harward wrote: > On Fri, Jan 2, 2015 at 8:24 AM, Chris Green <cl@isbd.net> wrote: > > While I'm here, how do I build a ....sysupgrade.bin image? I'm getting > > tired of doing bootp/tftp installs! > > AFAIK, MikroTik's don't have a sysupgrade path, probably because of > strong variability in flash layout among the dozens of RouterBoard/MT > devices. Yeah, it's not an ideal situation, but it's what we've got > unless sysupgrade becomes a whole lot smarter. > Ah, thanks. I guess I'll just have to continue with the bootp/tftp then, I'm getting better at it! :-) At least the RB2011 has an easily accessible serial console so I cn always talk to it even when I get the network/LAN configuration thoroughly screwed up (which is quite often).
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-rb2011.c b/target/linux/ar71xx/files/arch/mips/ath79/mach-rb2011.c index b73fae6..951ab94 100644 --- a/target/linux/ar71xx/files/arch/mips/ath79/mach-rb2011.c +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-rb2011.c @@ -270,6 +270,7 @@ static int __init rb2011_setup(u32 flags) rb2011_nand_init(); ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_RGMII_GMAC0 | + AR934X_ETH_CFG_RXD_DELAY | AR934X_ETH_CFG_SW_ONLY_MODE); ath79_register_mdio(1, 0x0); @@ -283,7 +284,7 @@ static int __init rb2011_setup(u32 flags) ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_RGMII; ath79_eth0_data.phy_mask = BIT(0); ath79_eth0_data.mii_bus_dev = &ath79_mdio0_device.dev; - ath79_eth0_pll_data.pll_1000 = 0x06000000; + ath79_eth0_pll_data.pll_1000 = 0x3e000000; ath79_register_eth(0);