**** BEGIN LOGGING AT Wed Oct 30 02:59:58 2013
Oct 30 10:15:23 <ant_work> lumag: I might have some ideas about the mtd failure when NOT built as modules
Oct 30 10:16:02 <ant_work> lumag: in gen_probe.c there is an #ifdef CONFIG_MODULES
Oct 30 10:17:30 <ant_work> lumag: unfortunately I don't seem to understand that code easily...
Oct 30 10:18:37 <ant_work> there is a note as well some lines later
Oct 30 10:18:39 <ant_work> 		   because symbol_get() doesn't work there */
Oct 30 10:22:43 <ant_work> ah...there is a recent commit of 2013 touching modules in 3.10
Oct 30 10:23:14 <ant_work> and one later in august (not in 3.10) refactor call to request_module
Oct 30 10:23:22 <ant_work> both touching that stuff...suspicious
Oct 30 10:26:17 <lumag> ant_work, hello
Oct 30 10:26:31 <ant_work> gm
Oct 30 10:28:10 <lumag> ant_work, that is a nice way to confuse anybody.
Oct 30 10:28:42 <lumag> check_cmd_set has ifdefs guarding calls to cfi_cmset if those cmdsets are built into kernel
Oct 30 10:28:53 <lumag> Otherwise cfi_cmdset_unknown is called.
Oct 30 10:30:14 <lumag> It checks if the corresponding symbol (function cfi_cmdset_xxx) is already present
Oct 30 10:30:33 <ant_work> see this changelogs
Oct 30 10:30:34 <ant_work> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/drivers/mtd/chips?id=refs/tags/v3.12-rc7
Oct 30 10:30:36 <lumag> Otherwise it requests a corresponding module, rereads the symbol and then calls it on top
Oct 30 10:30:50 <lumag> Hmm
Oct 30 10:30:54 <lumag> I have 3.12-rc2
Oct 30 10:30:57 <lumag> Let me update
Oct 30 10:31:20 <ant_work> I'm still teting MTD with 3.10
Oct 30 10:31:23 <ant_work> +s
Oct 30 10:33:19 <lumag> Do you mean 'refactor call to request_module' commit?
Oct 30 10:33:27 <lumag> It should not change anything for you.
Oct 30 10:33:49 <lumag> Basically, if you see cfi_cmdset_001 being called for the flash, you can assume that the error is later.
Oct 30 10:34:12 <lumag> that code only concerns a way to call cfi_cmdset probes. If it is called, you are on a safe side.
Oct 30 10:34:47 <ant_work> and  CONFIG_SYMBOL_PREFIX: cleanup ?
Oct 30 10:34:59 <lumag> Hmm
Oct 30 10:35:05 <lumag> What is the commit id?
Oct 30 10:35:17 <ant_work> 	b92021b09df70c1609e3547f3d6128dd560be97f
Oct 30 10:36:06 <ant_work> and in  	660685d9d1b4730f0b5ca97fa95f272f99c63bce  they say
Oct 30 10:36:06 <lumag> Looks innocent to me.
Oct 30 10:36:15 <ant_work> "And Yay! we get to kill off an instance of checking CONFIG_foo_MODULE, which is an abomination that should never happen.]"
Oct 30 10:36:34 <ant_work> I have to retry with an older 3.x kernel
Oct 30 10:36:59 <lumag> Any luck with debugging cfi probe code?
Oct 30 10:37:27 <ant_work> not yet done..build was stopped by stupid m4 error
Oct 30 10:37:45 <ant_work> so this morning I've relaunched one before going to work
Oct 30 10:38:08 <ant_work> today I'll check both sharpslparam and gen_probe
Oct 30 10:38:34 <lumag> ok
Oct 30 10:39:01 <ant_work> it's hard to think nobody had noticed so big breakage (no boot from flash..)
Oct 30 10:39:09 <ant_work> maybe it is sa1100 specific
Oct 30 10:39:45 <lumag> I have a day dedicated to telcos, so I might have a chance to look on qemu StrongARM LCD emulation. Maybe that will help with fbdev issues
Oct 30 10:40:01 <ant_work> ah, the nasty one...
Oct 30 10:40:19 <ant_work> thesing had some fixes for that but afair those won't apply anymore
Oct 30 10:40:27 <ant_work> one was hardcoding the freq
Oct 30 10:40:51 <lumag> do you have a link?
Oct 30 10:41:04 <ant_work> git here
Oct 30 10:41:05 <ant_work> http://linuxtogo.org/cgi-bin/gitweb.cgi?p=thesing/collie.git;a=summary
Oct 30 10:42:43 <ant_work> 50f374a8cbc593635cc43e7fa356bb91032fdb7c
Oct 30 10:44:05 <ant_work> lumag: fb  http://tinyurl.com/p55ojz4
Oct 30 10:44:37 <lumag> A whole lot of interesting patches for collie.
Oct 30 10:44:48 <lumag> Why did he not push them into upstream :(
Oct 30 10:45:32 <ant_work> also this one for kb:  http://tinyurl.com/p3cglk3
Oct 30 10:45:43 <ant_work> most patches are now upstream, not all :/
Oct 30 10:51:08 <ant_work> bluelightning: RP commit did fix the general case but sum.jffs2 for collie is still wrong
Oct 30 10:54:31 <bluelightning> ant_work: hmm, I haven't seen his fix yet
Oct 30 10:54:46 <ant_work> is top-commit -1 atm
Oct 30 10:56:37 <ant_work> after my last patches, if you don't define EXTRA_IMAGECMD_sum.jffs2(_collie) for collie the standard one is used (wrong, without padding and with cleanmarkers)
Oct 30 10:57:35 <ant_work> if you define it, the --pad=xy option is passed to mkfs.jffs2 (correct) and to sumtool as well (wrong)
Oct 30 10:57:58 <ant_work> and we do need it for mkfs.jffs2
Oct 30 11:14:53 <ant_work> for NOR, flashcpy does not have the -pad option like nandwrite (for...NAND) has
Oct 30 11:15:29 <ant_work> anyway, tbh, collie mtd size is so small that I'm not so convinced it needs jffs2 summary....
Oct 30 11:17:01 <ant_work> I'll give a last try putting the sumtool stuff in the EXTRA_IMAGECMD_jffs2 of collie (as it was done in oe-classic)
Oct 30 11:18:10 <ant_work> same for ubifs images: core-image-base is a bit too large and there aren't enough eraseblocks
Oct 30 11:19:27 <ant_work> (kernel is still too big in size, 3MB)
Oct 30 11:28:15 <lumag> ant_work, do you remember by chance, does collie use sa-1100 or sa-1110 ?
Oct 30 11:28:37 <ant_work> afaik 1100
Oct 30 11:32:12 <ant_work> CPU: StrongARM-1110 [6901b118] revision 8 (ARMv4), cr=c000717f
Oct 30 11:32:18 <lumag> ok ,thanks
Oct 30 11:32:22 <ant_work> heh
Oct 30 11:34:08 <ant_work> service man says SA1110 Rev.B4
Oct 30 11:36:06 <ant_work> by the way, looking at that log I see  vmalloc : 0xc4800000 - 0xff000000   ( 936 MB)
Oct 30 11:36:45 <ant_work> our params should be here but how are they in VM? The bootloader put them lower I guess..
Oct 30 11:37:08 <lumag> bb in 1/2 hour
Oct 30 11:37:19 <ant_work> >  #ifdef CONFIG_ARCH_SA1100
Oct 30 11:37:19 <ant_work> >  #define PARAM_BASE	0xe8ffc000
Oct 30 11:37:20 <ant_work> bbl
Oct 30 11:37:31 * ant_work -> snack
Oct 30 11:55:02 <lumag> ant_work, it looks like on collie params are read directly from flash.
Oct 30 11:55:28 <lumag> You should be able to find them at mtd0, offset 0xffc000
Oct 30 11:56:38 <lumag> Probably they are stored in flash also on pxa zaurii, but in NAND instead of NOR/rom, so they are not directly addressable.
Oct 30 12:11:33 <ant_work> lumag: why not addressable on pxa?you know, I have always in mind a module for reading the mtdparts..we could read the params as well
Oct 30 12:11:50 <lumag> NAND is usually not addressable
Oct 30 12:12:01 <lumag> Ah, that is true
Oct 30 12:13:16 <ant_work> anyway, you suspect this address is overwritten by the kernel isn't?
Oct 30 12:13:22 <ant_work> (on collie)
Oct 30 12:13:28 <lumag> If it is in NOR, then not.
Oct 30 12:13:40 <ant_work> the virtual address as well?
Oct 30 12:13:47 <lumag> Yes.
Oct 30 12:13:56 <lumag> Hmm. I don't get it.
Oct 30 12:14:03 <lumag> I did a dd of /dev/mtd0 on 2.4 kerne
Oct 30 12:14:04 <lumag> I did a dd of /dev/mtd0 on 2.4 kernel
Oct 30 12:14:22 <lumag> I got 16 Mb file.
Oct 30 12:14:35 <lumag> But it doesn't contain params.
Oct 30 12:14:52 <ant_work> hm.. my dump is here  http://tinyurl.com/o24sh3m
Oct 30 12:15:22 <lumag> Mine contains only cramfs.
Oct 30 12:15:39 <lumag> At least it does not contain "Uncompressing Linux" string
Oct 30 12:21:57 <lumag> I really don't get that.
Oct 30 12:22:01 <ant_work> 8MByte ROM (OTP? NOR-Flash?) at physical address 0x00000000, mirrored (at least) at 0x00800000
Oct 30 12:22:17 <ant_work> this was the page about angel debug monitor
Oct 30 12:22:40 <lumag> Hmm. I should try dumping /dev/mem
Oct 30 12:23:03 <lumag> But where does that angel live?
Oct 30 12:23:12 <lumag> Hmmm.
Oct 30 12:23:14 <ant_work> in the first 'partition'
Oct 30 12:23:20 <ant_work> see the old mtdparts
Oct 30 12:23:23 <lumag> Does locomo contain nor in it's own?
Oct 30 12:23:24 <ant_work> of 2.4
Oct 30 12:23:26 <lumag> Strange...
Oct 30 12:25:12 <lumag> Dirty dumbs.
Oct 30 12:26:26 <lumag> They map 16MB, but not from the start of the rom.
Oct 30 12:26:44 <ant_work> The Collie's /proc/mtd shows this:
Oct 30 12:26:44 <ant_work> dev:    size   erasesize  name
Oct 30 12:26:44 <ant_work> mtd0: 00020000 00020000 "Angel Monitor"
Oct 30 12:26:44 <ant_work> mtd1: 00020000 00020000 "CF Updater"
Oct 30 12:26:45 <ant_work> mtd2: 00080000 00020000 "Diagnostics"
Oct 30 12:26:45 <ant_work> mtd3: 00100000 00020000 "kernel"
Oct 30 12:26:47 <ant_work> mtd4: 00e20000 00020000 "jffs2"
Oct 30 12:26:49 <ant_work> mtd5: 00020000 00020000 "angel stuff"
Oct 30 12:26:55 <ant_work> this was ex-factory
Oct 30 12:27:10 <ant_work> if you see, the last part is the 'boot block'
Oct 30 12:27:54 <ant_work> I suspect all params are there, in the top block
Oct 30 12:29:40 <ant_work> (which is not mapped actually)
Oct 30 12:34:19 <lumag> Looks so
Oct 30 12:35:48 <lumag> Yes, I found params in my nor dump.
Oct 30 12:35:50 <lumag> 00e3c000  43 4d 41 44 56 00 00 00  ff ff ff ff ff ff ff ff  |CMADV...........|
Oct 30 12:35:50 <lumag> 00e3c010  ff ff ff ff ff ff ff ff  ff ff ff ff 54 55 43 48  |............TUCH|
Oct 30 12:35:50 <lumag> 00e3c020  f8 c5 8d 3e 8a 50 c4 3e  e9 ff ff ff d1 ff ff ff  |...>.P.>........|
Oct 30 12:35:50 <lumag> 00e3c030  42 56 41 44 94 02 00 00  ff ff ff ff ff ff ff ff  |BVAD............|
Oct 30 12:35:50 <lumag> 00e3c040  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
Oct 30 12:35:58 <lumag> This is shifted by 1c0000
Oct 30 12:36:32 <lumag> And before that:
Oct 30 12:36:37 <lumag> 00e1a000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
Oct 30 12:36:37 <lumag> *
Oct 30 12:36:37 <lumag> 00e2c000  52 4c 56 35 0a 00 00 00  ff ff ff ff ff ff ff ff  |RLV5............|
Oct 30 12:36:37 <lumag> 00e2c010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
Oct 30 12:36:37 <lumag> *
Oct 30 12:36:38 <lumag> 00e34000  53 48 41 52 50 20 53 4c  2d 73 65 72 69 65 73 20  |SHARP SL-series |
Oct 30 12:36:40 <lumag> 00e34010  00 00 13 03 c9 a3 02 00  ff ff ff ff ff ff ff ff  |................|
Oct 30 12:36:42 <lumag> 00e34020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
Oct 30 12:36:46 <lumag> *
Oct 30 12:36:48 <lumag> 00e38000  42 4f 4f 54 53 48 50 32  42 49 4e 00 5a 78 ff ff  |BOOTSHP2BIN.Zx..|
Oct 30 12:36:50 <lumag> 00e38010  32 30 30 32 30 31 32 36  00 00 00 00 00 00 02 00  |20020126........|
Oct 30 12:36:52 <lumag> 00e38020  43 46 20 20 20 20 20 20  42 49 4e 00 5d fd ff ff  |CF      BIN.]...|
Oct 30 12:36:54 <lumag> 00e38030  32 30 30 32 30 31 32 36  00 00 02 00 00 00 04 00  |20020126........|
Oct 30 12:36:56 <lumag> 00e38040  43 4f 4c 4c 49 45 20 20  42 49 4e 00 4d e4 ff ff  |COLLIE  BIN.M...|
Oct 30 12:36:58 <lumag> 00e38050  32 30 30 32 30 32 32 31  00 00 04 00 00 00 0c 00  |20020221........|
Oct 30 12:37:00 <lumag> 00e38060  5a 49 4d 41 47 45 20 20  20 20 20 00 ed 97 ff ff  |ZIMAGE     .....|
Oct 30 12:37:02 <lumag> 00e38070  32 30 30 33 30 35 30 39  00 00 0c 00 00 00 1c 00  |20030509........|
Oct 30 12:37:04 <lumag> 00e38080  52 4f 4d 44 49 53 4b 20  42 49 4e 00 d8 b1 ff ff  |ROMDISK BIN.....|
Oct 30 12:37:06 <lumag> 00e38090  32 30 30 33 30 37 30 32  00 00 1c 00 00 00 fe 00  |20030702........|
Oct 30 12:37:08 <lumag> 00e380a0  45 4e 44 20 20 20 20 20  20 20 20 00 00 00 ff ff  |END        .....|
Oct 30 12:37:10 <lumag> 00e380b0  31 39 38 30 30 30 30 30  00 00 00 00 00 00 00 00  |19800000........|
Oct 30 12:37:12 <lumag> 00e380c0  45 4c 41 54 45 20 20 20  42 49 4e 00 00 00 ff ff  |ELATE   BIN.....|
Oct 30 12:37:16 <lumag> 00e380d0  31 39 38 30 30 33 30 34  00 00 00 00 01 00 00 00  |19800304........|
Oct 30 12:37:18 <lumag> 00e380e0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
Oct 30 12:39:51 <lumag> Hmm,
Oct 30 12:40:04 <lumag> collie_defconfig contains only CONFIG_MTD_CFI_I4
Oct 30 12:40:11 <lumag> It should contains at least _I2 also
Oct 30 12:41:13 <ant_work> which one are you looking at?
Oct 30 12:41:45 <ant_work> until recently the jedec defs were for 4 8M chips
Oct 30 12:42:01 <ant_work> so probably the defconfig in kernel tree still reflects that
Oct 30 12:42:28 <lumag> I'm looking at linux-next.
Oct 30 12:42:30 <lumag> I think so
Oct 30 12:42:49 <ant_work> ok, iirc it was Pavel work back in 2008
Oct 30 12:42:54 <ant_work> or before...
Oct 30 12:43:03 <lumag> No.
Oct 30 12:43:07 <lumag> I was not.
Oct 30 12:43:32 <ant_work> http://www.infradead.org/pipermail/linux-mtd/2005-November/014273.html
Oct 30 12:44:27 <ant_work> I start thinking that Sharp has done som ecamouflage and there are other chips internally :)
Oct 30 12:45:30 <ant_work> with 4 chips, it would be impossible to match the 'boot block' top partition with regions
Oct 30 12:49:19 <lumag> Ah. And old kernel contains neither CFI nor jedec detection :(
Oct 30 12:50:27 <ant_work> I'm pretty sure I've seen in some header the offsets of those sharpsl_params, maybe in an old 2.4
Oct 30 12:50:42 <ant_work> googling now...
Oct 30 12:52:00 <lumag> The offset is ffc000
Oct 30 12:52:10 <lumag> In my case just the whole file is shifted.
Oct 30 12:52:15 <lumag> It starts at 1c0000
Oct 30 12:52:17 <ant_work> there were some #define for that vars iirc
Oct 30 12:52:58 <ant_work> why this shift? do you think is a recent change?
Oct 30 12:55:01 <lumag> I dumped with 2.4 kernel.
Oct 30 12:56:16 <lumag> It maps rom with an offset to the beginning of real rom.
Oct 30 12:56:39 <lumag> So mtd0 starts with 0x1c0000 - it is rootfs
Oct 30 13:08:04 <lumag> Regarding the fb.
Oct 30 13:08:08 <lumag> I can suspect e1b7a72aeb8292502c97b43eceb01aea47ded40f
Oct 30 13:08:24 <lumag> Or beca98c93dc8d838c3656bc62fd49b45622ef788
Oct 30 13:09:50 <ant_work> eib7a is rather recent..fb was b0rked with 2.6.32
Oct 30 13:10:57 <ant_work> I can't fully appreciate the impact of the beca98c
Oct 30 13:11:21 <ant_work> but things were broken before 2012 afair
Oct 30 13:16:10 <ant_work> bluelightning: err.. the commit is in master-next
Oct 30 13:16:13 * ant_work hides
Oct 30 13:16:19 <bluelightning> ant_work: ah I see
Oct 30 13:16:32 <ant_work> I'll retry
Oct 30 13:17:14 <ant_work> btw can you pls try to rebuild md4-native?
Oct 30 13:17:26 <ant_work> wow...m4-native
Oct 30 13:21:59 <ant_work> lumag: imagine the poor bluelightning was flashing all linux-kexecboot I've sent to him from 2.6.31 onwards. None properly booting because we realized recently there was a klibc issue and the BX instruction was used on armv4 ...
Oct 30 13:22:36 <lumag> :(((
Oct 30 13:22:44 <bluelightning> oh well, at least you found the problem...
Oct 30 13:22:46 <ant_work> neverthless the last kernel giving bootlogo is 2.6.31
Oct 30 13:22:55 <bluelightning> (sounds like anyway)
Oct 30 13:23:51 <lumag> ant_work, btw: kexecboot needs some splash screen. On tosa it takes some time to dig through all devices.
Oct 30 13:24:08 <ant_work> use ubifs ;)
Oct 30 13:24:23 <lumag> And I can understand if things are good or bad only thanks to nand LED flashing somewhere during scan.
Oct 30 13:24:45 <ant_work> it takes long time mounting the jffs2 images it finds
Oct 30 13:24:45 <lumag> ok.
Oct 30 13:25:05 <ant_work> more if these are with old JFFS headers (2.4)
Oct 30 13:25:32 <lumag> I've built 2.4 kexec (hopefully). Now building initramfs for collie, so I wille be able to run some experiments.
Oct 30 13:26:03 <ant_work> great
Oct 30 13:26:51 <ant_work> bluelightning: pls check out those two last patches for meta-hh and evtl. commit
Oct 30 13:27:12 <ant_work> lumag: you can use OE again to build images now
Oct 30 13:28:05 <lumag> ant_work, I'm using a master 2 days old.
Oct 30 13:28:12 <lumag> Should I pull new versions?
Oct 30 13:28:35 <lumag> I'm building non-klibc initramfs
Oct 30 13:31:53 <bluelightning> ant_work: so these are still needed after RP's fix?
Oct 30 13:32:06 <bluelightning> ant_work: sorry I have not had time to look at the details
Oct 30 13:32:17 <ant_work> well, the first one has nothing to do with Z
Oct 30 13:32:34 <ant_work> the second is ok for all apart colle, which will need a separate declaration
Oct 30 13:32:52 <ant_work> I have tocheck but I think we can even remov ethe line in zaurus.inc
Oct 30 13:32:59 <ant_work> after RP patch
Oct 30 13:33:08 <ant_work> it doesn't harm anyway
Oct 30 13:33:18 <ant_work> in case it just repeats the defaults
Oct 30 13:34:40 <ant_work> "which will then allow a EXTRA_IMGAGECMD to be set for
Oct 30 13:34:41 <ant_work> sum.jffs2 individually without changing the jffs2 command"
Oct 30 13:35:36 <ant_work> lumag: problems only with sum.jffs2 images
Oct 30 13:35:58 <ant_work> the other types are built well
Oct 30 13:36:46 <ant_work> note that kernel is still huge (need to filter out RAID and many stuff not used on Z)
Oct 30 13:37:23 <ant_work> and that you can only boot CF atm
Oct 30 13:41:09 <ant_work> bluelightning: we may add a 'Filesystems' section in machine.con, between hw and soft
Oct 30 13:41:36 <ant_work> so we put there the JFFS2_ERASEBLOCK and customizations
Oct 30 13:44:06 <ant_work> and the dumps of proc/mtd
Oct 30 13:44:28 <ant_work> so th enext-gen developer will not have to google overnight ;)
Oct 30 16:43:26 <ant_work> bbl
Oct 30 17:02:29 <lumag> Spent significant amount of time debugging why the kernel does not start my initrd only to find that collie_defconfig does not have AEABI=y
Oct 30 17:02:31 <lumag> RRRR
Oct 30 21:01:54 <ant_home> lumag: :/
Oct 30 21:02:10 <ant_home> (reading logs)
Oct 30 23:15:24 <ant_home> bluelightning, things are ok now wrt jffs2
Oct 30 23:16:12 <ant_home> pls apply my pending patches, RP will also commit his one
Oct 30 23:16:34 <bluelightning> ant_home: ok, will do now
Oct 30 23:20:12 <ant_home> once all is committed we'l lsee if we can remove form zaurus.inc the EXTRA_IMAGECMD_sum.jffs2
Oct 30 23:33:07 <ant_home> lumag:
Oct 30 23:33:11 <ant_home> DMA: preallocated 256 KiB pool for atomic coherent allocations
Oct 30 23:33:12 <ant_home> COMADJ 1145130307
Oct 30 23:33:12 <ant_home> PHAD -1
Oct 30 23:33:12 <ant_home> UUID -1
Oct 30 23:33:12 <ant_home> TOUCH 1212372308
Oct 30 23:33:12 <ant_home> ADADJ -1
Oct 30 23:33:14 <ant_home> Sharp Scoop Device found at 0x40800000 -> 0xc4846000
Oct 30 23:34:53 <bluelightning> ant_home: ok done
Oct 30 23:36:29 <ant_home> thx
Oct 31 00:06:26 <ant_home> lumag: in /proc/vmallocinfo I see :
Oct 31 00:06:27 <ant_home> 0xe8000000-0xea000000 33554432 iotable_init+0x0/0xbc ioremap
Oct 31 00:06:27 <ant_home> 0xea000000-0xec000000 33554432 iotable_init+0x0/0xbc phys=8000000 ioremap
Oct 31 00:18:31 <ant_home> gn
**** ENDING LOGGING AT Thu Oct 31 02:59:58 2013