Le 16/01/2014 22:22, Hanno Schupp a écrit : > > > > >> On 16/01/2014, at 9:43 pm, Michel Stempin <michel.stem...@wanadoo.fr> wrote: >> >> Hi Hanno, >> >> Le 16/01/2014 04:18, Hanno Schupp a écrit : >>> 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. >> >> Glad you found a solution to your problem! >> >>> 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. >> >> Unfortunately, this is often the case, and probably the reason why John >> refuses to take this burden on his shoulders. > I hear what you say, but OpenWrt is already supplying bootloaders as part of > the buildroot process for other platforms, most notably ar71xx. So why not > for ramips? From the outside it seems there seems to be no better reason than > individual dev's own choice. Happy to be educated otherwise.
ar71xx U-Boot tend to be very close to the original, while ramips are heavily modified (take the main menu as an example). And probably also the ramips support in OpenWrt is younger, at least for the RT5350 chips. But if you want to take in charge porting the diffs to the OpenWRT buildroot system, you are more than welcome! I have a MIFI-F5 (RT5350-based) small router with a CRC-modified vendor bootloader based on Ralink SDK that I need to replace with a more standard one in order to run OpenWrt. >> >>> I can say that with the self-compiled bootloader switch leaking does no >>> longer occur during bootloader processing. >> >> Can you be more explicit on what you did, like the exact SDK package you >> started from, and the name of the parameter you modified? This can be >> helpful to others having the same problem. > I intend to update the wiki accordingly with all details. It struck me that > there is no obvious good place to do this though. The bootloader pages in the > wiki are too generic, but the device specific page is too specific as what I > am showing can be used for any rt3052 based device with such a problem. We do > not seem to have platform based pages e.g. ramips, ar71xx, x86 etc. Any > suggestions welcome. You are right, there is no platform-based pages. The way it is done for these kind of "transverse" information is to create a Wiki page on the subject and link it from all concerned devices. I agree that this is not a perfect solution, though. >> >>> 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. >> >> Is this happening in BB HEAD too? > As I said, I will compile BB without the patch and retest and submit the > patch if it is proven to be useful. Ok, I was just confused: I am using git, so "trunk" is now meaningless to me;) >> >>> 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 >> >> --- >> Ce courrier électronique ne contient aucun virus ou logiciel malveillant >> parce que la protection avast! Antivirus est active. >> http://www.avast.com >> _______________________________________________ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> 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 > _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
