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 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 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?
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
[email protected] <javascript:;>
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
[email protected]
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
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
