<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
<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
<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
<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.