@northbound
Thanks, so a race condition I haven't triggered in a few hundred tries with an acs?
Topic: Update on Linksys WRT1900AC support
The content of this topic has been archived between 16 Sep 2014 and 7 May 2018. Unfortunately there are posts – most likely complete pages – missing.
Page 485 of 598
davidc502 wrote:
JohnnySL wrote:leitec wrote:The aforementioned fix should prevent it from happening again, but you probably have to manually reset the u-boot environment before you can flash a new image.
Agreed, damage is done, needs to be fixed first.
Okay, from the start...
1. I want to fix it first. What commands need to be run? < flashing OpenWrt will re-create the problem again?
2. After the fix, run leitec recommended commands?
Appreciate it, because I want to document what needs to be done.
You're going to need to fix the environment first, so that the sysupgrade process (and I think factory, too) will know which partition to write the new firmware to. There's a chance that after you repair the environment and boot into your existing OpenWrt you'll trigger the problem again. I don't know how likely that is, but the safest approach is to skip it.
One approach, if you still have the factory FW installed: run the u-boot commands and then boot into factory. Then, flash a new OpenWrt/LEDE with the fix applied.
Another approach: run the commands, then once you come back from "saveenv; reset" flash a new image from u-boot via TFTP.
(Last edited by leitec on 12 Jun 2016, 03:31)
Mr. davidc502, I just installed your build for the wrt1900ac. I just have one request, if it's not much trouble. Could you compile the package for the QOS-scrips and luci-app-qos. The sqm never worked properly for me. Thanks a lot
leitec wrote:
davidc502 wrote:command line sysupgrade fails too with this error. Anyone seen this before? "## Error: "boot_part" not defined"
<snip> ## Error: "boot_part" not defined cannot find target partitionOh, that looks like a problem that came up recently for an ACS user on the lede-dev mailing list. The u_env partition (u-boot settings) gets wiped out for some reason, and the bootloader doesn't save the defaults to flash on reset. The only way to fix it that I can think of is to connect the serial console, then issue the following from the u-boot prompt:
resetenv; reset
once it restarts, stop u-boot again and issue
saveenv; reset
(this will save the default values back to flash)
Then, let it boot normally.
I wanted to test to see if the commands above would allow me to upgrade.
I ran both
1. resetenv; reset
2. reboot -- stop the boot process
3. saveenv; reset
However, after the next boot, I tried upgrading, but it still will not let me for the same reasons.
I'm thinking at this point if I want to upgrade I'll need to use the tftp process. Any thoughts?
I do see during the loader the following line "*** Warning - bad CRC, using default environment"
Marvell>>
BootROM - 1.73
Booting from NAND flash
General initialization - Version: 1.0.0
Detected Device ID 6820
High speed PHY - Version: 2.0
Init RD NAS topology Serdes Lane 3 is USB3
Serdes Lane 4 is SGMII
board SerDes lanes topology details:
| Lane # | Speed | Type |
--------------------------------
| 0 | 06 | SATA0 |
| 1 | 05 | PCIe0 |
| 2 | 06 | SATA1 |
| 3 | 05 | USB3 HOST1 |
| 4 | 05 | PCIe1 |
| 5 | 00 | SGMII2 |
--------------------------------
:** Link is Gen1, check the EP capability
PCIe, Idx 0: Link upgraded to Gen2 based on client cpabilities
:** Link is Gen1, check the EP capability
PCIe, Idx 1: remains Gen1
High speed PHY - Ended Successfully
DDR3 Training Sequence - Ver TIP-1.26.0
mvSysEnvGetTopologyUpdateInfo: TWSI Read failed
DDR3 Training Sequence - Switching XBAR Window to FastPath Window
DDR3 Training Sequence - Ended Successfully
Not detected suspend to RAM indication
BootROM: Image checksum verification PASSED
__ __ _ _
| \/ | __ _ _ ____ _____| | |
| |\/| |/ _` | '__\ \ / / _ \ | |
| | | | (_| | | \ V / __/ | |
|_| |_|\__,_|_| \_/ \___|_|_|
_ _ ____ _
| | | | | __ ) ___ ___ | |_
| | | |___| _ \ / _ \ / _ \| __|
| |_| |___| |_) | (_) | (_) | |_
\___/ |____/ \___/ \___/ \__|
** LOADER **
U-Boot 2013.01 (Mar 27 2015 - 16:50:46) Marvell version: 2014_T3.0p6
Boot version : v1.0.13
Board: RD-NAS-88F6820-DDR3
SoC: MV88F6820 Rev A0
running 2 CPUs
CPU: ARM Cortex A9 MPCore (Rev 1) LE
CPU 0
CPU @ 1600 [MHz]
L2 @ 800 [MHz]
TClock @ 200 [MHz]
DDR @ 800 [MHz]
DDR 32 Bit Width, FastPath Memory Access, DLB Enabled, ECC Disabled
DRAM: 512 MiB
Map: Code: 0x1fea9000:0x1ff7632c
BSS: 0x1ffef6b4
Stack: 0x1f9a8f20
Heap: 0x1f9a9000:0x1fea9000
raise: Signal # 8 caught
U-ENV offset == 0x200000
raise: Signal # 8 caught
U-ENV offset == 0x200000
U-Boot Environment: 0x00200000:0x00220000 (NAND)
NAND: 128 MiB
MMC: mv_sdh: 0
DEVINFO offset == 0x900000
U-ENV offset == 0x200000
U-ENV offset == 0x200000
*** Warning - bad CRC, using default environment
S-ENV offset == 0x240000
#### auto_recovery ####
[u_env] get auto_recovery == yes
[u_env] get auto_recovery == yes
[u_env] get boot_part == 1
[u_env] get boot_part_ready == 3
auto_recovery enabled:1, boot_part:1, boot_part_ready:3
S-ENV offset == 0x240000
[boot_count_read] block:0x240000, size:128KB, records:64
[boot_count_read_record] boot_count:1, next_record:56
[boot_count_write] erase:0, auto_recovery->block_offset:0x240000 offset=0x25C000
Updating boot_count ...
[boot_count_write] offset:0x25C000 , length:2048
done
PCI-e 0 (IF 0 - bus 0) Root Complex Interface, Detected Link X1, GEN 2.0
PCI-e 1 (IF 1 - bus 1) Root Complex Interface, Detected Link X1, GEN 1.1
USB2.0 0: Host Mode
USB3.0 1: Host Mode
USB3.0 0: Host Mode
Board configuration detected:
mvEthE6171SwitchBasicInit init
Net:
| port | Interface | PHY address |
|--------|-----------|--------------|
| egiga0 | RGMII | 0x01 |
| egiga1 | SGMII | 0x00 |
egiga0 [PRIME], egiga1
auto_recovery_check changes bootcmd: run nandboot
Hit any key to stop autoboot: 0
Marvell>>(Last edited by davidc502 on 12 Jun 2016, 19:13)
Bogey wrote:
gsustek wrote:1900acs:~# free -m
total used free shared buffers cached
Mem: 513496 75080 438416 1060 5572 15060
-/+ buffers/cache: 54448 459048
Swap: 1048572 0 1048572
root@1900acs:~#So 459048 free.
Please run the commands while you are having a memory issue.
hi, r584; .diffconfig= http://sprunge.us/FWLe
putty.log;= http://sprunge.ushttp
dmesg_free_the_command: http://sprunge.us/iTAX
through 5GHz wifi with filezilla(vsftpd) 9GB file from SATA HDD(ext4) connected to 1900ACS copied to dell laptop (intel7625) about 55MB/s,
trying to upoad the same file cause kernel panic, reboot, and reboot during boot up!!!!
please see logs.. any advice? can anyone try this?
@leitec
Thank you for the explanation.
On latest trunk someone else having this in their log
daemon.info procd: Instance sysntpd::instance1 s in a crash loop 6 crashes, 0 seconds since last crash
?
Where is the (dark side) image builder located?
Or can we just use the OpenWrt image builder and run the command-- $git clone http://git.lede-project.org/source.git
Then proceed normally?
(Last edited by davidc502 on 13 Jun 2016, 01:04)
@davidc502
An older with backup of u_env from an acs with mac's set to all 0. So edit to what you'd like to have.
https://gpldr.in/v/F2ELeDx8fS/j5izjvnS7aFAQiSy
Also contains the info you need to boot into linux and use mtd to rewrite the env comfortably.
@david, indeed the "*** Warning - bad CRC, using default environment" shows that something didn't work during the 'saveenv' process, or that the same thing happened again the next time you booted into OpenWrt.
Either try again, and pay attention if you have that message after the 'saveenv' step. You can check the current environment variables with the 'printenv' command. After saveenv and a reset, check again.
You can also try flashing the file sera provided with:
mtd write filename.bin u_env
@sera and @leitec,
So far I'm learning and playing around a bit......
I went ahead and compiled the latest image from the "DARK SIDE", and proceeded to flash using TFTP, and it worked without issue. The DARK SIDE image boots right up and I see it has a new kernel?
Model Linksys WRT1900ACS
Firmware Version LEDE Reboot r607 / LuCI Master (git-16.164.65694-cd50f27)
Kernel Version 4.4.13
Question: by the printenv issued after lede was flashed, can we tell if the problem is now gone? I thought I read the latest lede image fixes the issue? If not, I can always go back to the image @sera let me download << Thanks sera
Marvell>> printenv
CASset=max
MALLOC_len=5
MPmode=SMP
altFwSize=0x2800000
altKernAddr=0x3200000
altKernSize=0x0600000
altnandboot=setenv bootargs console=ttyS0,115200 root=/dev/mtdblock7 ro rootdelay=1 rootfstype=jffs2 earlyprintk $mtdpart s;nand read $defaultLoadAddr $altKernAddr $altKernSize; bootm $defaultLoadAddr
auto_recovery=yes
autoload=no
baudrate=115200
boot_order=hd_scr usb_scr mmc_scr hd_img usb_img mmc_img pxe net_img net_scr
boot_part=2
boot_part_ready=3
bootargs_dflt=$console $nandEcc $mtdparts $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end $m vNetConfig video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel
bootargs_end=:10.4.50.254:255.255.255.0:Armada38x:eth0:none
bootargs_root=root=/dev/nfs rw
bootcmd=run nandboot
bootcmd_auto=stage_boot $boot_order
bootcmd_fdt=tftpboot 0x2000000 $image_name;tftpboot $fdtaddr $fdtfile;setenv bootargs $console $nandEcc $mtdparts $bootar gs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params clcd.lc d0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel; bootz 0x2000000 - $fdtaddr;
bootcmd_fdt_boot=tftpboot 0x2000000 $image_name; setenv bootargs $console $nandEcc $mtdparts $bootargs_root nfsroot=$serv erip:$rootpath ip=$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enabl e clcd.lcd_panel=$lcd_panel; bootz 0x2000000 - $fdtaddr;
bootcmd_fdt_edit=tftpboot $fdtaddr $fdtfile; fdt addr $fdtaddr; setenv bootcmd $bootcmd_fdt_boot
bootcmd_lgcy=tftpboot 0x2000000 $image_name; setenv bootargs $bootargs_dflt; bootm 0x2000000;
bootdelay=3
cacheShare=no
console=console=ttyS0,115200
defaultLoadAddr=0x2000000
device_partition=0:1
disaMvPnp=no
eeeEnable=no
enaClockGating=no
enaCpuStream=no
enaFPU=yes
enaMonExt=no
enaWrAllo=no
eth1addr=00:50:43:48:ab:be
eth1mtu=1500
eth2addr=00:50:43:48:e6:be
eth2mtu=1500
eth3addr=00:50:43:ab:e6:48
eth3mtu=1500
ethact=egiga0
ethaddr=00:50:43:e6:ab:be
ethmtu=1500
ethprime=egiga0
fdt_addr=2040000
fdt_skip_update=no
fdtaddr=0x1000000
fdtfile=armada-38x-modular.dtb
fileaddr=2000000
filesize=960000
firmwareName=cobra.img
firmware_name=shelby.img
flash_alt_image=tftpboot $defaultLoadAddr $firmwareName && nand erase $altKernAddr $altFwSize && nand write $defaultLoadA ddr $altKernAddr $filesize
flash_pri_image=tftpboot $defaultLoadAddr $firmwareName && nand erase $priKernAddr $priFwSize && nand write $defaultLoadA ddr $priKernAddr $filesize
ide_path=/
image_name=uImage
initrd_name=uInitrd
ipaddr=192.168.1.1
kernel_addr_r=2080000
lcd0_enable=0
lcd0_params=640x480-16@60
lcd_panel=0
loadaddr=0x02000000
loads_echo=0
mtdids=nand0=armada-nand
mtdparts=mtdparts=armada-nand:2048K(uboot)ro,256K(u_env),256K(s_env),1m@9m(devinfo),40m@10m(kernel),34m@16m(rootfs),40m@5 0m(alt_kernel),34m@56m(alt_rootfs),80m@10m(ubifs),-@90m(syscfg)
mvNetConfig=mv_net_config=4,(00:50:43:11:11:11,0:1:2:3),mtu=1500
mv_pon_addr=00:50:43:be:e6:48
nandEcc=nfcConfig=4bitecc
nandboot=setenv bootargs console=ttyS0,115200 root=/dev/mtdblock5 ro rootdelay=1 rootfstype=jffs2 earlyprintk $mtdparts;n and read $defaultLoadAddr $priKernAddr $priKernSize; bootm $defaultLoadAddr
netbsd_en=no
netmask=255.255.255.0
netretry=no
pcieTune=no
pexMode=RC
priFwSize=0x2800000
priKernAddr=0x0a00000
priKernSize=0x0600000
pxe_files_load=:default.arm-armadaxp-db:default.arm-armadaxp:default.arm
pxefile_addr_r=3100000
ramdisk_addr_r=2880000
rootpath=/srv/nfs/
sata_delay_reset=0
sata_dma_mode=yes
script_addr_r=3000000
script_name=boot.scr
serverip=192.168.1.2
standalone=fsload 0x2000000 $image_name;setenv bootargs $console $nandEcc $mtdparts root=/dev/mtdblock0 rw ip=$ipaddr:$se rverip$bootargs_end; bootm 0x2000000;
stderr=serial
stdin=serial
stdout=serial
update_both_images=tftpboot $defaultLoadAddr $firmwareName && nand erase $priKernAddr $priFwSize && nand erase $altKernAd dr $altFwSize && nand write $defaultLoadAddr $priKernAddr $filesize && nand write $defaultLoadAddr $altKernAddr $filesize
usb0Mode=host
usbActive=0
usbType=2
vxworks_en=no
yuk_ethaddr=00:00:00:EE:51:81
Environment size: 4273/131068 bytesOn a side issue -- It appears the BM patch I have doesn't work with this kernel version. Anyone have the latest BM patch? Or will it be built into the "dark side" soon?
Best regards, and appreciate everyone's help as I might need more lol
@davidc502
It is already there and functioning.
Here on a 1900acv1 anyway.
Is anybody having problems with latest releases (both David's and MrFeezee's) and WRT1900AC v1?
After a while my 5GHz WiFi is working but doesn't connect with Internet, while 2,4GHz WiFi works fine. A factory reset doesn't seem to fix things.
Maybe it's a problem with my router, because I tried LinkSys firmware and then no cable connected device was shown (nor could access the network). WiFi worked fine on both bands.
In the end I installed DD-Wrt and seems to work, but it's slow both booting and with WiFi connections, and has some problems with multicast, which I use to watch TV.
Any idea?
Regards.
gsustek wrote:
Bogey wrote:gsustek wrote:1900acs:~# free -m
total used free shared buffers cached
Mem: 513496 75080 438416 1060 5572 15060
-/+ buffers/cache: 54448 459048
Swap: 1048572 0 1048572
root@1900acs:~#So 459048 free.
Please run the commands while you are having a memory issue.hi, r584; .diffconfig= http://sprunge.us/FWLe
putty.log;= http://sprunge.ushttp
dmesg_free_the_command: http://sprunge.us/iTAXthrough 5GHz wifi with filezilla(vsftpd) 9GB file from SATA HDD(ext4) connected to 1900ACS copied to dell laptop (intel7625) about 55MB/s,
trying to upoad the same file cause kernel panic, reboot, and reboot during boot up!!!!please see logs.. any advice? can anyone try this?
i can confirm that arokh build, doesn't have this issue!
please, does somebody have saved previous version of 1900AC and 1900ACS wiki somewhere? i need that command how to reset config mtd partition from comand line!
thnx.
gsustek wrote:
hi, r584; .diffconfig= http://sprunge.us/FWLe
putty.log;= http://sprunge.ushttp
dmesg_free_the_command: http://sprunge.us/iTAXthrough 5GHz wifi with filezilla(vsftpd) 9GB file from SATA HDD(ext4) connected to 1900ACS copied to dell laptop (intel7625) about 55MB/s,
trying to upoad the same file cause kernel panic, reboot, and reboot during boot up!!!!please see logs.. any advice? can anyone try this?
Seems memory was fine, almost all the memory used by cache but that is normal.
Do you have the kernel panic in the log somewhere? Do you have TTL cable to get error logged from the console output?
Edit: Arokhs build does not have BM.
(Last edited by Bogey on 13 Jun 2016, 11:28)
and latest LEDE has BM? for TTL, plese see putty.log:-)
(Last edited by gsustek on 13 Jun 2016, 11:49)
gsustek wrote:
and latest LEDE has BM? for TTL, plese see putty.log:-)
Do we need to add the NAND patch to the "Dark Side" builds? This is for ACS, V2, or V1.
gsustek wrote:
and latest LEDE has BM? for TTL, plese see putty.log:-)
Image Name: ARM LEDE Linux-4.4.12
mvneta_bm f10c0000.bm: Buffer Manager for network controller enabled
davidc502 wrote:
gsustek wrote:and latest LEDE has BM? for TTL, plese see putty.log:-)
Do we need to add the NAND patch to the "Dark Side" builds? This is for ACS, V2, or V1.
I have not been using the NAND patch on there for quite awhile no lock up during boot.
Sometimes SQUASHFS error: xz decompression failed, data probably corrupt
Tue Jun 7 18:34:11 2016 kern.err kernel: [ 19.257563] SQUASHFS error: squashfs_read_data failed to read block 0x42c722.
But I have not seen that In awhile.
gsustek wrote:
please, does somebody have saved previous version of 1900AC and 1900ACS wiki somewhere? i need that command how to reset config mtd partition from comand line!
All the old versions are available at the Wiki itself...
just pick the version you need:
https://wiki.openwrt.org/toh/linksys/wr … =revisions
northbound wrote:
davidc502 wrote:gsustek wrote:and latest LEDE has BM? for TTL, plese see putty.log:-)
Do we need to add the NAND patch to the "Dark Side" builds? This is for ACS, V2, or V1.
I have not been using the NAND patch on there for quite awhile no lock up during boot.
Sometimes SQUASHFS error: xz decompression failed, data probably corrupt
Tue Jun 7 18:34:11 2016 kern.err kernel: [ 19.257563] SQUASHFS error: squashfs_read_data failed to read block 0x42c722.
But I have not seen that In awhile.
Hehe, right or wrong I still include the patch it in all my builds. I simply don't want to risk it and I can't find clear proof it has been incorporated upstream.
gsustek wrote:
and latest LEDE has BM? for TTL, plese see putty.log:-)
The link is corrupt, please correct it :)
(Last edited by Bogey on 13 Jun 2016, 16:41)
If you check the github you will see BM, NAND and much more pushed in the May20-22 timeframe.
anomeome wrote:
If you check the github you will see BM, NAND and much more pushed in the May20-22 timeframe.
Search for issues closed -- couldn't find anything dealing with ACS -- specifically dealing with the flashing issue.
https://github.com/lede-project/source/ … s%3Aclosed
Have you seen anything?
***EDIT***
JohnySL posted this "known issue for which Felix added a fix in Lede this weekend."
And this >>
anomeome wrote:
Here is the thread being referenced.
(Last edited by davidc502 on 13 Jun 2016, 17:13)
I had thought the issue was addressed by the link @northbound posted earlier. I believe the thread to which I linked is the discussion that led to said patch.
Edit: This was later that the CESA and rest that was pushed back in May.
(Last edited by anomeome on 13 Jun 2016, 17:18)
anomeome wrote:
I had thought the issue was addressed by the link @northbound posted earlier. I believe the thread to which I linked is the discussion that led to said patch.
Edit: This was later that the CESA and rest that was pushed back in May.
If I understand you correctly, this issue has not been addressed and I will need to post the problem on github?
Best regards,
Sorry, posts 12126 to 12125 are missing from our archive.
Page 485 of 598