**** BEGIN LOGGING AT Thu Oct 31 02:59:58 2013 Oct 31 09:59:07 ant_work, COMADJ looks strange Oct 31 09:59:15 hi Oct 31 09:59:33 it was a printk %d, I'd have done hex :/ Oct 31 09:59:39 it's DAMC Oct 31 09:59:44 the bytes are swapped, yes Oct 31 09:59:49 no, no. Oct 31 09:59:54 comadj should be one-byte value Oct 31 10:00:00 ah Oct 31 10:00:16 and your value is 0x44414d43 Oct 31 10:00:50 MAGIC_CHG(a,b,c,d) ( ( d << 24 ) | ( c << 16 ) | ( b << 8 ) | a ) Oct 31 10:01:40 I have to map mtd5 and dump it Oct 31 10:01:56 In my case (see yesterday) 'CMAD' is the 'magic' for comadj. Oct 31 10:01:57 I dont' find any param in mtd0 Oct 31 10:02:12 just service menu and cf-flasher Oct 31 10:02:36 morning ant_work, lumag Oct 31 10:02:47 and real value is after that. 0x56000000 Oct 31 10:03:02 bluelightning, evening :) Oct 31 10:03:23 ok, I see, I was looking for 43 4d 41 44 56 Oct 31 10:03:39 as in your dump, or smthg similar at least Oct 31 10:04:05 In your case it should be in mtd5 Oct 31 10:04:34 fwiw I've inspected the full 3.3 16MB rom-update and I couldn't find the string there Oct 31 10:05:03 Ospack or how it is called Oct 31 10:05:16 hi bluelightning Oct 31 10:06:25 lumag: afais th eioremap shows an offset Oct 31 10:06:54 ant_work, Most probably it is not present in Ospack - it is a calibrated value, not something 'facture-provided' Oct 31 10:07:57 0xe8000000-0xea000000 33554432 iotable_init+0x0/0xbc ioremap Oct 31 10:07:59 0xea000000-0xec000000 33554432 iotable_init+0x0/0xbc phys=8000000 ioremap Oct 31 10:10:17 lumag: you know, we'll end up disassembling the bootloader ... Oct 31 10:10:29 if I only could read assembler... Oct 31 10:10:35 Tried doing that some time ago (for tosa). Oct 31 10:10:54 ant_work, it is a basic but with different syntax Oct 31 10:11:00 really. Oct 31 10:11:07 and variables are fixed. Oct 31 10:11:22 I played a bit with it with z80 long long ago ;) Oct 31 10:12:20 then I realized I prefere high-level stuff..and now I'm back to the bare asm ;) Oct 31 10:16:36 lumag: naive question: does 'iotable_init+0x0/0xbc' mean there is an offset of 188bytes? Oct 31 10:17:38 Usually not. I don't know about vmallocinfo, but usually (sic) such field means that address is at offset 0x0 from iotable_init, which is 0xbc bytes long. Oct 31 10:18:57 ant_work, I can't come up with good guide on ARM asm. But it is really simple, esp. when no coprocessors are in play. Oct 31 10:20:39 you know, I was rememering that the atags have been also relocated because after some change they were overwritten Oct 31 10:21:03 so maybe there is a 'shift' and the params are at another address Oct 31 10:21:55 somehow it is done by the kernel, the bootloader can just pass the params at some physical address, isn't? Oct 31 10:23:01 ant_work, Just check what value comes after that 0x4441... Oct 31 10:23:11 It should be real comadj value. Oct 31 10:23:51 I tried playing with kexec for 2.4, but got no real results. Oct 31 10:24:07 Maybe it needs some adaptations for sa1100 (it was used for PXA as it seems). Oct 31 10:26:03 And 2.4 kernel fails to boot under qemu :( Oct 31 10:26:50 Another idea regarding collie & framebuffer. Oct 31 10:27:31 try rearraging lines in drivers/video/Makefile - move obj-y += blacklight/ to the end of the file. Oct 31 10:28:37 I'll try Oct 31 11:26:23 ant_work: would you be able to test Tartarus's udev patch on one of our machines? Oct 31 11:26:27 http://patchwork.openembedded.org/patch/60387/ Oct 31 11:29:35 ah, yes, I even though it was committed **** ENDING LOGGING AT Fri Nov 01 02:59:58 2013