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