> 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.
>
>> 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.
>
>> 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.
>
>> 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
