**** BEGIN LOGGING AT Tue Nov 05 02:59:58 2013 Nov 05 09:25:07 gm lumag_ Nov 05 09:25:25 hello ant_work Nov 05 09:28:24 lumag_: is there a reason to use sa1100-flash instead of physmap? Nov 05 09:29:27 1) it autodetects bank width Nov 05 09:29:43 2) vpp handling Nov 05 09:30:02 Physmap now also supports vpp handling. Nov 05 09:31:18 you know, physmap driver does both cfi and jedec probing and seems of much wider use than sa1100_flash Nov 05 09:31:32 so I bet it has more testing Nov 05 09:33:53 I'll try again to debug cfi detection: I'll hack it so that 'Q' will be enough Nov 05 09:35:29 the Intel docs are not clear: I don't see the case of a 32bit wide bus Nov 05 09:35:47 http://tinyurl.com/qyffbr5 Nov 05 09:59:49 lumag_: finally it must be all about a bit shift..but which one exactly? heh Nov 05 10:00:59 lumag_: ah, about sharpsl_param, I think the readings I've posted are ok Nov 05 10:01:14 ant_work, yes Nov 05 10:01:18 they look correct. Nov 05 10:01:27 I'd have to check in mtd5 Nov 05 10:01:39 So it might be some bad interaction between lcd and locomo/whatever frontlight/backlight. Nov 05 10:01:52 yes, changing the order had some effect Nov 05 10:02:32 I still did not have time to hack around either locomo or sa1100-lcdc support into qemu. Nov 05 10:02:50 And still babysitting, so no access to hardware. Nov 05 10:03:01 :) Nov 05 10:03:49 I'm reading all CFI pdf's in the web.. thre is another interesting one Nov 05 10:03:55 I'm playing with sa1100 cleanup up to 'recent standards' of arm kernels. Nov 05 10:04:36 I've seen on LAKML, great Nov 05 10:04:55 I'm a bit nervous when arm-soc table lists sa1100 as 'wait for extinct'. Nov 05 10:05:15 The biggest problem for sa1100 and pxa will be pcmcia support. Nov 05 10:05:23 At least from my POV. Nov 05 10:05:41 Because currently it is a mess. Nov 05 10:05:52 RMK said he won't let sda1100 die Nov 05 10:05:58 Good. Nov 05 10:06:07 I think one of his servers is sa1100 Nov 05 10:06:50 And scoop code contains lots of mach_is() code. Nov 05 10:07:00 It seems all of that should be converted to regulators. Nov 05 10:07:10 But I am not yet sure. Nov 05 10:07:37 By the way: do you have any irda-capable device other than collie? Nov 05 10:07:49 yes, pxa Zaurus Nov 05 10:07:54 I noticed that collie lacks irda knobs and would like to add them back. Nov 05 10:08:26 and last question: what version of locomo-spi do you use? Nov 05 10:08:51 I saw old patchset by Thomas on lakml. Nov 05 10:09:00 I can send you my patched ver Nov 05 10:09:07 still non-working Nov 05 10:09:14 so you'll read LinusW comments Nov 05 10:10:17 yes, please Nov 05 10:10:43 I would really like to hack locomo support for qemu, Nov 05 10:10:59 LinusW did a rework of all spi drivers last year Nov 05 10:11:42 Because that would allow us to redesign/reimplement locomo driver as a proper mfd driver. Nov 05 10:12:40 we have to adapt to: spi: create a message queueing infrastructure Nov 05 10:16:27 ant_work, I have lost your link with collie dmesg with working jedec probing Nov 05 10:16:37 Do you have it at hand by chance? Nov 05 10:16:39 np Nov 05 10:20:09 I've sent you as extra the CFI docs talking about QRY Nov 05 10:20:36 the Spansion one has some more notes Nov 05 10:25:17 thx Nov 05 10:28:32 lumag_: the old sharp map was patched and bitshift was increased from 23 to 24. What coul dthis suggest to us ?? Nov 05 10:28:33 http://lkml.indiana.edu/hypermail/linux/kernel/0511.0/0345.html Nov 05 10:39:27 I think I have an idea... Nov 05 10:39:32 regarding cfi Nov 05 10:40:32 I'm all ears Nov 05 10:47:45 ant_work, could you please try http://paste.debian.net/64074/ Nov 05 10:48:32 sure, even with (in theory unneeded) unlock addresses? Nov 05 10:48:43 yes Nov 05 10:48:53 This is what (as it seems) jedec does. Nov 05 10:48:59 I'l try afternoon, sure Nov 05 10:49:55 afaik this is what cmdset_0002 does Nov 05 10:51:01 IIUC for CFI things fail even before going to cmdset. Nov 05 10:51:20 right Nov 05 10:55:21 bluelightning: the FILESPATH regression is in dora as well Nov 05 10:55:45 ant_work: er, that change went into dora? Nov 05 10:55:48 ? Nov 05 10:55:52 http://cgit.openembedded.org/openembedded-core/log/?h=dora Nov 05 10:56:42 one of the last commits, maybe cherry-picked Nov 05 11:02:32 ant_work, if this will work, somehow, I belive the following will help with locks: Nov 05 11:02:35 diff --git a/drivers/mtd/chips/cfi_cmdset_0001.c b/drivers/mtd/chips/cfi_cmdset_0001.c Nov 05 11:02:35 index 7751443..5f58196 100644 Nov 05 11:02:35 --- a/drivers/mtd/chips/cfi_cmdset_0001.c Nov 05 11:02:35 +++ b/drivers/mtd/chips/cfi_cmdset_0001.c Nov 05 11:02:35 @@ -310,6 +310,7 @@ static struct cfi_fixup cfi_fixup_table[] = { Nov 05 11:02:36 { CFI_MFR_ST, 0x00ba, /* M28W320CT */ fixup_st_m28w320ct }, Nov 05 11:02:38 { CFI_MFR_ST, 0x00bb, /* M28W320CB */ fixup_st_m28w320cb }, Nov 05 11:02:40 { CFI_MFR_INTEL, CFI_ID_ANY, fixup_unlock_powerup_lock }, Nov 05 11:02:45 + { CFI_MFR_SHARP, 0x00B1, /* LH28F640 */ fixup_unlock_powerup_lock }, Nov 05 11:02:46 { 0, 0, NULL } Nov 05 11:02:48 }; Nov 05 11:02:50 Nov 05 11:04:51 kernel doesn't finish boot this way Nov 05 11:05:12 ? Nov 05 11:05:26 this unlock fixup is ok done as module Nov 05 11:06:21 I've added it to jedec_fixup_ fo rtesting btw Nov 05 11:06:50 Well. Let's see if cfi fix will work. Nov 05 11:07:01 sure Nov 05 11:07:15 Also I'm really interested in DEBUG_CFI_FEATURES/DEBUG_LOCK_BITS output in cmdset_0001 Nov 05 11:07:28 But let's wait for that. Nov 05 11:07:30 heh.. I have to get this code Nov 05 11:07:33 running Nov 05 11:07:46 once cfimode = CFI we'll sdee Nov 05 11:08:10 I'm also tempted to compile OTP support Nov 05 11:08:34 :) Nov 05 11:08:45 step by step... Nov 05 11:09:12 brb Nov 05 11:25:05 I wander why sa1100 cpu freq driver does not need sdram table, but sa1110 uses a table. Nov 05 11:26:44 Ah 1100 does not support sdram Nov 05 11:28:47 w/o filling that data table it would be impossible to enable cpufreq on collie :( Nov 05 14:02:34 lumag_: Nov 05 14:02:41 that's with module? Nov 05 14:02:41 find where it is stuck with the built-in code; what is it waiting for? Nov 05 14:02:41 ok Nov 05 14:02:41 if you do a soft-reboot or kexec from the kernel with the module, into the kernel with the driver built in, does it work then? Nov 05 14:02:41 I'm kexec-booting fwiw Nov 05 14:02:43 I really suspect the set_vpp code and some driver init dependency. Nov 05 14:02:50 try making the map code initialise later (late_initcall or something) Nov 05 14:47:33 Hmm. Let me think about it. Nov 05 14:49:00 set_vpp depends on scoop being initialzied correctly Nov 05 14:49:22 26 #define COLLIE_GPIO_VPEN (COLLIE_SCOOP_GPIO_BASE + 7) Nov 05 14:49:26 Yes Nov 05 14:49:28 I was up to here ;) Nov 05 14:49:32 Do you know where it hangs? Nov 05 14:49:57 not exactly, iirc after unlocking Nov 05 14:50:41 during maybe, as it happens to flash_unlock from shell Nov 05 14:51:59 Hmm. If nothing else helps, printk debugging would at least allow to bisect where it hangs Nov 05 14:54:28 you know, from userland I unlock a single partition but th efixup unlock the full nor Nov 05 14:55:05 What is flash_unlock? Nov 05 14:55:07 don't know what happens to the top blocks (and to the first blocks with diags) Nov 05 14:55:12 Is it from survive*? Nov 05 14:55:16 is the userspace tool Nov 05 14:55:18 hi Jay7 Nov 05 14:55:19 mtd-utils Nov 05 14:56:12 but it fails if mtd is not module Nov 05 14:56:16 as well Nov 05 14:57:13 I'd really suggest to bisect the "halt" point. Nov 05 14:57:18 if flash is built-in Nov 05 14:57:27 ok, full debug Nov 05 14:57:45 DEBUG_DRIVER would help to determine probe function Nov 05 14:58:07 It tells a lot about what is really happening and in which order. Nov 05 14:58:13 ok Nov 05 14:59:49 I have a vague idea it was complaining about some symbol but I'll log it this time :) Nov 05 15:02:06 bluelightning: reproduced the ordering issue? Nov 05 15:02:16 ant_work: I haven't tried Nov 05 15:02:22 I did remind Richard about it Nov 05 15:02:33 ok, great Nov 05 17:51:40 lumag: for some reasons now it did boot with th eunlock fix. Maybe debug added some wait Nov 05 17:53:36 lumag_: http://pastebin.com/wEkrZFSz Nov 05 17:54:57 Most probably. Nov 05 17:55:08 Is that with cfi or with jedec Nov 05 17:55:09 ? Nov 05 17:55:14 still jedec Nov 05 17:55:59 I'l lhave to remove that locomo-spi for the moment Nov 05 17:56:11 and silence the battery code Nov 05 17:59:09 it seems there is some irq problem Nov 05 18:23:43 lumag_: now trying the cfi patch Nov 05 18:24:02 I've added a cfi_send_gen_cmd(0xFF Nov 05 18:24:21 because thi schip supposedly resets with FF Nov 05 20:40:42 ant_home, any progress with cfi? If you had time, of course. Nov 05 20:41:00 I'm retrying right now.. no success until now :/ Nov 05 20:41:13 Hmm. Nov 05 20:41:16 not detected Nov 05 20:41:31 Try changing values in my patch (2aa <-> 155) Nov 05 20:41:49 first one Nov 05 20:42:41 I *think* those unlock addresses are unconditionally added by jedec_probe Nov 05 20:42:55 and this chip shpouldn't really need it Nov 05 20:43:11 anyway, I'll add more variants Nov 05 20:45:32 Also it would be interesting to try to read QRY from jedec probe driver. Nov 05 20:53:12 lumag: you know, this 155 is fishy Nov 05 20:54:02 is 2AA >1 Nov 05 20:54:20 is the hals of the usual tuple Nov 05 20:54:24 the half Nov 05 20:54:38 0x555 0x2AA Nov 05 20:55:38 I'm trying this now Nov 05 20:55:40 <------>cfi_send_gen_cmd(0xF0, 0, base, map, cfi, cfi->device_type, NULL); Nov 05 20:55:40 <------>cfi_send_gen_cmd(0xFF, 0, base, map, cfi, cfi->device_type, NULL); Nov 05 20:55:40 <------>cfi_send_gen_cmd(0xAA, 0x155, base, map, cfi, cfi->device_type, NULL); Nov 05 20:55:40 <------>cfi_send_gen_cmd(0x55, 0x2AA, base, map, cfi, cfi->device_type, NULL); Nov 05 20:55:40 <------>cfi_send_gen_cmd(0x98, 0x155, base, map, cfi, cfi->device_type, NULL); Nov 05 21:25:28 Also it would be interesting if we can read mfr id after these sequence (well, before 0x98 cmd). Nov 05 21:25:35 Hmm. Or after. Nov 05 21:25:42 I'm puzzled about cfi. Nov 05 21:27:27 I'm getting a monster-log :/ Nov 05 21:34:35 well, nothing about CFI but this Nov 05 21:34:36 kobject: 'backlight' (c3ad16a0): kobject_add_internal: parent: 'locomo-backlight', set: '(null)' Nov 05 21:35:11 Oh, my, sa1100 has two pin control units. One for 28 GPIOs that can have an alternate function and another one for 22 peripheral pins which can become a GPIO. Nov 05 21:35:16 Hmm. Nov 05 21:35:30 locomo-bl isn't about CFI ;) Nov 05 21:35:45 yes ;) Nov 05 21:36:16 see if you find smthg while I rebuild... Nov 05 21:36:19 http://pastebin.com/xKqZvJFr Nov 05 21:40:26 Hmm. It responds to those unlock addresses. Nov 05 21:40:48 Ah, my second patch (unlock) probably needs obvious correction s/0xb1/0xb0/ Nov 05 21:41:08 And this was jedec probe, not a cfi probe :( Nov 05 21:41:20 Did you change collie.c? Nov 05 21:45:03 Hmm. Nov 05 21:45:27 It looks like those addresses are not necesessary. You were right. Nov 05 21:46:01 As it switches from interleave=4 to interleave=2, it suddenly finds chips. Nov 05 21:56:01 I don't see lh28f640 handling 0xf0 command. Nov 05 21:56:42 in fact the dosc say FF Nov 05 21:56:58 So we theoretically should hit the second try in cfi_qry_mode_on (for odd chips). Nov 05 21:57:00 I Nov 05 21:57:28 Maybe adding some mdelays inbetween cfi_gen_cmd will help Nov 05 21:57:30 have added a line sending 0xFF after the 0xF0 in code Nov 05 21:57:49 after each one Nov 05 21:58:25 see, this chip has similar quirks like the strataflash documented in the code Nov 05 21:59:18 but being new probably doesn't need to disable couple of buggy features like strataflash Nov 05 22:02:26 Hmm. Note that is is INTEL, not INTEL_EXT. Nov 05 22:02:32 At least according to the appendix Nov 05 22:02:39 well, yes, it is 3 Nov 05 22:02:54 but.. if you see, it supports the Extended cmdset Nov 05 22:03:04 so what is it? Nov 05 22:03:43 anyway this is for jedec only, both take cmdset_0001 Nov 05 22:04:15 (in theory ;) Nov 05 22:04:55 hm..the old map driver did Nov 05 22:04:57 + case 0x00b000b0: Nov 05 22:05:36 Yes, mfr and device id Nov 05 22:05:48 I mean, a read of two words Nov 05 22:16:08 jeez.. again.. gen_probe:genprobe_ident_chips: CFI: Found no sa1100-0 device at location zero Nov 05 22:16:32 I try now to force it to detect Q Nov 05 22:16:38 only Q Nov 05 22:17:13 What are the readings from chips? Nov 05 22:17:47 I completely hate locomo driver. Nov 05 22:18:06 It is done in the same way as we were forbidden to do for Toshiba chips in tosa/eseries. Nov 05 22:19:24 I'd like to try flash detection with OCD but I lack JTAG Nov 05 22:20:00 I remember there was a way to trigger JTAG out of serial port Nov 05 22:20:49 http://marcin.juszkiewicz.com.pl/2006/08/09/sharp-zaurus-jtag-cable/ Nov 05 22:22:39 Ah, it is from service manual. Nov 05 22:23:02 CN2 is parallel port. Nov 05 22:23:22 I have an openmoko jtag board here. Nov 05 22:23:46 Let me check tomorrow, maybe I can arrange to send it to you. Nov 05 22:24:29 Or you can try ordering it locally. Nov 05 22:24:39 It works (*worked) with OpenOCD. Nov 05 22:25:14 But I am not sure if OCD supports sa1100 Nov 05 22:26:29 If you have LPT port on you computer, you can try wiring TS-170 serial cable to support jtag Nov 05 22:33:47 I am not sure, but I don't suspect that OCD will help in our case. Nov 05 22:34:12 well, some routine for reading from userspace would be great Nov 05 22:34:26 reading CFI query I mean Nov 05 22:37:54 Ah, interesting. Nov 05 22:38:06 I reproduced boot lockup in qemu. Nov 05 22:38:21 Even though I am emulating completely different flash Nov 05 22:38:41 oO Nov 05 22:48:20 No. It is a problem in my irq handler :( Nov 05 22:54:50 Ah Nov 05 23:14:51 lumag_: do you remember how to disable the output of collie_battery? Nov 05 23:15:05 CONFIG_POWER_DEBUG=n ? Nov 05 23:15:18 ah, it is not per-driver... Nov 05 23:17:55 CONFIG_POWER_SUPPLY_DEBUG Nov 05 23:37:41 lumag_: \o/ Nov 05 23:37:48 ? Nov 05 23:38:03 sa1100-0: Found 2 x16 devices at 0x0 in 32-bit bank. Manufacturer ID 0x0000b0 Chip ID 0x0000b0 Nov 05 23:38:03 sa1100-0: Found 2 x16 devices at 0x1000000 in 32-bit bank Nov 05 23:38:03 Intel/Sharp Extended Query Table at 0x0039 Nov 05 23:38:03 Intel/Sharp Extended Query Table at 0x0039 Nov 05 23:38:03 Intel/Sharp Extended Query Table at 0x0039 Nov 05 23:38:06 Using buffer write method Nov 05 23:38:08 cfi_cmdset_0001: Erase suspend on write enabled Nov 05 23:38:10 erase region 0: offset=0x0,size=0x20000,blocks=127 Nov 05 23:38:12 erase region 1: offset=0xfe0000,size=0x4000,blocks=8 Nov 05 23:38:14 erase region 2: offset=0x1000000,size=0x20000,blocks=127 Nov 05 23:38:16 erase region 3: offset=0x1fe0000,size=0x4000,blocks=8 Nov 05 23:38:18 sa1100-0: 2 set(s) of 2 interleaved chips --> 2 partitions of 16384 KiB Nov 05 23:38:20 SA1100 flash: CFI device at 0x00000000, 32MiB, 32-bit Nov 05 23:38:22 Creating 3 MTD partitions on "sa1100": Nov 05 23:38:24 0x000000000000-0x0000000c0000 : "bootloader" Nov 05 23:38:26 0x0000000c0000-0x0000001c0000 : "kernel" Nov 05 23:38:28 0x0000001c0000-0x000000fe0000 : "rootfs" Nov 05 23:38:33 o-o! Nov 05 23:38:38 I did not add the unlock line Nov 05 23:38:47 just forced the two probes to return 1 Nov 05 23:39:01 so is just initial misdetection Nov 05 23:39:21 ok, now I'll readd the fixup Nov 05 23:39:23 the qry_ok ? Nov 05 23:40:13 diff --git a/drivers/mtd/chips/cfi_util.c b/drivers/mtd/chips/cfi_util.c Nov 05 23:40:13 index f992418..007dcec 100644 Nov 05 23:40:13 --- a/drivers/mtd/chips/cfi_util.c Nov 05 23:40:13 +++ b/drivers/mtd/chips/cfi_util.c Nov 05 23:40:13 @@ -47,7 +47,7 @@ int __xipram cfi_qry_present(struct map_info *map, __u32 base, Nov 05 23:40:13 if (!map_word_equal(map, qry[2], val[2])) Nov 05 23:40:13 Is the flash writeable w/o fixup? Nov 05 23:40:15 return 0; Nov 05 23:40:17 Nov 05 23:40:19 - return 1; /* "QRY" found */ Nov 05 23:40:21 + return 0; /* "QRY" found */ Nov 05 23:40:23 } Nov 05 23:40:25 EXPORT_SYMBOL_GPL(cfi_qry_present); Nov 05 23:40:27 Nov 05 23:40:29 @@ -85,7 +85,7 @@ int __xipram cfi_qry_mode_on(uint32_t base, struct map_info *map, Nov 05 23:40:31 if (cfi_qry_present(map, base, cfi)) Nov 05 23:40:33 return 1; Nov 05 23:40:37 /* QRY not found */ Nov 05 23:40:39 - return 0; Nov 05 23:40:41 + return 1; Nov 05 23:40:43 } Nov 05 23:40:45 EXPORT_SYMBOL_GPL(cfi_qry_mode_on); Nov 05 23:40:47 Nov 05 23:40:49 mom, I'll try Nov 05 23:40:57 :) Nov 05 23:41:04 yes, seems so Nov 05 23:41:09 So it's some problem with qry Nov 05 23:41:12 even w/o fixup? Nov 05 23:41:14 Coool Nov 05 23:41:22 I'm double-checking Nov 05 23:42:00 So it is really a problem of getting to QRY mode. Nov 05 23:42:05 ubiformat: formatting eraseblock 112 -- 100 % complete Nov 05 23:42:39 the only other diff is ofc Nov 05 23:42:40 - .map_name = "jedec_probe", Nov 05 23:42:40 + .map_name = "cfi_probe", Nov 05 23:43:14 Note: your fix also removed aliasing detection. So be double-safe not to overwrite a bootloader. Nov 05 23:44:14 I think we should add ro,lk to the partition Nov 05 23:44:27 lk == locked should make it skip Nov 05 23:45:11 the unlocking Nov 05 23:47:55 Not sure if it will work out of box. Nov 05 23:48:03 too late now Nov 05 23:48:13 I'll check deeply tomorrow Nov 05 23:48:24 The next question would be to really dump those qry values. Nov 05 23:48:40 I think there is some bitshift to do Nov 05 23:48:57 we have to check the other fixups Nov 05 23:49:29 Maybe it misreports itself - e.g. returns QQ instead of 0x0,Q on the 16-bit bus Nov 05 23:49:37 Just guessing though. Nov 05 23:50:00 hm..looking now at the eraseregions Nov 05 23:50:12 we have to force it to detect top-boot Nov 05 23:51:11 I am not sure, but if the flash reports them in this way, they are (right now) configure this way. Nov 05 23:51:32 ah, right, is CFI Nov 05 23:51:52 OTOH CFI can have mistakes. Nov 05 23:51:56 :p Nov 05 23:52:16 I've seen code fixing the detection of top-boot somewhere Nov 05 23:52:33 I'll check tomorrow Nov 05 23:52:49 have to wake up earlier tomorrow Nov 05 23:52:59 bye Nov 05 23:53:02 gn Nov 05 23:53:45 gn **** ENDING LOGGING AT Wed Nov 06 02:59:58 2013