Thank you John and Michel for taking the time to explain. Much appreciated. Based on your comments and some research I found a resolution to the issue that in the end is quite simple.
Whether the Ralink extension of UBoot is hackish or not Is not for me to judge but in their defense the issue of the leaking switch during bootloader processing is well covered by them. There is a compile option to lock down the switch during bootloader startup, which, when activated, does exactly what it should so the issue I observed does not occur. I quote: "The switch operates in dump switch mode by default when the board powers up. It will cause the clients on the LAN site get the dynamic ip address from the remote DHCP server connected to WAN port. Set LAN/WAN Partition to avoid the Client’s DHCP request forwarded to the WAN side. " I simply downloaded the SDK, compiled the bootloader with the parameters shown during the boot process with the default bootloader the manufacturer delivers (plus the switch lock down of course), upload and flash the bootloader with a serial cable and that's that. Not exactly rocket science once I understood what a bootloader actually is and does - thanks again for your guidance. So the issue is not really with Ralink but rather with the device manufacturer who compiles and deploys an inadequately configured Ralink UBoot version. I can say that with the self-compiled bootloader switch leaking does no longer occur during bootloader processing. I found though on AA that about half the time during OpenWrt boot process a leak would occur around the time of network initialisation; the behaviour was not consistent, exactly 50/50 in a dozen boot tests including full power down. On trunk with this patch https://dev.openwrt.org/attachment/ticket/14156/0300-NET-MIPS-rt3052-boot-switch.patch the issue of OpenWrt leaking during boot up did not occur once in a dozen boot ups. I have not tested trunk without that patch, but if trunk without the patch behaves like AA I will submit it formally for your consideration. On Wednesday, 15 January 2014, John Crispin wrote: > > Hi, > > So what uboot bootloader version am I supposed to use for rt350x? Is the > standard Uboot Version for MIPS going to work? And which one? John seemed > to be aware of the bug but which UBoot version is the bug actually fixed in? > it is not a uboot bug but a bug caused by ralinks hackish esw driver not > setting up the vlans properly. > > this has existed in every sdk uboot they ever released. fixing it > involves getting the source of the uboot on your device and then > recompiling from scratch with a newly made fix for the issue. > > it is most likely a matter of a few hours. however i would rather walk > through hell and back than explain people how to reflash their > bootloader. people would only start to try and find random bootloader > blobs and flash them on random boards (that is what you are trying to > do) and will brick their boards on the way and then come asking us how > to fix it. openwrt has no plans to get involved in building and > redistributing ralink uboot trees/blobs because of those reasons > > John > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org <javascript:;> > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
