| 03:48.31 | *** join/#openezx kundan (~kundan@117.200.84.187) |
| 05:51.07 | *** part/#openezx kundan (~kundan@117.200.84.187) |
| 06:37.01 | *** join/#openezx stefan_schmidt (~stefan@2001:638:602:1183:cda5:2bfc:7471:f49a) |
| 06:57.13 | *** join/#openezx ao2 (~ao2@2001:1418:117::1) |
| 07:13.10 | *** join/#openezx flo_lap (~fuchs@Maemo/community/contributor/florian) |
| 08:16.30 | *** join/#openezx florian_kc (~fuchs@Maemo/community/contributor/florian) |
| 08:21.47 | *** join/#openezx bluelightning (~paul@83.217.123.106) |
| 08:21.47 | *** join/#openezx bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 08:59.43 | *** join/#openezx mickey|office (~Mickey@business-092-079-168-007.static.arcor-ip.net) |
| 09:07.44 | ao2 | mickey|office, kernel modules should be there now: http://people.openezx.org/ao2/kernel_images/latest/ |
| 09:07.58 | mickey|office | ao2: ok, thanks. will grab them from there |
| 09:16.23 | mickey|office | ao2: can i help for adding the LED support? |
| 09:16.39 | mickey|office | the e2 is supposed to have at least two LEDs, but they're not appearing |
| 09:17.34 | ao2 | mickey|office, we have to find out how they are wired: pcap, regulator, gpio? |
| 09:17.48 | mickey|office | ao2: ok... i have not the slightest idea ;) |
| 09:17.49 | ao2 | maybe the easiest way to find out is to look at the motorola code |
| 09:18.16 | ao2 | if you tell me the code name of E2 I can look into that |
| 09:18.41 | ao2 | the code name should show up on the bootloader screen |
| 09:18.50 | mickey|office | Sumatra |
| 09:18.54 | ao2 | ok |
| 09:19.04 | mickey|office | (I don't have it with me in the office ;) |
| 09:19.09 | mickey|office | but i'm sure it's sumatra |
| 09:19.22 | ao2 | fine |
| 11:10.30 | *** join/#openezx lclaudio (~lclaudio@177.16.80.193) |
| 11:14.39 | CIA-18 | OpenEZX: 03Antonio Ospite <ospite@studenti.unina.it> 07master * raeef3f44a1 10moto-boot-usb/src/moto-boot-usb.c: |
| 11:14.39 | CIA-18 | OpenEZX: src/moto-boot-usb.c: don't issue query commands to gen-blob |
| 11:14.39 | CIA-18 | OpenEZX: gen-blob doesn't support RQHW for instance so don't call this and the |
| 11:14.39 | CIA-18 | OpenEZX: other query commands when we are talking to it. |
| 11:14.39 | CIA-18 | OpenEZX: Signed-off-by: Antonio Ospite <ospite@studenti.unina.it> |
| 12:00.08 | *** join/#openezx mickey|zzZZzz (~mickey@80.81.242.146) |
| 12:28.16 | ao2 | WyrM, about alignment issues, from what I understood aligning to _word_ size is not a requirement for memory access, memory is addressable byte per byte after all, about _struc_ alignment gcc can align structs to the size of the bigger type size of its members |
| 12:28.38 | ao2 | *biggest |
| 12:30.31 | ao2 | in our case the struct had an array of chars and 'short' len fields, so maybe the -Os in newer version of gcc were forcing alignments it to multiple of 2 = sizeof(short) |
| 12:31.26 | ao2 | and this caused problem because the buffer of chars were then castes to a buffer of uint32_t, hence changing the alignment requirement? Does this make any sense? |
| 12:31.44 | ao2 | s/castes/casted/ |
| 12:35.50 | *** join/#openezx mickey|office (~Mickey@business-092-079-168-007.static.arcor-ip.net) |
| 12:47.50 | CIA-18 | OpenEZX: 03Antonio Ospite <ospite@studenti.unina.it> 07master * r33d6abb6ae 10gen-blob/src/blob/bl_parser.c: |
| 12:47.50 | CIA-18 | OpenEZX: src/blob/bl_parser.c: force alignment for structs used in usb transfers |
| 12:47.50 | CIA-18 | OpenEZX: Without this change newer gcc versions won't guarantee those structs are |
| 12:47.50 | CIA-18 | OpenEZX: aligned to a 4 byte boundary, which is required for them to correctly |
| 12:47.50 | CIA-18 | OpenEZX: store the commands coming over USB. |
| 12:47.51 | CIA-18 | OpenEZX: Signed-off-by: Antonio Ospite <ospite@studenti.unina.it> |
| 12:49.26 | *** join/#openezx Varunb (~rey@122.162.53.1) |
| 13:10.58 | ao2 | mickey|office, pushing some ezx fixes to OE, I don't think I need to send them to openembedded-devel first, do I? |
| 13:11.54 | mickey|office | no, just go ahead |
| 15:45.46 | *** join/#openezx angelox_123 (~angelo@201-43-67-1.dsl.telesp.net.br) |
| 16:01.40 | *** join/#openezx pr0d1gy (~pr0d1gy@210.212.127.1) |
| 16:26.45 | *** join/#openezx varunb (~varun@122.162.53.15) |
| 16:35.44 | *** join/#openezx mickey|office (~Mickey@92.79.168.7) |
| 17:57.10 | *** join/#openezx pr0d1gy (~pr0d1gy@125.19.237.34) |
| 18:03.26 | *** join/#openezx florian (~fuchs@Maemo/community/contributor/florian) |
| 18:08.08 | WyrM | ao2: ARM's ldr instruction needs aligned addresses, so normally the compiler will insert padding bytes to put each struct fields on alignment boundary unless __packed is used. |
| 18:08.10 | WyrM | a cast from char[] to uint32_t should generate different asm code if the char[] is not aligned. |
| 18:08.53 | WyrM | This is the first time i see code that explicitly needs __aligned, i thought that aligned was default behaviour. :) |
| 18:09.00 | WyrM | see http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka3544.html |
| 18:09.45 | angelox_123 | Hi WyrM :) i didn't see you :) |
| 18:10.29 | WyrM | hey angelox_123. :) |
| 18:15.10 | *** join/#openezx pr0d1gy (pr0d1gy@219.64.191.25) |
| 18:46.08 | mickey|zzZZzz | ao2: http://git.openezx.org/motorola-2.4.git/blob/7864e39e663d32d2db9b956b74f300ddb73bfecf:/drivers/misc/pwm-led.c looks like the LEDs are connected to a regulator on E2 |
| 18:46.25 | mickey|zzZZzz | line178ff |
| 18:47.46 | mickey|zzZZzz | hmm, i'm not sure whether this is the LCD backlight or the actual LEDs |
| 18:49.32 | mickey|zzZZzz | all the keys are working, the e2 has a bunch of extra ones |
| 18:50.23 | ao2 | POWER_IC_REG_PCAP_PERIPH, looks like a pcap controlled led, should be easy to add, I'll send you a tentative patch after dinner |
| 18:50.48 | mickey|zzZZzz | awesome, thanks. at first glance, i spot three leds |
| 18:50.59 | mickey|zzZZzz | one on the left side, one on the right side, and the camera flash |
| 18:51.35 | mickey|zzZZzz | no idea whether the left side contains more that are only switched on/off simultaneously by the Ezx software |
| 18:51.59 | mickey|zzZZzz | bon appetit, btw. |
| 18:52.35 | angelox_123 | anyone know if the E1 are a ezx device too? |
| 18:52.44 | angelox_123 | s/are/is |
| 18:54.49 | *** join/#openezx angelo_ (~angelo@201-95-47-134.dsl.telesp.net.br) |
| 18:55.48 | angelo_ | sorry,my internet got down? someone answered my question ? :) |
| 18:56.11 | WyrM | angelo_: no |
| 18:56.25 | WyrM | (for both questions) ;) |
| 18:56.31 | angelo_ | :) thanks |
| 19:13.02 | *** join/#openezx pr0d1gy (~pr0d1gy@125.19.237.34) |
| 19:33.09 | *** join/#openezx angelo_ (~angelo@201-95-47-134.dsl.telesp.net.br) |
| 19:36.17 | ao2 | WyrM, reading that page I understand that alignment is required for _efficiency_, not required absolutely by the processor (read: produced code is slow but still correct), and in any case alignment is not always on word boundary (multiple of 4), it depends on the data type. The fact that the casting fails to produce the right code, well that could very well be a bug. Am I still missing anything? |
| 19:51.47 | WyrM | ao2: not just slower, generated asm code is different if you want to read from an unaligned address, the compiler should abstract this but it seems that it failed doing it. that makes me think its a compiler bug. |
| 19:51.49 | WyrM | If you have to explicitly use __aligned its because the generated code wasn't "unaligned safe". :) |
| 19:53.50 | WyrM | I dont get what you mean by depend on data type though... |
| 19:55.31 | WyrM | my understanding is that struct { short; int; } should take 8 bytes unless __packed is used, otherwise every access to "int" would be _very_ inefficient. |
| 20:04.15 | ao2 | maybe I am mixing some concepts, struct fields alignment and the address of the struct itself, the struct in question is "struct {char buf[5000]; short len;}" btw |
| 20:05.07 | ao2 | mickey|zzZZzz, pushed some fsogsmd stuff, looking at the leds changes now |
| 20:09.36 | WyrM | weird. |
| 20:10.08 | WyrM | 5000 is a multiple of 4, so using packed shouldn't make a difference. |
| 20:10.23 | WyrM | the address of a struct is the same as the address of the first field. :) |
| 20:10.45 | ao2 | I wonder if -Os is doing something here, forcing some packing |
| 20:12.09 | ao2 | anyways I haven't even tried to replicate the issue with a minimal example |
| 20:17.45 | WyrM | yeah, this really seems weird.. -Os should take the size of the code too, so saving 2 bytes on the struct would still generate a bigger file because of the increase in code size. |
| 20:18.27 | WyrM | ahh, s/short len/int len/ may also force the alignment on char buf[5000]. |
| 20:21.44 | ao2 | WyrM, you mean as a better fix than the __aligned attribute? |
| 20:25.13 | WyrM | fix would probably be the same, not better. :) |
| 20:25.45 | WyrM | you would save a instruction on each "len" access though, so code would probably be a bit smaller. |
| 20:33.10 | ao2 | mickey|zzZZzz, you could try a patch like this one http://pastebin.com/Yvu5136i and tell me if any leds is working with it. Already compiled here: http://people.openezx.org/ao2/tmp/zImage-e2-leds-test.bin |
| 20:36.16 | *** join/#openezx pixel____ (~root@p5B0E0617.dip0.t-ipconnect.de) |
| 20:41.14 | WyrM | brb. |
| 20:41.21 | *** part/#openezx WyrM (~WyrM@unaffiliated/wyrm) |
| 20:41.55 | *** join/#openezx WyrM (~WyrM@unaffiliated/wyrm) |
| 21:32.18 | *** join/#openezx purl (~purl@rikers.org) |
| 21:32.18 | *** topic/#openezx is OpenEZX Developer Lounge -- http://www.openezx.org -- identi.ca: http://identi.ca/openezx -- Facebook group: http://www.facebook.com/group.php?gid=291471230258 |
| 21:32.22 | *** join/#openezx bluelightning (~paul@86.5.60.184) |
| 21:32.22 | *** join/#openezx bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 23:35.22 | *** join/#openezx angelox_123 (~angelo@201-95-47-134.dsl.telesp.net.br) |