**** BEGIN LOGGING AT Wed Nov 06 02:59:58 2013 Nov 06 08:07:12 hi lumag Nov 06 08:07:59 so, about this unlocking, the infrastructure seems: Nov 06 08:08:26 1) uapi/mtd/mtd-abi.h defines #define MTD_POWERUP_LOCK 0x2000 /* Always locked after reset */ Nov 06 08:09:06 2) mtd/mtdcore.c does: 385 /* Some chips always power up locked. Unlock them now */ Nov 06 08:09:06 386 if ((mtd->flags & MTD_WRITEABLE) && (mtd->flags & MTD_POWERUP_LOCK)) { Nov 06 08:09:06 387 error = mtd_unlock(mtd, 0, mtd->size); Nov 06 08:09:40 so the unlock is done at core level if the flag is set Nov 06 08:11:13 about CFI we have: Nov 06 08:11:56 1) cfi_cmdset_0001.c static void fixup_unlock_powerup_lock(struct mtd_info *mtd) Nov 06 08:12:04 if (cfip->FeatureSupport&32) { Nov 06 08:12:04 printk(KERN_INFO "Using auto-unlock on power-up/resume\n" ); Nov 06 08:12:31 ^^ the feature-set is verified in the CFI table Nov 06 08:12:48 2) in case smthg goes wrong, som echips add a fixup Nov 06 08:13:13 Conclusion: I'll have to print out the full CFI features Nov 06 08:13:26 but all seems ok Nov 06 08:15:58 I suppose the Feature & 32 is bit 5, instant individual block locking Nov 06 08:19:09 specs on page 67 of the Appendix Nov 06 08:19:20 I'll compare with the readings Nov 06 08:22:20 btw, Intel Strataflash does lack this feature, thus needs fixup Nov 06 08:31:27 hm.. interesting Nov 06 08:31:36 mckoan> koen: I used linux-2.6.30 and I solved it simply using udev 164 Nov 06 08:31:54 I could give it a try with the old 2.6.31 working kernel Nov 06 08:53:44 ah ah Nov 06 08:53:55 about extinction of sa1100 Nov 06 08:54:00 linusw> ant_work: grrr Arnd put in that remark and it is very clear this is no going away soon Nov 06 08:54:14 ant_work: as I own that document I will change it. Nov 06 08:54:14 lol Nov 06 08:54:14 ant_work: so people do not get nervous Nov 06 08:54:14 ant_work: I also heard from people non-hobbyists using the iPAQs for things like inventory and other industrial applications Nov 06 08:54:14 ant_work: so this is not going away any time soon. Nov 06 08:55:04 we can then invest some more time on collie ;) Nov 06 10:35:54 hello ant_work bluelightning Nov 06 10:35:56 ant_work, :) Nov 06 10:36:12 hi lumag, ant_work Nov 06 10:36:39 Regarding fixup. I think atmel uses POWERUP_LOCK unconditionally, w/o checking FeatureSupport & 32 Nov 06 10:40:15 I've found an old thread discussing about the dangers Nov 06 10:40:29 http://lists.infradead.org/pipermail/linux-mtd/2007-November/019872.html Nov 06 10:42:05 Is it in? Nov 06 10:42:31 linusw changed the arm table. Now sa1100 is 'alive and kicking' :) Nov 06 10:43:59 I think I will push my tree somewhere after I implement any pin configuration handling. Nov 06 10:44:08 s/any/the/ Nov 06 10:44:28 sadly linusw can't boot any oe- image on his h3600 Nov 06 10:44:32 init crashes Nov 06 10:44:51 I've received his image: I'll try to boot it on collie with collie kernel Nov 06 10:46:47 If nothing helps I can quickly hack h3xxx in qemu Nov 06 10:47:04 No LCD though :( Nov 06 10:47:08 he says his initramfs boot, ours not Nov 06 10:47:27 fwiw Nov 06 10:47:28 I have forward-ported the h3600 microcontroller patches from v2.6.x Nov 06 10:47:28 backlight, touchscreen and keys are working Nov 06 10:47:28 now I started to fix up these patches for real to upstream them Nov 06 10:47:46 Stupid question. Does he have EABI enabled in kernel? Nov 06 10:48:02 good question: not at the beginning ;) Nov 06 10:48:12 Where are you discussing that? Nov 06 10:48:19 the h3600 defconfig is in OE Nov 06 10:48:23 on #armlinux Nov 06 10:48:31 freenode Nov 06 10:49:42 arm-soc / he and Olof (ojn) are usually there Nov 06 13:25:59 lumag: what could be wrong with the CFI detection finally? Nov 06 13:26:18 it seems to find sa1100-0: 2 set(s) of 2 interleaved chips --> 2 partitions of 16384 KiB Nov 06 13:26:52 sa1100-0: Found 2 x16 devices at 0x0 in 32-bit bank. Manufacturer ID Nov 06 13:26:52 0x0000b0 Chip ID 0x0000b0 Nov 06 13:26:52 sa1100-0: Found 2 x16 devices at 0x1000000 in 32-bit bank Nov 06 13:26:57 4 devices? Nov 06 13:28:00 afaik we have one chip at 0x0 and the other at 0x1000000 Nov 06 14:13:40 fwiw Nov 06 14:13:44 dwmw2: ehm, I suspect there is some miscalculation wrt pair of CFI chips Nov 06 14:13:44 jedec: SA1100 flash: CFI device at 0x00000000, 16MiB, 32-bit Nov 06 14:13:44 cfi: SA1100 flash: CFI device at 0x00000000, 32MiB, 32-bit Nov 06 14:24:16 lumag, and why Nov 06 14:24:18 printk(KERN_INFO "%s: Found %d x%d devices at 0x%x in %d-bit bank. Manufacturer ID %#08x Chip ID %#08x\n", Nov 06 14:24:31 sa1100-0: Found 2 x16 devices at 0x0 in 32-bit bank. Manufacturer ID 0x0000b0 Chip ID 0x0000b0 Nov 06 14:25:18 why is it 6 bytes? 0x00 00 00 Nov 06 14:34:27 ant_work, I think it just finds an alias for those chips Nov 06 14:34:43 See, there are 2 chips connected in parallel at 0x0. Nov 06 14:35:16 The highest address line is unconnected, so it just goes back to 0x0 and ... finds old chips. Nov 06 14:35:40 sorry, I got to go now, I will come back to that later. Nov 06 14:36:57 thx Nov 06 18:15:56 lumag: kernel with CFI debug is building...I'm curious Nov 06 19:08:21 I wander why does it take that much for you to rebuild kernels. Nov 06 19:08:32 Do you do full OE rebuilds with do_rm_work? Nov 06 19:08:38 because it's OE ;) Nov 06 19:09:53 Jay7, one can disable rm_work for linux-yocto and then just call do_compile to get zImage Nov 06 19:11:45 * lumag_ is trying to find a way to read LAKML so that it doesn't take all the time Nov 06 19:36:03 lumag_: http://pastebin.com/ZJC8taev Nov 06 19:39:53 lumag_: I did git pull, that's why. moreover linux-yocto is very long to package Nov 06 19:41:28 yeah. when playing with OE kernel patching I usually just do a lots of do_compile. Otherwise it is toooooooo long to wait for a single change. Nov 06 19:41:49 I did not verify the table with datasheet, but it looks logical. Nov 06 19:42:25 BTW: I would really ask you to print what kernel reads from flash when checking for QRY Nov 06 19:43:32 I'm currently reading Grant's notes from ARM summit. I wonder why do they mark xscale/sa1100 as never-multiplatform Nov 06 19:46:32 I'll try to unbork locomo-spi..I'ma shamed by the logs... Nov 06 19:46:57 now my babysitting turn, brb Nov 06 19:47:07 :) Nov 06 20:25:52 back Nov 06 20:27:14 lumag_: can we remove APM ? Nov 06 20:33:43 I think so. Nov 06 20:34:04 We might need to implement/fix connection between power button and system suspend though. Nov 06 20:34:40 AFAIR Opie can use /sys/class/power to get battery readings Nov 06 20:38:01 hm..I'm seeing that on this last boot MTD mounted RO Nov 06 20:39:05 I'll reboot Nov 06 20:40:37 fun, is RO Nov 06 20:41:50 flash_unlock did finish, though Nov 06 20:42:17 bizarre..maybe I had some extra patching around... Nov 06 20:43:00 good news: ubiformat finishes cleanly Nov 06 20:43:38 this CFI seems an improvement. let's verify that unlock Nov 06 20:47:53 hm.. I did enable OTP support on this kernel build Nov 06 20:47:55 http://pastebin.com/gxXz1AXP Nov 06 20:52:51 Great Nov 06 20:53:00 Did you try reading from otp? Nov 06 20:53:16 not yet Nov 06 20:53:24 otp controlls configuration of 'small' erase blocks Nov 06 20:54:03 seems dangerous, write only once Nov 06 20:54:14 maybe I misread the docs Nov 06 20:54:38 what the purpose? storing i.e. PIN ? Nov 06 20:58:43 ant_home, I'm not sure. Nov 06 20:59:07 or maybe the BIOS parts for old X86 MB Nov 06 20:59:37 Special OTP (One Time Program) block provides an area to store permanent code such as a unique number Nov 06 21:00:01 hm.. imei Nov 06 21:00:13 Then what is the purpose of otp-lock? Nov 06 21:00:16 I don't get that Nov 06 21:00:32 afair there are User and Factory ares Nov 06 21:01:21 According to Kconfig you can not reprogram register. Nov 06 21:01:32 However you can program bits (probably 1 -> 0) Nov 06 21:03:19 I was mistaken Nov 06 21:03:28 partition configuration is a separate register Nov 06 21:04:06 Table 12 in datasheet Nov 06 21:06:08 ok, now I'll try to spit out that Q R Y readings Nov 06 21:08:39 Let's squash that bug! Nov 06 21:08:59 hm.. how should I format the printk? Nov 06 21:09:20 I wonder what will they do to me if I squash together gpio and pinctrl drivers Nov 06 21:09:41 :) Nov 06 21:12:15 I would suggest to print qry[i].x[0] and val[i].x[0] using %lx Nov 06 21:12:22 where i from 0 to 2 Nov 06 21:12:37 trying to follow that map_word Nov 06 21:12:51 ah, ok Nov 06 21:13:15 btw, ther are different funcs for COMPLEX_MAPPINGS Nov 06 21:13:18 It is just a big integer. We are interested in a first word Nov 06 21:13:23 different map_read Nov 06 21:13:33 don't remind me Nov 06 21:13:45 I was trying to dig there once Nov 06 21:13:49 do we need that complex mappings? Nov 06 21:13:50 http://lxr.free-electrons.com/source/include/linux/mtd/map.h#L459 Nov 06 21:14:12 No Nov 06 21:15:35 BTW: Nov 06 21:16:23 what about just dumping first 0x80 map_reads of a flash right before second cfi_qry_present in cfi_qry_mode_on() ? Nov 06 21:34:08 g unsigned int', but argument 2 has type 'map_word' [-Wformat=] Nov 06 21:34:08 printk(KERN_INFO "Here comes Q: %lx\n", qry[0]); Nov 06 21:34:39 ignore? Nov 06 21:41:13 lumag_: http://pastebin.com/fLmYRPx4 Nov 06 21:47:20 so the data is preented in the lowest bytes as documented Nov 06 21:47:37 Here comes Q: 510051 Nov 06 21:47:38 Answer for Q: ffff0051 Nov 06 21:48:03 why 6 bytes for the query? doh Nov 06 21:49:15 lumag_: oh, and btw, nor is now RW ... seems OTP or debug is turning it RO Nov 06 21:50:11 bb in 15 mins, pls think you first about a detection patch ;) Nov 06 22:05:56 lumag_: so we need to do FFFF0051 AND FFFF -> 51 Nov 06 22:06:24 hi bluelightning Nov 06 22:06:36 hi ant_home Nov 06 23:06:34 ant_home, thus I suggested printing qry[0].x[0] Nov 06 23:07:38 I'm trying now to add a 'corrected answer' by adding & 0xffff Nov 06 23:07:41 Hmm. Strange. It looks like one of the chips not receiving the 'read qry' command\ Nov 06 23:08:12 btw, I have to disable the unused interleave/buswidths because are enabled by default otherwise Nov 06 23:08:23 See - lower half is correct (chip acted correctly), upper is not Nov 06 23:08:27 and power man debug Nov 06 23:08:46 iirc it is expected only on the D0-15 Nov 06 23:11:27 No. It expect 0x510051 - it is 0, 'Q', 0, 'Q' Nov 06 23:14:05 Another debug suggestion - could you please add return -1; in the beginning of locomo_probe() - arch/arm/common/locomo.c Nov 06 23:14:56 You will probably also need to temporary disable rtc/cts handling in collie.c Nov 06 23:24:21 ehm.. where exactly ? Nov 06 23:26:31 In collie.c comment all the contents of collie_uart_set_mctrl Nov 06 23:27:13 and limit collie_uart_get_mctrl() to just return TIOCM_CD; Nov 06 23:27:21 ok, on the next build Nov 06 23:27:57 That is just in case locomo somehow interferes with flash reading Nov 06 23:28:15 I've to commit all those small fixes before or I get crazy Nov 06 23:28:23 :) Nov 06 23:29:02 I'll remove the locomo-spi stuff atm Nov 06 23:32:42 spi should not be a problem. Nov 06 23:32:54 If there is a problem, it lies in the core locomo code. Nov 06 23:37:12 hm.. I see CONFIG_MTD_COMPLEX_MAPPINGS=y Nov 06 23:37:22 remove ? Nov 06 23:37:52 Let's try w/o it Nov 06 23:38:04 even physmap is pointless on collie Nov 06 23:38:13 why? Nov 06 23:38:31 do you mean that you get the same errors? Nov 06 23:38:32 there is no prom like on SL-C Nov 06 23:39:02 IIUC sa1100-mtd in physmap + width detection Nov 06 23:39:10 on pxa Z is needed to map the 'rom' on mtd0 iirc Nov 06 23:41:08 You can still use physmap on collie. You just have to specify bus width Nov 06 23:45:12 it is shared zaurus-hardware.cfg:CONFIG_MTD_PHYSMAP=y Nov 06 23:45:17 let it be Nov 06 23:45:56 ok, now I have all the commits up to the CFI detection Nov 06 23:46:59 Would you mind also adding a debug to cfi_send_get_command (include/linux/mtd/cfi.h). Nov 06 23:47:10 there should be only buswidth 32 and interleave 2 Nov 06 23:47:12 Print val.x[0] after val gets set Nov 06 23:47:18 ant_home, yes Nov 06 23:47:37 I'm checking that Nov 06 23:49:55 yes Nov 07 00:04:34 almost built... Nov 07 00:05:58 this kernel is too big for embedded Nov 07 00:06:14 anyway Nov 07 00:14:43 lumag_: http://pastebin.com/pZJp2U1i Nov 07 00:18:13 Strange Nov 07 00:18:18 Command is correct Nov 07 00:19:26 with this patch Nov 07 00:19:36 http://pastebin.com/NZAg2bUx Nov 07 00:22:54 On the other "upper" chip receives some commands Nov 07 00:23:04 It returns 0xffff instead of proper data Nov 07 00:23:20 the appendix sais must be discarded afaik Nov 07 00:23:25 *says Nov 07 00:23:41 ? Nov 07 00:23:49 the Sharp appendix Nov 07 00:24:02 to the docs Nov 07 00:24:30 under point 6. CFI Nov 07 00:24:44 it explains how dta is presented Nov 07 00:50:35 anyway, it seems to me there are too many loops...I'd expect just I2 and WIDTH4 Nov 07 00:51:51 I can't find why.. Nov 07 00:51:53 # Nov 07 00:51:53 # RAM/ROM/Flash chip drivers Nov 07 00:51:53 # Nov 07 00:51:53 CONFIG_MTD_CFI=y Nov 07 00:51:53 # CONFIG_MTD_JEDECPROBE is not set Nov 07 00:51:54 CONFIG_MTD_GEN_PROBE=y Nov 07 00:51:56 CONFIG_MTD_CFI_ADV_OPTIONS=y Nov 07 00:52:00 CONFIG_MTD_CFI_NOSWAP=y Nov 07 00:52:02 # CONFIG_MTD_CFI_BE_BYTE_SWAP is not set Nov 07 00:52:04 # CONFIG_MTD_CFI_LE_BYTE_SWAP is not set Nov 07 00:52:06 CONFIG_MTD_CFI_GEOMETRY=y Nov 07 00:52:08 # CONFIG_MTD_MAP_BANK_WIDTH_1 is not set Nov 07 00:52:10 # CONFIG_MTD_MAP_BANK_WIDTH_2 is not set Nov 07 00:52:12 CONFIG_MTD_MAP_BANK_WIDTH_4=y Nov 07 00:52:14 # CONFIG_MTD_MAP_BANK_WIDTH_8 is not set Nov 07 00:52:16 # CONFIG_MTD_MAP_BANK_WIDTH_16 is not set Nov 07 00:52:18 # CONFIG_MTD_MAP_BANK_WIDTH_32 is not set Nov 07 00:52:20 # CONFIG_MTD_CFI_I1 is not set Nov 07 00:52:22 CONFIG_MTD_CFI_I2=y Nov 07 00:52:24 # CONFIG_MTD_CFI_I4 is not set Nov 07 00:52:26 # CONFIG_MTD_CFI_I8 is not set Nov 07 00:52:30 CONFIG_MTD_OTP=y Nov 07 00:52:32 CONFIG_MTD_CFI_INTELEXT=y Nov 07 00:52:34 # CONFIG_MTD_CFI_AMDSTD is not set Nov 07 00:52:36 # CONFIG_MTD_CFI_STAA is not set Nov 07 00:52:38 CONFIG_MTD_CFI_UTIL=y Nov 07 00:52:40 # CONFIG_MTD_RAM is not set Nov 07 00:52:42 CONFIG_MTD_ROM=y Nov 07 00:52:44 # CONFIG_MTD_ABSENT is not set Nov 07 00:52:46 # CONFIG_MTD_XIP is not set Nov 07 00:52:48 # Nov 07 00:52:50 # Mapping drivers for chip access Nov 07 00:52:52 # Nov 07 00:52:54 CONFIG_MTD_COMPLEX_MAPPINGS=y Nov 07 00:52:56 CONFIG_MTD_PHYSMAP=y Nov 07 00:53:00 # CONFIG_MTD_PHYSMAP_COMPAT is not set Nov 07 00:53:02 CONFIG_MTD_SA1100=y Nov 07 00:53:04 # CONFIG_MTD_PCMCIA is not set Nov 07 00:53:06 # CONFIG_MTD_GPIO_ADDR is not set Nov 07 00:53:08 # CONFIG_MTD_PLATRAM is not set Nov 07 00:53:10 # CONFIG_MTD_LATCH_ADDR is not set Nov 07 00:56:58 * ant_home yawns Nov 07 00:57:02 gn **** ENDING LOGGING AT Thu Nov 07 02:59:58 2013