Quote:
Originally Posted by Lmiller1708
Ok I will give this a try shortly.
Your numbers are a bit off for your MTD parts. You are overwriting your system with your recovery.
Code:
mtdparts=msm_nand:0x20000000@0x0(nand),0x600000@0x6000000(recovery),0x0A000000@0x6600000(system),0xF800000@0x10600000(userdata),0x1E00000@0x1FE00000(cache)
Edit: Still no go.. I will post some logs in a bit. (Or I will be in chat)
Also my wifi does not seem to be working now either... It turns on, scans, and then says unable to scan for networks and then turns off. Any Ideas anyone?
Log as promised: D/AT ( 134): AT> AT+CREG? D/RILJ ( 466): [0060]< QUERY_FACILITY_LOCK - Pastebin.com |
Hmm your logs show ur actually on data.
[0084]< SETUP_DATA_CALL {1, ppp0, 255.255.255.255} < -- means you connected to pppd just fine. Now i had this happen where stale settings were being used meaning an old IP instead of the new one. go to airplane mode and run the ip-down script by hand in /data/ppp. Then disable airplane mode and a new ip should come up.
Wifi works good for me. Changes are your modules are shot? check dmesg, and logcat when making the connection. I cant replicate this on my end. Since i only have limited minutes on my test plan i rely on wifi heavily.
PLEASE fix my mtd parts.. i just did it so i can format it. You and Nate are the pros here. The cache part can wait since i couldnt replicate but the recovery needs to be moved back a bit. I decided to move it back 2mb and shrink the size 2mb but my math was probably off
Also the recovery is looking so good, im thinking of just removing replimenu completely. Replimenu works when we disable the kernel messages but being a in weird debug state right now makes it break alot. I suppose we could just remove em for autobuild and keep it for dev? thoughts?
Edit: chatted with lmiller about this. Looks like he was preparing frx5 for us
. So he is all set now.