

The MI424WR Rev I has a 4-port switch, so a different driver is used. (Side notes: this might be a significant factor in lesser network performance comparing to the a380 or aXP).Īlso, what you said above "MI424RW was auto-negotiated to half-duplex" should be relevant only for the SG200 model, because it has only 2 Ethernet ports. Armada 370, 380, XP Socs all use the same BM code, and the lack of HW buffer for the a370 is taken into account. In the latest kernel, it is not an issue anymore. Armada 370 does not have hardware buffer in the NIC, so there was a time when it was correct to remove it. That error about buffer management was real. What I don't know is if that can be set in the DTB. And, with an older version of that driver than what's likely available now. Unless I'm wrong, that suggests to me that the OpenRG-based firmware was operating with that driver set with buffer management disabled.įrom a common-sense and performance perspective, disabling buffers and running half-duplex seems wrong, but it did work surprisingly well. I could get a great speed-test result in that mode, but it was horrible when I forced DD-WRT to uplink using full-duplex. When I was using my MI424RW-Rev-I router with Verizon FiOS in front of my DD-WRT router, I was surprised that my DD-WRT upstream connection to the MI424RW was auto-negotiated to half-duplex. Then the complaints rolled in, then it was backed out.

Apparently, all was good until somebody enabled it. Those changes seemed centered around enabling or disabling buffer management in the driver. I have found postings from years ago that suggest an issue with changes to the driver build. Bear with me, I'm not the embedded developer that you are. I've been looking as time permits, and wondering about a couple of things related to the "mvneta" driver issue. sizeğlash sector size Number of sectorsĮdited 2 time(s). Usb_set_bootargs=setenv bootargs console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 $ earlyprintk=serialīootcmd=run bootcmd_debian run bootcmd_stock Mtdparts=mtdparts=orion_nand:2M(U-Boot),32M(JFFS2),80M(Firmware) Usb_bootcmd=run usb_set_bootargs run usb_bootīootcmd_debian=usb start run usb_bootcmd usb stop resetīootcmd_stock=echo Booting Stock. run load_uimage run load_uinitrd bootm 0x800000 0x2100000 Load_uinitrd=ext2load usb 0:1 0x2100000 /boot/uInitrd

Load_uimage=ext2load usb 0:1 0x800000 /boot/uImage

And also set up mtd partitions to allow u-boot envs read/write acess in Debian. Here to recap our current envs settings to boot Debian on USB.
