This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - OuNao
1
« on: May 02, 2013, 05:03:08 PM »
The mtd8 dump seems garbage...  The read function has problems. Did you get dmesg error during the dump?
2
« on: May 02, 2013, 02:42:58 PM »
Can you post links to the files?
3
« on: May 02, 2013, 01:04:19 PM »
Can you post the dmesg of insmodding the "stock" fsr_stl driver on "stock" kernel? We are closer.
The boot was ok.
The erase was ok (maybe).
The mount was ok (almost). The read was ok (maybe), but all the block is bad??? No....
I´m thinking in two possibilities:
1. Erase problem.
2. Read problem.
Some tests:
For erase:
1. flash with odin a smal csc.rfs (odin erase the partition before flash, only the rfs part must result on bad blocks, less rfs, more good blocks). Try to mount yaffs. You will get some bad blocks on start, but good blocks on the end.
If work, maybe a msm_onenand_erase problem...
2. Cat the boot partition (no rfs, few badblocks). Erase boot partition. Cat again and compare. This will test read and erase routines
For read:
1. flash a boot.img. Cat the boot partition. Compare the cat with the boot.img. Must match on the star with 0x00 and 0xFF on the end...
Other:
1. Try mount on boot partition. No rfs, must get few badblocks.
2. Include on driver on msm_onenand_block_isbad a debug msg with the ooptr values (0,1, 16, 17, etc)...
May we need to go some step before... Me and psyke started to test this driver with dd/nanddump/cat before try yaffs... Can you try something? Try boot the phone in recovery mode with a "null" fstab (no mount on startup). Try dd if=/dev/mtd/mt4 of=/sdcard/mtd4_dump.bin bs=4096 (change mtd4 by the boot or recovery partition) Compare this dump with a dump of the same partition using the bml driver... Must be equal... If ok, try flash_erase -N the partition. dd and compare again...
4
« on: May 02, 2013, 11:29:32 AM »
Can you post the dmesg of insmodding the "stock" fsr_stl driver on "stock" kernel?
5
« on: April 28, 2013, 02:08:28 PM »
Something is wrong.
On kernel 3.0 didn´t get errors on flash_erase, on 2.6 you get errors...
Well. If the fsr driver didn´t work, maybe the flash or the flash controler configuration is different.
i5500 has a flash_onenand_probe: version_id = 0x13e
your phone flash_onenand_probe: version_id = 0x241
This maybe did the difference...
Can you find some information about the flash chip on your phone?
6
« on: April 27, 2013, 10:26:59 PM »
We are closer.
The boot was ok.
The erase was ok (maybe).
The mount was ok (almost). The read was ok (maybe), but all the block is bad??? No....
I´m thinking in two possibilities:
1. Erase problem.
2. Read problem.
Some tests:
For erase:
1. flash with odin a smal csc.rfs (odin erase the partition before flash, only the rfs part must result on bad blocks, less rfs, more good blocks). Try to mount yaffs. You will get some bad blocks on start, but good blocks on the end.
If work, maybe a msm_onenand_erase problem...
2. Cat the boot partition (no rfs, few badblocks). Erase boot partition. Cat again and compare. This will test read and erase routines
For read:
1. flash a boot.img. Cat the boot partition. Compare the cat with the boot.img. Must match on the star with 0x00 and 0xFF on the end...
Other:
1. Try mount on boot partition. No rfs, must get few badblocks.
2. Include on driver on msm_onenand_block a debug msg with the ooptr values (0,1, 16, 17, etc)...
7
« on: April 27, 2013, 05:47:35 PM »
humm.. I don´t know what´s going on...  You are not allowed to view links.
Register or Login last boot time yaffs mount line. All read succed ok You are not allowed to view links.
Register or Login yaffs umount attemp with error? You are not allowed to view links.
Register or Login start of erase -> all ok? Can you try to erase before any attempt of mount yaffs? Boot without yaffs on fstab, try to erase and mount?
8
« on: April 27, 2013, 05:44:32 PM »
On dmesg we can see that the cache partition is mounted on boot. This time the msm_onenand_read_oob give no error (only bad blocks, expected). After a erase, the mount attempt give read errors...
You are erasing the mtd partition without a umount? Maybe you are getting ecc (oob area) corruption because that...
Try to remove the cache/system/data partitions from fstab or umount before the flash_erase...
9
« on: April 27, 2013, 04:43:03 PM »
You have no avaiable erase_blocks on /proc/yaffs... Seems erase of badblock handling problem... You are not allowed to view links.
Register or Login You are not allowed to view links.
Register or Loginon mount -t yaffs2 /dev/block/mtdblock13 /cache you get msm_onenand_read_oob: from 0x1ef40000 mode 2
datbuf 0xd1378000 datlen 0x840
oobbuf 0x (null) ooblen 0x0
msm_onenand_read_oob: unsupported ops->len, 2112 for MTD_OOB_RAW
msm_onenand_block_isbad: Error in reading bad blk info
yaffs: block 94 is badThe block_isbad function must be wrong... But the code seems ok, reading 4224 bytes. Why the yaffs is trying to read 2112??? That make no sense. How the msm_onenand_block_isbad is trying to read 2112 bytes if the 4224 value is hardcoded??? Did you used that You are not allowed to view links.
Register or Login source???
10
« on: April 27, 2013, 01:47:10 PM »
OuNao,
Here's erikcas's last pastebin: You are not allowed to view links.
Register or Login
Thanks. Seems that the driver still checking for bad blocks on load... And all the blocks are bad??? (read_oob function problem?) Maybe a dmesg with verbose=0 can show us the complete load/erase/mount/touch log...
11
« on: April 27, 2013, 01:37:00 PM »
The erase attempt was not sucessfull. You still get a full cache partion.
Maybe is better build the driver as module and load on init...
What you get on /proc/yaffs?
Can you post the source?
I need a dmesg from the flash_erase attempt, mount and touch.
PS: Today I haven´t access to pastebin (firewall). Can you post on gist?
12
« on: April 15, 2013, 08:36:58 AM »
Hi!
I completly killed my G5 (hardware kill)!!!
I´m buying a new (bigger) phone but I want to continue to help the G5 development team.
So, I need a cheap (used/new) i5500 phone to buy here on brazil (preferable).
Thanks.
13
« on: March 14, 2013, 04:11:52 PM »
Hi psyke83,
could you try to revert my changes and test the module replacing vfree(ar->fw); with kfree(ar->fw); ?
This should fix this problem!
For the sleep problem you can add:
ath6kl_dbg(ATH6KL_DBG_TRC, "********************List empty!***************************\nar->num_vif = %d", ar->num_vif);between lines 1109 and 1110 in main.c. and
ath6kl_dbg(ATH6KL_DBG_TRC, "********************EIO: %d***************************", EIO);between lines 2342 and 2343 in cfg80211.c (I forgot to specify, sorry) only to verify that the problem is in this function...
If the initialization is done with kmemdup (kmalloc variation), the release must be done with kfree... Good!
14
« on: March 14, 2013, 04:08:08 PM »
This is the prototype of this function (line 642)
static int ath6kl_get_fw(struct ath6kl *ar, const char *filename, [b]u8 **fw[/b], size_t *fw_len)
in line 834 there is the call:
ret = ath6kl_get_fw(ar, filename, [b]&ar->fw[/b], &ar->fw_len);
Ops. That correct!!! Thanks. Hi psyke83,
could you try to revert my changes and test the module replacing vfree(ar->fw); with kfree(ar->fw); ?
This should fix this problem!
For the sleep problem you can add:
ath6kl_dbg(ATH6KL_DBG_TRC, "********************List empty!***************************\nar->num_vif = %d", ar->num_vif);between lines 1109 and 1110 in main.c. and
ath6kl_dbg(ATH6KL_DBG_TRC, "********************EIO: %d***************************", EIO);between lines 2342 and 2343 in cfg80211.c (I forgot to specify, sorry) only to verify that the problem is in this function...
If the initialization is done with kmemdup (kmalloc variation), the release must be done with kfree... Good!
15
« on: March 14, 2013, 12:43:05 PM »
Hi OuNao,
galaxy 5 uses the function ath6kl_fetch_fw_api1() at the initialization (line 1117):
Line 460 of the log:
<6>[ 6350.961776] ath6kl: ar6003 hw 2.0 sdio fw 3.1.1.149 api 1
However the function that initialize the value of ar->fw is ath6kl_get_fw() (called at line 834) with a call of kmemdup (line 653).
Adding
ath6kl_dbg(ATH6KL_DBG_BOOT, "Init address of ar->fw %d\n", ar->fw);at line 840 we will see what location of memory is used and replacing the vfree we will see if this changes..
Hummm. Yes Galaxy uses ath6kl_fetch_fw_api1, but that function did not inicializes ar->fw... The Line 460 of the log are related to __ath6kl_init_hw_start You are not allowed to view links.
Register or Login and not to ath6kl_fetch_fw_apin (or api1)... ath6kl_get_fw don´t seems to initialize the ar->fw
|
Show Posts