| aw_ | Does https://github.com/milkymist/bugs/issues/26 influence my current test works on rc3 boards now? ;-) | 02:24 |
|---|---|---|
| aw_ | or it doesn't matter? | 02:24 |
| kristianpaul | i think is a technical detail nor practical | 02:39 |
| aw_ | so happy to continue using my current test image, right? | 02:41 |
| aw_ | ;-) | 02:41 |
| aw_ | 0x33; so good that VGA DDC failed at test image firstly was a false alarm caused my VGA cable un-close together with vga connector on m1. means that my vga cable's pins not have good contacts connection(male), I could buy a new one next time. I hope rest failed about DDC failed with this the reason. ;-) | 03:39 |
| kristianpaul | you mean this vga-cable issue aply to several boards? | 03:40 |
| wolfspraul | kristianpaul: be patient :-) | 03:41 |
| kristianpaul | heh | 03:41 |
| kristianpaul | ok | 03:41 |
| kristianpaul | but sounds good, every problem seems to be solve replacing a cable ;-) | 03:41 |
| wolfspraul | testing is like this, you just don't know where the insight/root cause will pop up. can be all sorts of things. | 03:41 |
| kristianpaul | i can imagine | 03:41 |
| aw_ | the signals of SDA & SCL on failed board measured is good. | 03:42 |
| wolfspraul | it's not the first time that I've had a case where the pins of a cable broke | 03:42 |
| wolfspraul | connectors are designed for certain duty cycles | 03:42 |
| wolfspraul | but by definition in a test environment the connectors of the test equipment may be used far beyond the design of the connector | 03:42 |
| wolfspraul | so we just have to replace the test cables/connectors regularly, as part of keeping the test environment itself free from problems :-) | 03:43 |
| aw_ | so hope all rest r, g, b analog signals are also caused by this reason, I'll spot them soon. | 03:43 |
| wolfspraul | I've seen _TOTALLY_ worn out connectors on factory lines, regularly | 03:43 |
| wolfspraul | kristianpaul: some connectors are, by design, meant to survive only 10 insert/remove cycles :-) can you imagine? | 03:43 |
| wolfspraul | in their lifetime | 03:44 |
| aw_ | yup...i have to prepare maybe 2 ~ 3 pcs vga cable to switch them to keep be as good testing tools. | 03:44 |
| kristianpaul | 10?!!! | 03:44 |
| wolfspraul | others are designed for 1000, 5k, 10k, into the millions (but those are very special connectors then) | 03:44 |
| wolfspraul | when you just 'use' consumer goods, you tend to forget this | 03:44 |
| wolfspraul | you don't realize that it's all designed with some goals in mind, nothing lasts forever | 03:44 |
| wolfspraul | (in hardware) | 03:44 |
| wolfspraul | yes, 10 :-) | 03:44 |
| wolfspraul | for example certain FPC connectors | 03:45 |
| aw_ | but seems that having a extended vga cable with 1 meter female to male type I have to prepare. | 03:45 |
| wolfspraul | kristianpaul: but my point is, every connector is designed for a certain lifetime/connect cycles. keep in mind. it's not 'indefinite' | 03:45 |
| kristianpaul | yeah, i killed a usb cable last week.. was from my first nokia phone two years ago !! | 03:46 |
| wolfspraul | since it's mechanical and wears out, eventually something will break | 03:46 |
| wolfspraul | yup, there you go | 03:46 |
| wolfspraul | USB is mostly in the 'thousands' of connect cycles, I think | 03:47 |
| wolfspraul | 5K or so | 03:47 |
| wolfspraul | there may be something in the standard, and then individual connectors or cables may try to go a little higher or don't care and go lower | 03:47 |
| wolfspraul | it's a consumer connector so people will rarely go through 5k of connect cycles | 03:47 |
| wolfspraul | anyway | 03:48 |
| wolfspraul | let's see how Adam's findings continue :-) | 03:48 |
| kristianpaul | yes i'm in patient/read only mode now | 03:48 |
| wolfspraul | I do hope we quickly can increase the number of PASS boards. so far the results are tough. but what can we do, right? stay calm and keep working and thinking :-) | 03:49 |
| wolfspraul | we cannot blame any process, source, vendor, design choice, etc. until we can trace down real root causes | 03:50 |
| kristianpaul | May be is same cable used in rc1, rc2? wich end of life is rc3 :-) | 03:50 |
| Action: kristianpaul no more blames | 03:53 | |
| wolfspraul | kristianpaul: no it's good. let's call it 'finding root causes' | 03:56 |
| wolfspraul | testing is an amazing challenge, I really like it, even after all these years. it just plays with your mind. | 03:56 |
| wolfspraul | if you keep testing something that never finds a problem, you should stop that test, right? | 03:56 |
| wolfspraul | but at the same time you should not overlook anything unexpected, and be prepared for whatever unknown new problem may hit you, right? | 03:57 |
| wolfspraul | how are those 2 possible at the same time? | 03:57 |
| wolfspraul | so the ideal test is more like a miracle. the moment you realize it's needed, you immediately find the problem. :-) | 03:59 |
| wpwrak | wolfspraul: (10 insertions) totally unthinkable ! the openmoko debug cable never existed. it's all a dirty lie ;-) | 04:25 |
| roh | morning | 04:25 |
| roh | *yawn* .. yikes... monday. 1.8. new month. not even 6:30am | 04:26 |
| GitHub105 | [flickernoise] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/flickernoise/commit/575e5813ddbc4be3ba89e65e3c3a06543ceb1300 | 09:13 |
| GitHub105 | [flickernoise/master] YAFFS: flush task - Sebastien Bourdeauducq | 09:13 |
| GitHub140 | [rtems] sbourdeauducq pushed 8 new commits to master: https://github.com/milkymist/rtems/compare/48c2947...189c80a | 09:53 |
| GitHub140 | [rtems/master] 2011-07-31Joel Sherrill <joel.sherrilL@OARcorp.com> - joel | 09:53 |
| Last message repeated 2 time(s). | 09:54 | |
| GitHub171 | [rtems] sbourdeauducq pushed 1 new commit to mmstaging: https://github.com/milkymist/rtems/commit/2d6d1edd467a22bc40cadd686081d5f0d1138f36 | 10:31 |
| GitHub171 | [rtems/mmstaging] Merge branch 'master' into mmstaging - Sebastien Bourdeauducq | 10:31 |
| Alarm | is it possible to have your opinion on these errors? | 10:40 |
| Alarm | http://pastebin.com/z1QXVRFj | 10:40 |
| Alarm | the source file: | 10:42 |
| Alarm | http://pastebin.com/z1QXVRFj | 10:42 |
| Alarm | oups : The source file : http://pastebin.com/AiVJ3J5M | 10:44 |
| GitHub133 | [rtems] sbourdeauducq pushed 1 new commit to mmstaging: https://github.com/milkymist/rtems/commit/af64cbc07f4357bace63b79486525e14c722cd38 | 10:49 |
| GitHub133 | [rtems/mmstaging] Update ChangeLog - Sebastien Bourdeauducq | 10:49 |
| GitHub85 | [rtems] sbourdeauducq pushed 1 new commit to mmstaging: https://github.com/milkymist/rtems/commit/cce9e54216aa25710faeeb37fadbeb63ace44dbe | 10:50 |
| GitHub85 | [rtems/mmstaging] removed score from changelog - Sebastien Bourdeauducq | 10:50 |
| GitHub143 | [scripts] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/scripts/commit/3e09df1c556d362c2cb31e9c0a64d32a821eff4e | 11:36 |
| GitHub143 | [scripts/master] Match latest development software - Sebastien Bourdeauducq | 11:36 |
| Fallenou | Alarm: you should test the return value of open | 11:51 |
| Fallenou | Alarm: after modifying the framebuffer, you should swap the buffers I think | 11:58 |
| Fallenou | (using the ioctl FBIOSWAPBUFFERS) | 11:58 |
| Fallenou | well if you are in triple buffered mode | 11:58 |
| Fallenou | ok it seems you are in single buffered mode, so forget about swapping | 12:00 |
| Fallenou | Alarm: add a "volatile" to the declaration of the "pixels" variable maybe ? | 12:01 |
| Fallenou | Alarm: anyway cannot read the link containing errors ( http://pastebin.com/z1QXVRFj ) | 12:06 |
| Fallenou | it says "unknown paste ID" | 12:06 |
| Action: larsc just wrote his very first gcc optimization :) reduces the kernel image size by ~8k | 12:33 | |
| Alarm | Fallenou: http://pastebin.com/paRn4BpG | 12:36 |
| lekernel | larsc, if you send me gcc patches I can commit them | 12:39 |
| larsc | lekernel: ok | 12:43 |
| Fallenou | Alarm: RETEMS_INTERRUPT_LEVEL(0) | 12:43 |
| Fallenou | you have a typo there | 12:43 |
| Fallenou | line 43 | 12:44 |
| Fallenou | you missed 42 by 1 :) | 12:44 |
| larsc | i still don't get why gcc puts constants into the constant pool when optimization is enabled | 12:46 |
| Alarm | Fallenou: right! I had not seen. I understand the relationship between the typographical error and the error message. thank you very much | 12:59 |
| Fallenou | np you're welcome :) | 12:59 |
| lekernel | I wonder how Xst handles synthesizing recursive VHDL functions | 16:16 |
| lekernel | he, seems it's doing the right thing :) | 16:34 |
| mwalle | larsc: after sleeping about it. i think its still a gcc bug | 17:12 |
| mwalle | but not in our case, where its a macro | 17:12 |
| mwalle | but http://paste.debian.net/124773/ doesnt work either | 17:17 |
| larsc | mwalle: i though the same thing when i woke up this morning | 17:26 |
| mwalle | lol ;) | 17:27 |
| mwalle | DrJoel | I don't think so but worth popping on the list. It might be considered one.. I am betting it is just "don't do that" :-D | 17:46 |
| larsc | hm, it doing tail call optimization for lm32 has great potential. if i'm not mistaken we should always be able to translate 'call x; lw ra (sp+4); addi sp, sp, 4; ret;' to 'b x' | 17:48 |
| larsc | ok, we still need to load r and increment the stack register | 17:50 |
| larsc | but there are a lot of cases where ra was just pused onto the stack before the function call | 17:51 |
| larsc | about 1/5 of all kernel functions could make use of such an optimization | 18:09 |
| mwalle | larsc: load r? | 20:24 |
| larsc | mwalle: load r? | 20:29 |
| mwalle | larsc | ok, we still need to load r and increment the stack register | 20:30 |
| mwalle | load ra? | 20:30 |
| larsc | if it has been overwritten by a non tail call | 20:31 |
| lekernel | wolfspraul, more sourcing problems? http://en.qi-hardware.com/wiki/File:M1_rc3_0x37_u20s_mark_is_faked.png ...... | 20:33 |
| mwalle | larsc: could you give a more detailed example? :) | 20:43 |
| mwalle | ra should be pushed onto the stack within the function prologue if call or calli is used | 20:44 |
| larsc | and poped from the stack in the epilogue | 20:56 |
| larsc | which is what i meant by load | 20:56 |
| larsc | and ra only needs to be pushed on the stack if the function is not a leaf | 20:59 |
| larsc | furthermore we can optimize the code, so that ra doesn't need to be pushed on the stack if there is only one function call which is a tail call | 21:00 |
| larsc | at least as far as i can see there is no abi requirement that would prevent it | 21:10 |
| mwalle | larsc: what about backtracing? | 21:22 |
| mwalle | larsc: http://gcc.gnu.org/ml/gcc/2011-08/msg00026.html | 21:47 |
| larsc | hm, right the function would disapear from the call graph, if backtraced | 21:55 |
| larsc | i've been scanning through the kernel objcode looking for stupid constructs. and i've been wondering if we should add our own atomic operations | 22:02 |
| larsc | currenlty atomic_dec evaluates to upper while the lower would be a more efficient solution http://pastebin.com/Mp1HRCWF | 22:03 |
| mwalle | larsc: one could do wcsr IE, r0 instead of the andi r3, r4, 0xfffe; wcsr IE, r3 | 22:11 |
| larsc | yes. the end and is only there because of the good old times ;) | 22:13 |
| larsc | interesting but unimportant fact: there is exaclty one xnor instruction in the whole kernel | 22:23 |
| larsc | the optimized atomic operations reduce the size by about 24k | 22:28 |
| mwalle | larsc: could you review the patch i sent to the mm mailinglist? | 23:10 |
| mwalle | im going to bed now ;) | 23:11 |
| larsc | hm, i'm not sure whether it is correct | 23:14 |
| larsc | but i guess it is | 23:16 |
| Hodapp | I am surprised I haven't stumbled upon this project yet, but it looks quite interesting and well-developed. | 23:59 |
| --- Tue Aug 2 2011 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!
