wpwrak | that way, i can make several boards, can also make partial boards for testing some subsystem (e.g., the board i made for anelok that has wheel and OLED but no MCU) | 13:42 |
---|
ysionneau | the bios modification I made is only for testing purpose, so you may wonder why I made some weird changes :) (like in the exception vectors) | 17:46 |
---|
lekernel | the python coding style is usually inclined towards trying doing things and then catching exceptions, instead of testing if the operation will work | 21:06 |
---|
wpwrak | do creotech also do the SMT ? or are they just taking care of testing and maybe logistics ? | 18:49 |
---|
wpwrak | it's pretty nice that you can outsource the production testing, even for prototypes. should make things a lot easier | 13:39 |
---|---|---|
wpwrak | i also have an nVidia, but i think it was the ATI i used for testing. the NV would be: NVIDIA Corporation G72 [GeForce 7200 GS / 7300 SE] (rev a1) | 19:09 |
lekernel | creotech have started testing their mixxeo boards :) | 20:34 |
---|
lekernel | what are the obstacles to testing it on the lx9? | 12:15 |
---|
sb0 | don't worry your board is on the way... they're at creotech atm and should go through testing soon (if not done already) | 19:52 |
---|
davidc__ | lekernel: I haven't tested milkymist-ng; the code I'm testing it on is a 2k LOC project at the moment. I of course would before I sent in patches (its not ready yet anyhow) | 14:43 |
---|
larsc | I'm mostly testing with qemu | 08:56 |
---|
davidc__ | lekernel: BTW - I've written a simulation TopBlock for multiple clock domain/async testing [do_simulation/migen_tick tied to only one]. Any interest in a patch? | 18:27 |
---|
Fallenou | and then they attribute "lower" speed grades to the one not capable of reaching that goal after testing | 11:56 |
---|
sb0 | "Testing a FIFO design for subtle design problems is nearly impossible to do. [...] Clearly the answer is to recognize that there are potential FIFO design problems and to do the design correctly from the start." | 09:36 |
---|
wpwrak | how is stability ? have you done any long-running torture-testing yet ? | 17:31 |
---|---|---|
lekernel | not as much testing as the old controller... actually I want to at least try 1080p as a test before sending the bug-ridden HDMI data to DRAM | 17:32 |
lekernel | have you done some testing on that? | 21:21 |
---|
azonenberg | the smaller ones are for one-off prototyping and libjtaghal regression testing | 16:47 |
---|
Fallenou | for simple unit testing it could be great | 21:36 |
---|
azonenberg | Are you guys doing unit testing now? if so, how? | 07:28 |
---|
GitHub28 | milkymist-ng/master 0c29775 Sebastien Bourdeauducq: tb/asmicon/asmicon_wb: more complete testing by default | 17:09 |
---|
Grievre | I can see the advantage to that but it seems like it would make testing difficult | 15:40 |
---|
wolfspraul | so I can read and write both textual and binary bitstreams, but the reading of binary bitstreams is only for the purpose of roundtrip testing in the autotester | 08:23 |
---|
Fallenou | wpwrak: that would deserve testing! | 19:43 |
---|
wolfspra1l | I can supply you with cheap slx9 testing boards if we make it there in the next weeks hopefully, at cost | 12:34 |
---|
Fallenou | It surely need more testing | 12:08 |
---|
lekernel | testing the code now... | 11:49 |
---|
azonenberg | I've pretty much finished testing and there are no known bugs in the board at this time | 01:29 |
---|
lekernel | xiangfu: let me know how the testing goes. if it works, i'll commit Jia's patch into gcc. | 08:15 |
---|---|---|
lekernel | but (a) this needs testing against regressions (small mistakes can easily slip through in such code) (b) the preferred way for customized SoCs is to use -ng | 14:21 |
kristianpaul | testing yes | 14:21 |
GitHub167 | [milkymist-ng/master] framebuffer: fake DMA for testing (WIP) - Sebastien Bourdeauducq | 19:49 |
---|
wolfspraul | I can probably get this made in 2 days, in horrible sloppy quality then I can learn about testing and fixing pcbs :-) | 00:55 |
---|
azonenberg | its an 8 bit data bus and i'm testing with 0x00FF00FF since thats worst case crosstalk from DQ* to other signals and worst-case SSO | 15:21 |
---|
um4_ | Hi guys. First sorry, this is my last stupid question. The Milkymist one has arrived. All works fine but when I run a patch I donĀ“t know how to return to the control panel& except pushing L-R buttons at the time. One hour testing and nothing... :| | 12:43 |
---|
lekernel | but sure, strict testing can be good... but expensive | 09:59 |
---|
lekernel | I'll create a mmu branch and do it for you... will be the occasion for some testing/review | 08:45 |
---|
Fallenou | I more than welcome comments on the verilog or C code (even if C code is just there for testing purposes, to validate the hardware/gateware part) | 16:48 |
---|
wpwrak | (2014) do you think it'll be reliably usable and with a full feature set (i.e., MMU) sooner ? especially testing and optimizing may take a bit | 06:54 |
---|
lekernel | wolfspraul: I don't think the M1 features are all about overpromising. first we did test every single of them at the hardware (pcb) level - that's what the m1testing program (remember it...?) that I wrote is for... | 09:47 |
---|---|---|
Fallenou | fyi, I am still commited to keep working on the mmu, it's making small progresses every week, I am planning on testing if the exception handling is reliable. I just have very little time, but I have not stopped at all :) | 12:29 |
wpwrak | cladamw: naw, that wouldn't make sense. i think it will take a while before we have more extensive testing on m1rc3. | 02:33 |
---|---|---|
wpwrak | (dead) well, another niche development. small developer base, limited testing, etc. | 16:15 |
wpwrak | probably doesn't get much testing | 17:10 |
Fallenou | dtlb exception handling needs testing | 21:03 |
---|
Fallenou | I will do more intensive testing soon | 12:09 |
---|
wolfspraul | adam wang (nick cladamw) in taipei, who is doing the production and testing of boards and products | 00:40 |
---|
wolfspraul | with our minuscule engineering resources even the tape-out, testing and communication process with a foundry could get us stuck for 10 years :-) | 00:47 |
---|
Hodapp | the man who made the board purposely made it hackable and broke out all of the relevant pins right underneath the battery and told them it was for testing purposes (which it sort of was) | 13:24 |
---|
wpwrak | Fallenou: the effect i'd expect would be more along the lines of main development focusing on the latest hardware but things still being able to build for older hardware. and occasionally, e.g., for releases, there would be systematic testing of the builds for older hardware | 12:28 |
---|---|---|
Fallenou | instead of testing in the code right where you need to toggle a GPIO, in order to check for hardware version | 12:35 |
wolfspraul | all nice theories, but to pull it off in reality is a lot of infrastructure, testing, risk, etc. | 12:39 |
wpwrak | wolfspraul: i think it's indeed mainly an infrastructure issue. we need more 100% automated tests. that way, the testing burden largely vanishes. | 12:41 |
Action: xiangfu is testing #2026 now | 14:30 |
wpwrak | lekernel: that's probably fine. would need testing, though. if i remember correctly, it's about 6.5 bit times | 12:35 |
---|
wpwrak | mwalle: i mean that one could wait either for data, error, or timeout. that should cover roughly the same cases. but ... would need some testing. so that's an idea for the future great USB low-level test :) | 22:29 |
---|
jonand | It really depends on how bad it looks in reality. Did you run the EMI tests with ethernet traffic or are the ethernet + usb ports considered as "service ports" (that do not need testing because they are not connected during normal operation)? | 07:39 |
---|
wolfspraul | together with sourcing, mechanical, production testing, analog circuits, ... :-) | 00:23 |
---|
Action: lekernel scratches is head about the best testing strategy for this little mess | 21:25 |
wolfspraul | and yes I totally agree, it depends on R4 regression testing as well | 01:18 |
---|
roh | i think currently we just chose digikey to get good quality without thinking/testing ourselves, right? | 00:12 |
---|---|---|
wolfspraul | roh: we are testing the entire assembled pcb, quite good nowadays | 00:13 |
roh | no need to change it now. we can mod a cable for testing and nobody would use it as in because it would block the out besides testing | 23:43 |
---|
wpwrak | 3) is more difficult to answer. needs more testing. | 13:00 |
---|---|---|
wpwrak | sw lagging also causes holes in hw design testing | 13:45 |
wolfspraul | assembly and testing at Adam's home factory ;-) | 04:41 |
---|
wolfspraul | currently sampling from several vendors, testing, comparing, etc. | 02:44 |
---|---|---|
wolfspraul | so we sourced accessories 80-85-90, depending on how likely we thought that some would fail our testing | 03:57 |
wpwrak | FREE beta testing :) | 07:16 |
wolfspraul | second run, 40 pc, about 31-33 were 100% good and sold, and the remaining ones were used up in various development/testing/design efforts | 12:50 |
lekernel | xiangfu: may I suggest I keep taking care of building/testing/uploading software images? (it allows me to do a few quality checks...) | 09:04 |
---|---|---|
wolfspraul | that includes testing with peripherals | 09:35 |
wolfspraul | but I think the more testing we do, and especially working on a better test plan, that's always a good thing. once we have figured this out, we should come out with meaningful updates every month, or at least bi-monthly. that's not necessarily something big, can be small things like new patches etc. | 09:36 |
wolfspraul | sure, first a good test plan, then fix the bugs that show up during testing | 09:37 |
lekernel | I take care of this testing. I like to be reassured :p | 09:40 |
wolfspraul | which includes testing with peripherals, walking through important use cases, etc. all of that documented and efficient (so we can repeat it for frequent updates) | 09:42 |
wolfspraul | those 2 things go together - testing & bug fixing | 09:49 |
Fallenou | there is a balance between tons of pointless procedures/integration test/unit testing etc and having no test procedure at all :) | 09:53 |
rejon | Oh testing would be helpful | 10:07 |
wolfspraul | rejon: yes, we are trying to share the testing work smarter among more people | 10:11 |
wpwrak | (automated testing) i have a bunch of regression tests for the compiler. 396 tests on last count, but that's a bit inflated because also each patch in the patch pool counts twice. but that's only the compiler, not all of FN. the audio/midi/etc. input -> rendering or -> gui flow would be much harder to test. | 12:21 |
wolfspraul | except for more testing, it's fully working? | 13:51 |
---|
xiangfu | testing.... | 08:27 |
---|---|---|
xiangfu | lekernel, rescue bitstream with VGA bug. no testing rescu bitstream now. | 10:14 |
wolfspraul | testing sounds good! | 06:46 |
---|
cozy | how would i go about writing a patch and testing it? | 01:03 |
---|---|---|
cozy | is there a provision for writing patches and testing them within the milkymist itself? | 01:03 |
Hodapp | Good enough to use, or just good enough for the sake of testing? | 14:09 |
Hodapp | speaker talked about how it was often a much more viable solution to build an entire environment inside QEMU, including full build toolchain, than to try to do all testing on real hardware (which in some cases was not even possible) or to try to do everything with cross-compiling | 14:16 |
Fallenou | I suspect the freeze I had yesterday while testing dtlbtest occured because I was trying to write at physical page 0 | 08:43 |
---|
dvdk | the ram.data is just for testing, i.e. whatever is in there is ok? | 21:49 |
---|---|---|
Fallenou | basically for now I'm just testing the DTLB | 21:52 |
Fallenou | for testing on fpga with dtlbtest I'm using massively asm() in main.c | 23:13 |
wpwrak | anyway, seems that we'll have to try our luck without dvi design testing | 02:38 |
---|---|---|
dvdk | wrt debugging the debug environment, I'm currently trying to port gforth-ec over to LM32 to use as a debug "operating system". Don't like to cross-compile&upload a hundred times just for testing a SoC components | 22:24 |
lekernel | and is this spec'd by the DRAM vendors, or do you have to do the testing and characterization yourself? | 12:39 |
---|
lekernel | by the way, why bother with the full BIOS if you're only testing a few MMU instructions? | 09:12 |
---|
cladamw | wpwrak, can you tell me your current If while you were testing that off-ledm for simulation of 'booted'? | 10:36 |
---|---|---|
wpwrak | (work items) and then testing, and rework, etc. so minimum 3 months. | 16:00 |
wolfspraul | what kind of testing is enough? turn them all one at once? | 01:15 |
---|---|---|
wpwrak | for automated testing, the current could be increased to 6 mA for one led (limited by the resistor). maybe an option :) | 01:22 |
wolfspraul | do a little boundary testing, then go through one by one to make sure the grid is good | 01:23 |
wolfspraul | you are right - watching current is the #1 thing after smt and in testing | 01:44 |
wpwrak | the thing is that we have zero automation on adam's side. so if anything comes up that needs a bit more sophisticated testing, he can't do it. or he has to spend a lot of time playing robot. | 01:55 |
wolfspraul | our testing is great, when we add the leds we just add one more simple test case and fine | 01:57 |
wolfspraul | yes, but please not - any automation of that kind of testing just adds more uneconomical things | 01:58 |
wolfspraul | testing is about economics, once you forget that you can stop testing right there | 02:10 |
wolfspraul | also I'd hate to invent test case on my own genius thoughts. instead, we ask how others are testing in mass-production (in Taipei), and then we know what makes sense | 02:14 |
wolfspraul | if yield is bad, you have 2 options first: be smarter on testing and process *or* make more | 02:17 |
wolfspraul | you are trying to tell Adam (or me) what causes work in testing, but Adam is doing the work. he can tell you. | 02:21 |
wolfspraul | we improved testing a lot in rc3, for Adam, and it was mostly very small things that helped him a lot. | 02:21 |
wolfspraul | and I will continue exactly along those lines - fix the real problems he has, not invent new problems for him from excessive testing systems | 02:22 |
wolfspraul | everything else is crazy, we can improve testing forever | 02:23 |
wpwrak | in other words, you think led testing is completely superfluous. now we're getting somewhere ;-) | 02:24 |
wolfspraul | I've done and overseen a lot of testing on the line | 02:26 |
wolfspraul | we may not need that testing in the run | 02:29 |
wolfspraul | it's design testing | 02:29 |
wpwrak | no no, it's production testing ;-) | 02:29 |
wpwrak | design testing would be worrying about the difference whether i see 6.3 mA or 6.1 mA, and why. the production testing would be whether i see 0, 3, 6, or 12 mA :) | 02:31 |
xiangfu | yes. just finish modify the script makefile. testing now :) | 05:19 |
wolfspraul | I indeed had some more led testing dreams/nightmares, but luckily forgot them | 09:21 |
wolfspraul | they regularly break, nobody is testing them, etc. | 10:44 |
---|---|---|
wpwrak | lekernel_: still a bit excessive for the LED testing ... | 16:12 |
wolfspraul | wpwrak: wow, nice led testing! | 09:24 |
---|---|---|
wpwrak | wolfspraul: (led testing) leds make for pretty pictures :) | 13:14 |
wolfspraul | then testing, bugfixing, moving hotkeys so they are easy and make sense on the chosen kbd, ship to Taipei, include in box | 01:46 |
---|
wolfspraul | I think it also depends on Werner's testing | 09:09 |
---|---|---|
wolfspraul | remember that Werner is testing already | 09:10 |
wpwrak | (led matrix testing) ah, lemme commit what i did yesterday ... | 11:13 |
lekernel | but they're not free. they have a cost in PCB routing effort, mech design, parts, testing and software development. | 17:16 |
wolfspraul | he is testing... | 15:50 |
---|---|---|
wolfspraul | but you are testing, I think we should follow with what you *see* | 15:55 |
wolfspra1l | updates need regression testing, and then 'downgrade' should be something that is rarely if ever needed | 11:32 |
---|---|---|
wpwrak | and there's of course no serious testing. so you'll run into regressions every now and then | 11:34 |
Artyom | ...use a big SDRAM-based FIFO. And this is the field where I would like to use MM SoC (memory controller + FIFO). This task seems to me similar to VGA output + TMU-module. There is board that can be used for testing FX2 + MM SoC ( http://www.ztex.de/usb-fpga-1/usb-fpga-1.11.e.html ). But there are no boards that use FX3 (USB super speed chip) + FPGA. As FX3 is a very new chip. There was also... | 18:30 |
wpwrak | hmm, for regression testing of the pfpu itself, it would be nice to be able to run it on a PC. but i guess that's not so easy. (if we want accurate behaviour, e.g., a precise replica of rounding errors) | 11:44 |
---|
wpwrak | regarding HID, I was planning to do that report parsing myself. i have a big bag full of mice waiting for testing all that :) | 06:38 |
---|
wolfspraul | I can easily imagine that that may overtake a competitor who focuses on the samples/chips first, and then figures out process and testing/qa | 00:05 |
---|---|---|
wolfspraul | I think testing is the key, quality testing. that's where time is sunk. | 00:06 |
wolfspraul | process and testing/verification | 00:07 |
wpwrak | testing is a little weak on our end | 00:08 |
wpwrak | naw, feature/regression testing. also including software | 00:10 |
wpwrak | temperature testing ... hmm. i could leave the air conditioning off. than my M1 would be roasted at ~40 C. that could get interesting ;-) | 00:11 |
wolfspraul | we can learn something in stress testing there :-) | 09:17 |
wpwrak | let them do the testing ;-) | 23:57 |
---|---|---|
wolfspraul | we can get process, tools, testing and so on in shape on our end | 23:57 |
wolfspraul | I wouldn't say that, but we haven't done extensive testing on rc2 | 01:55 |
---|
wpwrak | i.e., that the idea is to better automate sourcing with boom. boom is aligned with kicad. plus, it would be kinda inconvenient if i couldn't generate "real" boms for testing :) | 22:43 |
---|
pablojavier | i can live without a PC today, but not without testing this marvel | 13:54 |
---|---|---|
pablojavier | just kidding. Going to do some more testing, see you later! | 14:39 |
cladamw | wpwrak, one thing I forgot to ask. When you were doing reliable testing on nor corruption, were you always using usb high speed mode to access ? | 04:11 |
---|---|---|
wolfspraul | 1 day testing for Adam, done | 10:11 |
wolfspraul | thanks a lot for helping with this and testing and all! that is really great | 11:02 |
---|
cladamw | oah ~yes. since I was testing a new rc3 board, just found. :) Thanks told me this. ;-) | 10:13 |
---|
wpwrak | wolfspraul: it could still be useful for testing certain model properties | 13:44 |
---|---|---|
wpwrak | today, the main risk are programs with buggy code paths that aren't visited in testing. of course, there are tools for avoiding that as well ... | 15:49 |
wpwrak | wolfspraul: one more day of testing will add an extra safety margin of a factor of about 1000 | 15:41 |
---|
cladamw | alright...good luck...Measuring two VBUSs connections from AP4142A's pin7(OUT1 = usb -A port) and pin6(OUT2 = usb - B port) _before_ testing usb stuff. :-) | 13:06 |
---|---|---|
wpwrak | i love it when machines do this sort of mind-numbing testing for me ;-) | 21:24 |
wpwrak | yup. of labsw. i'm torture-testing the M1's NOR behaviour | 21:58 |
krispaul | wpwrak: are you going up to resnder or just testing powercycle so far? | 23:09 |
cladamw | xiangfu, for those packed rc3, i can just directly update it without crc testing. Since I can surely those m1 h/w worked pass already. For remaining new boards without f/w, i can temporarily skip phy id/midi/crc tests. No problems. :-) | 05:21 |
---|
barbu-uucp | we can replace it with either a sinus LUT - to take care of Adam's ears during testing - or a more rash square/sawtooth wave | 21:00 |
---|
wolfspraul | but how about builds? how about testing? how do people find out which build/image/binary they need? can we auto-detect? etc. | 03:13 |
---|---|---|
wolfspraul | how big is the testing risk? i.e. if the person doing build testing only has the latest hw revision, can he assume the differences to older hw revisions are small enough to avoid having to do separate testing on the older hw? | 03:16 |
azonenberg | Well, in any case once exams are over i will be testing on the real chip | 09:43 |
wpwrak | wolfspraul: what's the plan for video codec testing ? will the supposed signal quality improvements be verified ? or do we just take them for given if no overly visible regression shows up ? | 12:28 |
---|---|---|
lekernel_ | that's the point of doing regression testing... | 12:37 |
wolfspraul | one day we need to do proper temperature testing | 13:01 |
wpwrak | stekern: you mentioned you had a fancy usb protocol analyzer at work. maybe that could be handy :) would you also happen to have any USB device that uses an USB-capable AVR ? if yes, that may exhibit the same issue and thus be useful for testing | 06:19 |
---|
wpwrak | just doing a bit of cleanup, more testing, and integration | 00:03 |
---|---|---|
wolfspraul | just to establish a testing baseline | 04:42 |
lekernel | wpwrak: why do you need to test rx_active before testing rx_pending? | 16:26 |
---|---|---|
lekernel | but it keeps testing for rx_active while waiting for the next byte, no? | 16:34 |
wpwrak | lekernel: (race) the problem is that you're testing in the same loop for rx_pending to rise and rx_active to drop, expecting to catch them in sequence | 16:42 |
lekernel_ | wpwrak: with the sample point change. I'm testing without the change now ... | 11:36 |
---|
sb0 | http://packages.debian.org/search?keywords=gcc-avr&searchon=names&suite=testing§ion=all | 19:14 |
---|---|---|
kristianpaul | ah,http://release.debian.org/migration/testing.pl?package=gcc-avr | 19:19 |
roh | the kit arrived yesterday... we completed it today. now its up to testing and calibration | 03:30 |
---|
wolfspraul | I did a lot of keyboard testing | 01:33 |
---|---|---|
wolfspraul | wpwrak: after my testing, I am sure we have several bugs, not just one. But good we are unraveling it now. | 01:38 |
wolfspraul | well, I think we were subconsciously clear that if we would do serious testing with lots of mice bought in the market, we would find some troublemakers | 01:49 |
wolfspraul | I was frustrated and worn out from keyboard testing at that time, so I was hoping writing this there would somehow be a good defense. didn't work. | 14:43 |
wolfspraul | I never did serious mice testing either, that also didn't help | 14:44 |
xiangfu_ | wpwrak, I have two combine keyboard and mouse devices. both only keyboard working. will testing your new usb code when the buildhost finish the build | 15:59 |
lekernel | well... I just mean applying the changes to that branch as well and do some testing | 21:33 |
---|
wpwrak | i think 4.0 V is a safe change from my 4.4 V. so i don't think i need to try this first myself. i can always do torture testing later. | 02:23 |
---|---|---|
wolfspraul | if we are able to execute this, everybody should have the same reset circuit in mind, and we double-check it sufficiently in terms of rework and testing | 02:27 |
wpwrak | lekernel: (head) none that i know of. but i haven't done very comprehensive testing yet. | 15:59 |
wpwrak | ah, so it's the resolution we talked about. why bug and not patch ? lack of time for testing ? | 22:58 |
---|
xiangfu | I am testing now. | 13:39 |
---|---|---|
xiangfu | testing try to reproduce the bug now. | 13:39 |
wpwrak | ah well, at least we know it wasn't that. sebastien should be happy hat we're leaving some bugs for him to chase :) thanks for testing ! | 13:50 |
wolfspraul | where he makes the pcb, where he makes the smt/dip, testing, etc. | 02:21 |
---|
wolfspraul | of course let's do more testing now, let it run for 24hours, then wait a day, then again for a few hours, etc. | 08:25 |
---|
wolfspraul | should we dismiss that now that we have done this extensive testing and found everything to be stable? | 01:43 |
---|---|---|
lekernel | wpwrak, very cool :) thanks for all this testing! | 07:32 |
wpwrak | lekernel: thanks ! still a bit more testing to do :) but i'm starting to feel good about all this | 10:21 |
wpwrak | i think my board is fine. my concern with the rest chip is more that we're testing a rail that may be easily upset | 13:08 |
wpwrak | testing the "stable" rails would thus make more sense. but ... we need to test several of them, or it won't work | 13:10 |
wpwrak | wolfspraul: what do you think of selling boards that fail testing ? you could even make an auction. announce which boards will be available a few days in advance, so people have time to read the test reports, and maybe get advice on what the problems really mean. | 01:02 |
---|---|---|
wolfspraul | because we have no volume forecast, no price testing | 10:26 |
wolfspraul | since we can share the pcb & smt & testing costs with the product run | 07:56 |
---|---|---|
wolfspraul | we need to do real price testing, not just think "oh, maybe low cost will help" | 14:49 |
wolfspraul | this came up when we had this idea of a camera to point at an m1 board in testing to find hot spots | 14:05 |
---|---|---|
wolfspraul | it was for testing | 14:07 |
lekernel | there is the production testing software, yes | 13:30 |
---|---|---|
lekernel | http://milkymist.org/mmone/m1_testing_procedure.pdf | 13:34 |
wolfspraul | testing is also complicated | 02:38 |
---|---|---|
wolfspraul | well, we still have no proper release and testing process at all, even for 1 bitstream. so you could argue testing cannot get worse. | 02:38 |
lekernel | testing the triode I got from http://lekernel.net/blog/2011/09/prywatna-wytwornia-lamp-where-diy-meets-vacuum-electron-devices/ :) | 16:09 |
---|---|---|
lekernel | http://lekernel.net/blog/2011/10/testing-the-diy-triode-from-pwl/ | 19:12 |
wolfspraul | aw: should be, but let's wait for xiangfu's feedback. I think he is testing right now :-) | 02:19 |
---|
wolfspraul | wpwrak: hard to say. as always the main cost was in the pcb/smt/testing overhead | 22:29 |
---|
wpwrak | well, it seems some just need testing | 01:31 |
---|
aw | 70pcs here includes 25pcs "Packed - For Sale" and those ones sent out. With Werner's auto testing idea to verify if those two pull high resistors can suffer from exponential distribution and temperature-oriented later. :-) | 06:20 |
---|---|---|
wolfspraul | I am not worried about the units we are testing, packing and shipping now | 06:24 |
wpwrak | but before trying such a rework, i want to bring the testing process more under control. it still runs away too often for my taste. more control means accelerating it to reduce the risk of getting outliers that take a week of hammering before they show up, and also controlling the temperature | 13:23 |
---|---|---|
wpwrak | i think the torture-testing is easier on my side, because i can automate it | 14:01 |
sb0 | I'll also have a round of measurements/characterization/testing to do on the TDC core when I'm back, so the lag bug will have to wait a bit | 23:34 |
---|
wpwrak | the problem with this testing approach is that you drive the bugs into a corners your tests don't reach | 05:32 |
---|---|---|
wolfspraul | maybe but everybody is testing | 05:33 |
wpwrak | (everybody is testing) with tests designed for broad coverage you have a reasonable chance. but i don't think the current process is very strong there. i'm not saying that it's bad but that the tests are fairly narrow and probably high-level, too. e.g., some glitches may even get auto-corrected without you noticing. | 05:37 |
wpwrak | my plan is, once the new scheduler is done, to update the labsw design, make another prototype, and if it behaves well, also make one for adam. then he can do his testing in his sleep, much like i do ;-) | 05:46 |
lekernel | thanks for testing | 10:29 |
wolfspraul | Adam keeps fixing & testing | 03:26 |
---|
wolfspraul | how about reworking one board to the gates+4.4v reset ic solution we plan for rc4, and testing against that as well? | 05:29 |
---|---|---|
wolfspraul | it sounds like you have a really good setup for testing now | 05:30 |
wpwrak | ah, how many times did adam typically cycle those rc3 boards when testing ? | 05:42 |
wpwrak | one or two more and i can do some meaningful testing again | 17:48 |
---|
wpwrak | at the moment, i'm testing with the scope removed (so DC IN isn't grounded). but that doesn't seem to have an effect. still need a few hundred more cycles, though. | 14:30 |
---|
wpwrak | (that is, if the problem strikes during this testing) | 11:47 |
---|
aw | wpwrak, when got NOR corruptions, most that I was testing "rendering test", i.e., repeatedly following steps: | 06:02 |
---|---|---|
lekernel | I remember testing it though... | 09:02 |
roh | good question. i think i asked myself that (how to manage the matching) and then ignored it since i did diameter testing before shipping the glued buttons (nothing should be stuck or so) and was sure i sent all/enough fitting ones | 15:10 |
---|---|---|
wpwrak | for remote-controlling the M1 (for testing) | 18:06 |
wpwrak | this wouldn't affect the out-of-the-box experience because adam would have already sat through that initial compilation when testing | 16:14 |
---|
wolfspraul | Adam finished all testing successfully, a total of 500 render cycles on 32 boards (2*100 plus 30*10) | 07:57 |
---|
lekernel | how is the "lockflash" testing going? | 12:02 |
---|---|---|
aw | according to current plan: keep testing 30 pcs done then assembly. ;-) | 12:07 |
wolfspraul | for testing audio function again - sure if you like you can do it. | 06:48 |
---|---|---|
wpwrak | wolfspraul: i consider it good news that no previously "available" boards joined the "cluster" of unreliable booting in the fix2b testing | 12:20 |
wpwrak | wolfspraul: (NOR corruption) of course, if you want to be sure no such unreliability exists, then you have to delay until more testing is done. i.e., we don't know yet when exactly the thing happens, what causes it, what the pattern of affected addresses is, and how we can make it stop for good. | 12:22 |
wpwrak | kristianpaul: oh, but it is like this. more boards, deeper testing, new users. this inevitably brings out more bugs. | 00:45 |
---|---|---|
wolfspraul | yes, will try. I have dodged testing web update because I'm pretty sure I will find a problem :-) | 22:58 |
kristianpaul | also acording to changelog mmap was for adding the feature of testing specific physical regions of memory | 04:13 |
---|---|---|
wolfspraul | why don't we just erase all trace of those two boards, 0x4C and 0x7D, from the production and testing plans, and sell the rest as if everything was always perfect? | 09:21 |
wolfspraul | we need your help in manual testing, because that's how we tested so far | 11:12 |
wpwrak | now, for testing what's really going on. i'd suggest to do the current power cycling test at least 1000 times and until the corruption has happened at least 10 times, i.e., whichever comes last. | 11:33 |
wpwrak | well, i think it's also seeing more intensive testing now. so it's normal that more critters come out. we turn more stones ;-) | 19:30 |
aw | xiangfu, i keep testing...just ping me if you have new one | 02:15 |
---|
aw | wpwrak, I'll try it but i'm testing other. ;-) | 07:03 |
---|---|---|
wolfspraul | I was hopeful that the other boards were contained at some earlier state of testing, but I guess you were right all along. | 11:27 |
wolfspraul | actually in all the crazy reworks and testing, the yield is getting quite good, he he. not that there is much to laugh about in this run. | 11:32 |
wolfspraul | test! that's a good approach. we need to do some comparative testing to find early warning signs. | 11:37 |
wpwrak | if adam continues with the testing, we may also find more boards for the cluster. the more, the merrier as far as analysis is concerned :) | 11:43 |
wolfspraul | that neglects the dynamics of the production and testing process of course. in reality fix2b helped us to reduce the number of boards that failed after x rendering cycles a lot. | 12:00 |
wpwrak | lekernel: have you ever used jtag for a boundary scan ? that would allow a more systematic examination of things than the current functional testing | 13:50 |
wolfspraul | after we have 30 boards that are 100% pass with fix2b applied, you pause that fixind and testing work, and spend a day or two to assemble (case) and package 30 full retail units of M1 | 01:35 |
---|---|---|
wolfspraul | so I think you can mix in some interesting or failure boards, if only to see that our fix2b and testing process is now strong and can always identify well between pass and failure. | 01:45 |
wolfspraul | then continue with fixing and testing | 01:46 |
wolfspraul | 1. you continue exactly as you did last week. fixing and testing, analyzing some failure boards. | 01:48 |
wolfspraul | I just want to prepare Adam that there will be an interruption at some point, which is when we have ca. 30 fix2b 100% pass boards, and we are confident in our design, fix2b, and testing process. | 01:49 |
wolfspraul | then there's an assembly and packaging interruption, then back to fix2b/testing/fixing for all 90 boards | 01:49 |
wpwrak | aw_: yes, sounds good. thanks for all the testing ! we made some good progress into understanding the behaviour of that critter :) | 08:52 |
wpwrak | in any case, with fix2b and the testing, M1rc3 made a lot of progress. i think that fixed 75% or 80% of the "cluster", didn't it ? | 07:49 |
---|
aw_ | i continue testing the rest... stay tuned. ;-) | 12:20 |
---|
wolfspraul | and that is enough to disrupt the normal testing of the run | 02:30 |
---|---|---|
wolfspraul | I just need to stabilize the bloody rc3 run, get reliable 100% pass testing results, and start to ship those monsters out :-) | 02:40 |
wpwrak | yeah, end user testing is missing, too :) | 11:49 |
wolfspraul | I already want to do 1h render testing on each board :-) | 11:50 |
wolfspraul | or whereever the run is. the testing needs to be fast and efficient and in one place. | 12:07 |
wolfspraul | if you look at the 0x3C testing notes, this is after fix2b applied | 12:21 |
wpwrak | it seems that the diodes are unreliable. with fix2b alone, we're removing about 50% of the unreliability :) and with the extra testing adam does as part of fix2b, most of the rest as well | 14:39 |
wpwrak | but if we find something "interesting" in 0x3a/0x55, it may make sense to include it in the post-fix2b testing, to save time. | 15:36 |
aw_ | wpwrak, so how's best and quick way that i can know if usb-jtag board is bad while testing m1? | 09:55 |
---|---|---|
lekernel | it received more testing than urjtag and the usb-jtag board | 12:19 |
wolfspraul | it affects > 20 % of boards, at least. maybe with tougher testing even more. We don't know. | 02:13 |
---|---|---|
wpwrak | or maybe just leave it out for testing. afaik, the FPGA shouldn't need it | 05:28 |
wolfspraul | well, we have to wait for more thoughts from Werner or Sebastien. I suggest you continue with regular testing and fixing across the batch. | 06:30 |
wolfspraul | I suggest you continue with regular testing and fixing now | 06:38 |
wolfspraul | I suggest you go back to the regular testing and fixing | 06:38 |
wolfspraul | but now back to regular testing... | 06:52 |
wolfspraul | because we think about a lot of boards and even more testing data. there may be multiple bugs, or different problems on different boards. | 08:50 |
wolfspraul | but my main concern is to finally have a known-good design and test I can 100% trust, so that the board won't fail a few tests after I stopped testing | 12:43 |
wolfspraul | that wasn't part of the testing before, and doesn't imitate user behavior either | 13:30 |
wolfspraul | for testing, if he can make it to the render cycles, he should do 10 full render cycles, but without crc checks in between (maybe one at the end is not bad) | 13:44 |
wolfspraul | aw_: you are testing 0x39 now, if 100% is fine and pass, it goes to 'available' state | 13:54 |
wolfspraul | I think if extensive testing shows that everything is stable, at least for myself I don't need the 4.4V reset ic rework only because that makes the circuit better conform to the datasheet voltages. | 14:01 |
wolfspraul | since our testing did not show problems | 14:03 |
wolfspraul | testing results win here, imho | 14:03 |
wpwrak | wolfspraul: opportunistic testing :) | 08:45 |
---|---|---|
wolfspraul | aw: above you said 0x7C is available (testing finished) | 08:49 |
aw | okay...and keep testing another board first | 09:02 |
wolfspraul | wpwrak: be warned (well, I warn myself). I believe this kind of testing may damage the nor chip or more, and turn a board unflashable for days or forever. :-) | 09:25 |
wolfspraul | the bad thing is that we currently do 10 render cycles (30 seconds each) in our testing | 09:52 |
wolfspraul | for the cycle testing adam is doing on 0x7A now, I propose we stop that at 100 successful cycles | 09:59 |
wolfspraul | that's because we already have several improvements now (short cable, full-speed, crc checks in test software which is logged), and then we have more testing data to look at and thing about | 10:00 |
wolfspraul | that's 30 minutes testing for each board, easily | 10:03 |
aw | 2. CRC is okay while testing | 11:49 |
wolfspraul | the sample set was smaller (run of 40 instead of 90), and there was a lot less testing in rc2 than rc3, but I am pretty sure this same 'kind' of bug already existed in rc2 | 14:03 |
wpwrak | part temp. starts at room temp. :) the you do a bit of testing, it fails, keeps on failing, you give up, put it away, and then it works, until ... | 14:20 |
Action: Fallenou is testing with their cvs head | 17:20 |
wolfspraul | my feeling from looking at testing results is that (if it's 1 problem only), the root cause is not a simple flash write somewhere | 12:45 |
---|---|---|
wolfspraul | because whatever we do, Adam will have to do some testing of this and that variant. and if parts are missing we will quickly have another 'couple days' waiting time in between... | 13:00 |
wolfspraul | I will dwell over the testing results a bit more... | 13:11 |
kristianpaul | lekernel: as seems you have lot experience with testing the opencores stuff, what about this one http://opencores.org/project,ethmac ? | 15:39 |
wpwrak | maybe testing will be faster with the CRC check running on the M1. e.g., like adam's test sw does | 03:13 |
---|---|---|
wolfspraul | Adam will need at least another day or two for more testing and fixing. and in parallel we improve the test tools, erasing, crc checks, etc. | 05:40 |
wpwrak | in the calibration or once you start systematic testing ? :) | 22:19 |
---|
kristianpaul | hum, but jtag serial cabled passed testing all okay it seems, so dunno if can be a jtag-serial board issue | 02:03 |
---|
wolfspraul | or Adam's testing VGA connector wearing out from all the connect cycles | 07:11 |
---|---|---|
wolfspraul | I just realized that we are not yet testing the expansion header :-) | 07:29 |
aw | xiangfu, is there possible that we can use test image to help on testing for records into flash rom for 10 times when I press middle btn to boot up and some where that gui can let me save after rendering 30 seconds? | 08:12 |
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 |
---|---|---|
aw_ | yup...i have to prepare maybe 2 ~ 3 pcs vga cable to switch them to keep be as good testing tools. | 03:44 |
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 | he has it written, testing now | 03:08 |
---|---|---|
wolfspraul | we are testing boards off of a manufacturing run | 03:12 |
wolfspraul | good luck with testing! :-) | 13:32 |
aw | just updated on wiki, alright; i am out now. will continue testing tomorrow, night. :) | 14:48 |
aw | well...i keep testing firstly ...no more chats now. ;-) | 06:37 |
---|---|---|
wpwrak | (testing) good luck ! may the yield be with you ! :) | 06:38 |
wolfspraul | hmm. I think focus on fully testing all boards first. | 10:32 |
aw | well..i keep testing | 10:32 |
wolfspraul | that's why you do testing | 10:40 |
wolfspraul | but it doesn't matter as long as our testing is rock solid | 10:42 |
wpwrak | aw, wolfspraul: (cable testing methodology) first, it would be good to do, say, 10 tests with the long cable and the original value. otherwise you don't even know what failure probability to look for. | 13:54 |
wolfspraul | also we need to keep in mind that the USB cable itself comes from a very respected vendor, has already undergone testing by that vendor, etc. | 14:30 |
wpwrak | kristianpaul: so i dragged the thing over and did my things. while playing around, i found that it also had some USB test software installed. turned out that we could have done all the fancy testing at our leisure with that scope, without having to rely on the other lab. | 15:07 |
wolfspraul | then a batch of impedance/power-on/reflash testing, then we see | 04:01 |
---|---|---|
lekernel | it's less annoying testing | 12:57 |
wolfspraul | which reminds me that I still haven't done any testing of the update feature as it is now, argh | 08:05 |
---|---|---|
wolfspraul | that we have a strong process on testing and qualifying update images | 08:12 |
wolfspraul | after he has applied fix2 to a bigger batch, he will proceed with impedance, boot and reflash testing | 08:27 |
wolfspraul | wpwrak: when the xray results are inconclusive, you will have your field day and the heat testing can start ;-) | 08:56 |
wolfspraul | all perfect, start testing :-) I'm very curious about the results of the first 5-10... | 09:37 |
---|---|---|
wolfspraul | wpwrak: in all factories I've seen, female percentage in assembly and testing is > 90%, but female percentage at the rework stations is < 10%. just empirical data... | 10:03 |
wolfspraul | Adam's problem is more his age, hands start to shake etc. in factories you rarely see anyone above 25 either in assembly/testing or rework. | 10:04 |
wolfspraul | aw: I am not proposing this for rc3, but what do you think about the value of testing real temperature cycles? | 06:29 |
---|---|---|
wolfspraul | I think most OEMs are doing temperature cycle testing, do they? | 06:30 |
wolfspraul | I am wondering what kind of value one can get from temperature cycle testing. | 06:33 |
wolfspraul | I just know that all OEMs do temperature cycle testing quite consistently, and we don't. | 06:36 |
wolfspraul | there will be no systematic temperature cycle testing for the rc3 run | 06:43 |
wpwrak_ | for cycle testing, you'd first have to find out what to look for, yes | 06:44 |
wolfspraul | I do have extensive experience in how _NOT_ to do temperature cycle testing :-) | 06:44 |
wolfspraul | at our former employer (that's where my only limited experience comes from), temperature cycle testing was a joke | 06:48 |
wolfspraul | that's the tricky part, I think testing and collecting results is relatively easy. | 06:50 |
wpwrak_ | again, cycle testing != probing the operating range. cycle testing is much more advanced. but if you get complaints that M1 crashes in the middle of a show on a hot night or doesn't boot, etc., your VJ customers will not like to hear that you never tested it beyond 28 C | 06:53 |
wolfspraul | if we find suspicious things during testing, we have time to think more | 07:08 |
---|---|---|
wolfspraul | if you get another board or two, we can use the time very well for more testing | 07:20 |
wpwrak_ | i think we'd need to do more testing if we have to change C238, because it could cause other, yet unknown problems | 03:33 |
---|---|---|
kristianpaul | i had similar experience when testing that peak mode on the scope i have.. | 04:40 |
roh | wpwrak_: there will be ambient testing on the ccc-camp ;) | 05:18 |
wpwrak_ | (100 tests) i think you don't need extra testing for going from 100 pF to 150 pF. the test with 1 nF already proves that you can survive with 10x the capacitance. | 05:56 |
wpwrak_ | aw: i mean your rc3 board, the one we're testing now | 06:26 |
wpwrak_ | aw: you'll need the caps only for rework. i don't think we need any additional testing with values in the 120-220 pF range. i had a lot of faith in my simulation results :) | 06:41 |
aw | meanwhile i am testing rendering at least 10 times @ 10nF | 07:20 |
errordeveloper | in terms of llhdl, i'd be up for doing some testing to start with ... | 10:54 |
wolfspraul | are you testing this on rc2 or rc3 now? | 07:40 |
---|---|---|
wpwrak_ | lekernel_: if you put half a dozen rework variants in his pipeline, you'll never know what he's actually testing and he'll just wear down the board | 11:07 |
lekernel_ | with proper prior testing on rc3, of course - but later | 12:01 |
wolfspraul | aw: ok good, so we are testing the latest idea on your rc2 board first, right? | 13:49 |
aw | this test is a must i think. also testing our new DC adapter. ;-) | 16:05 |
wolfspraul | when we can, and when we don't have a reason to not do so, we should always try to imitate real user behavior when testing | 16:15 |
wolfspraul | aw: continue the boot-to-render testing until we are at 30 or so, better 50 | 16:25 |
wolfspraul | 6) for bootup testing on the other 89 boards, I propose that we start with something like 10 boot-to-render cycles on the first boards, say 10 or 20. And if that is good, we reduce the cycles to 5, then maybe 2. | 16:59 |
wolfspraul | we will definitely do serious boot-to-render testing on all rc3 boards, no worries | 18:13 |
aw_ | so well...i can enable or disable while testing rc3 board when i need to speed up on testing the same board to investigate. :-) | 04:06 |
---|---|---|
wolfspraul | we should collect the various testing documents and materials, and that's a nice one... | 04:18 |
wolfspraul | we need one name, and a clear testing and release process | 05:37 |
wolfspraul | after that, we need to stop testing irrelevant cases on rc3, we should only focus on testing the one and only design we plan to manufacture and sell | 11:16 |
wolfspraul | good. and also see my other points - why do we need D16 at all? why did rc3 boot without D16? stop testing irrelevant cases. how to recover rc3 board now. | 11:23 |
wolfspraul | if there is any value I can provide, it's solid testing across the entire run | 11:57 |
wolfspraul | Adam's testing was a little unfortunate/unfocused, but in the next round we'll narrow it down and then it's done, I'm sure. | 12:02 |
wpwrak_ | have things like DMX and MIDI seen any major testing yet ? | 18:05 |
wolfspraul | we are a team after all, so the most important for me again is that he is in an excellent position to do a good testing job for the 89 boards that will soon flood his apartment | 18:22 |
wolfspraul | so when things go bad, that's when you know whether your testing setup was robust or not | 18:28 |
wolfspraul | even testing problem | 17:25 |
---|
wolfspraul | ximian: ok I'm testing the update-hang with 07-01 a bit more | 02:46 |
---|
wolfspraul | dealing with vendors, quality issues, getting the whole package together, production testing, etc. | 01:04 |
---|
wolfspraul | xiangfu is currently traveling because of an emergency and doesn't have his m1 with him. he probably released the 07-01 image in a rush, without testing much, if at all. | 15:03 |
---|---|---|
wolfspraul | he sent this image out in a hurry, I think while traveling, without access to his m1. maybe even without any testing. | 15:12 |
wolfspraul | [44h] sounds great, I'm not doing any testing now but when I get back to it I will definitely report back | 09:23 |
---|
Fallenou | don't know is bios is doing some usb testing at boot time or not | 16:50 |
---|
rjeffries | wolfspraul I will go away. it doesn't matter when we are testing 1- 2- - 50 chips | 04:47 |
---|---|---|
wolfspraul | wpwrak: there are definitely fabs that will take a mask from you in a 500nm process and just make your wafer without testing | 04:54 |
wolfspraul | then there is testing, big problem | 05:23 |
wolfspraul | I currently understand very little/nothing about IC testing process, need to learn | 05:24 |
wpwrak | wolfspraul: testing probably adds quite a bit to the setup cost | 05:25 |
azonenberg_lab | Basic testing for functionality, or failure analysis? Basic testing is a lot easier | 05:28 |
wolfspraul | ah wait, I took a video at Ingenic once, they were testing chips in fully packaged state | 05:28 |
azonenberg_lab | The testing unit sticks that onto the bare wafer (before dicing) and checks each die | 05:29 |
azonenberg_lab | at 60 microns per pixel (large, i'm just testing the etch rates) | 06:08 |
wolfspraul | at least from what I've seen so far, without exhaustive testing around this issue though | 09:19 |
---|---|---|
aw | before i test, pls let me know what version of s/w you're testing now. | 09:30 |
wolfspraul | I'm testing now, one sec... | 09:32 |
aw | for examples, if say 10/90 percent we find this while testing rc3, we surely need to fine tune capacitors with whole 90 pcs. if all pass then we get there. is it ok? | 12:11 |
wolfspraul | we have been testing several different pcb makers too, I think Adam had some fun :-) | 11:54 |
---|
wolfspraul | ok we'll do more testing | 09:34 |
---|
wolfspraul | lekernel: can you tell me the exact model number of your Philips remote control? Then Adam can try to get the same one for testing the rc3 run... | 02:04 |
---|---|---|
wolfspraul | the remote control situation is much clearer now, another item off the table :-) Xiangfu was able to buy a working Philips remote, so he will get a few more then we have at least something for testing and demoing. | 06:44 |
wolfspraul | xiangfu found a working one, and will order some more. then him and Adam have enough for proper production testing. | 07:55 |
wolfspraul | first of all I'm happy that Adam will soon have a control that will allow for proper production testing | 07:56 |
lekernel | sorry for flooding, just testing commit notification works everywhere... | 11:49 |
wolfspraul | it gets dangerous when you start to fool yourself in testing | 06:47 |
---|---|---|
wpwrak | yeah, if you can't even tell whether the IR receiver is connected or not, then your testing may be in trouble ;) | 06:48 |
wolfspraul | my m1 just froze again in rendering (was testing) - 50 minutes | 07:24 |
wolfspraul | lekernel: fyi - these inconsistencies are with the 'gold standard' rc-5 control Adam is using for testing too, so I'm surprised we see this kind of inconsistencies. Want to find out what's going on. | 09:55 |
---|---|---|
wolfspraul | no way. this is the remote controller Adam sent you months ago for testing. and he uses for testing too. | 10:19 |
wolfspraul | and Adam also is using a non-rc5 control for his testing, and sent Xiangfu the wrong one too? | 10:30 |
wolfspraul | maybe so far Adam's testing was really just to see _any_ value | 10:31 |
wolfspraul | I think I vaguely remember seeing 0x2B/2C values in the rc2 testing, let me check the logs... | 10:32 |
wolfspraul | you can also try the testing images, we probably still have them somewhere | 10:43 |
wolfspraul | when testing the 40 boards from rc2, I don't remember ever running into this test failing | 10:43 |
wolfspraul | Decided that I was not interested in the design part, but instead manufacturing. Maybe that's because I mostly drove software development from the testing side as well :-) | 10:44 |
---|---|---|
wolfspraul | so now I'm working on the manufacturing side - sourcing, testing | 10:44 |
sqgl | shippping, storage, testing, marketing, etc etc | 15:52 |
---|
wolfspraul | so I work on things like sourcing, production testing, hardware quality (iqc/oqc), logistics, sales | 15:52 |
---|
aw | xiangfu, the auto flash script file, it works via internet. while testing rc3 brds, I'd like to offline auto reflash, how can i do? | 10:12 |
---|
azonenberg | I'm going to need to get myself some microprobes for testing as there's no way i can use a multimeter on these things :P | 07:32 |
---|
azonenberg | well actually that'd be 1.25um but close enough for testing, i just need it deep enough to see edges clearly | 09:36 |
---|
lekernel | checking the datasheet we can certainly manually rework a rc2 or rc3 to install the 7180 for testing | 08:50 |
---|
aw_ | lekernel, i remembered that i tried 1000 attempts for testing 're-configuration' | 12:05 |
---|---|---|
lekernel | plus you did testing that was extensive enough | 12:10 |
wolfspraul | yes they were there in emi testing | 00:49 |
---|---|---|
wpwrak | (emi testing) then removing the may backfire. better if you can find out what went wrong | 01:10 |
wpwrak | lekernel: who needs documentation or testing if it works ? ;-)) | 08:33 |
---|
lekernel | i'm testing the twit wall atm :p | 14:50 |
---|
lekernel | just take that, do some quick testing and go ahead | 09:30 |
---|
guyzmo | well, I'm testing it using a linux vm, so at least I'm sure the luam firmware works | 12:11 |
---|
xiangfu | testing | 15:37 |
---|
lekernel | this audio codec is the last thing you're testing? | 10:31 |
---|
xiangfu | testing now. | 14:21 |
---|
kristianpaul | the thing is not clear to me, well me be because i dont understand yet it well, the m1testing, failed too.. | 14:33 |
---|
xiangfu | kristianpaul: lekernel the IRCLOG search fixed. :) http://en.qi-hardware.com/mmlogs/search?q=testing | 15:16 |
---|
xiangfu | lekernel: do you think add a keyboard shotcut for 'fbgarb' is ok in flickernoise? (I already have a some patch for it. testing now) | 11:34 |
---|
mwalle | mm1testing? rtems port? | 16:43 |
---|
roh | its a chip swap. one extra cap needed. some more testing needed, but it seemed to work earlier | 22:32 |
---|
wolfspraul | would you expect a big difference? is it worth testing? | 09:05 |
---|
wolfspraul | well, you are testing | 01:05 |
---|
Fallenou | they are testing it right now | 16:30 |
---|
kristianpaul | aw_: How many or wich kindof sd-like memory do you used for mm1 testing? | 02:36 |
---|---|---|
aw_ | kristianpaul, the source codes must be here: https://github.com/lekernel/m1testing | 02:42 |
wolfspraul | and supporting adam on testing software, i.e. adding features adam needs, documenting the build process | 09:59 |
Fallenou | I am testing something and then I git push :) | 21:49 |
---|---|---|
Fallenou | hum ok I am doing some testings right now | 21:57 |
kristianpaul | xiangfu: https://github.com/lekernel/m1testing/blob/master/src/tests_audio.c | 03:44 |
---|
wolfspraul | I vaguely remember at one time (and only once) during rc2 testing, we had a case where something SECAM was detected. | 00:39 |
---|---|---|
wolfspraul | let me try to grep the production testing log files, if I can fine them. one sec... | 00:39 |
wolfspraul | I remember that one time during testing, there was something SECAM we ran into, right? | 00:44 |
wolfspraul | I suggest you don't try extensive testing around this bug, just stay away from it. We have damaged 2 boards trying to track this down with extensive/aggressive testing. | 02:12 |
wolfspraul | that may be a result of our testing, but still, no need for many people to dig around there at the same time. | 02:12 |
aw_ | kristianpaul, yes..stay way from extensive testing. | 02:13 |
lekernel | btw, i'd be up for some directed ESD testing on that part | 10:44 |
wolfspraul | you say you worked on products before, and they showed certain bugs, under EMC testing? | 13:00 |
wolfspraul | lekernel did not do any EMC testing, he just ran his board, when after hours suddenly he video-in started failing. | 13:01 |
wpwrak | (attacks on irc) may also be some amount of bot-net testing. easily available target that gives feedback and doesn't call the cops | 21:15 |
---|
lekernel | assist in developing and testing your own software and hardware for | 12:44 |
---|
aw_ | lekernel, the condition is tested by normal power on. if said using 1000 times testing when just delay 200ms (not use fast power cycling ) i agreed this approach to confirm reset ic completely needed. | 12:49 |
---|---|---|
Fallenou | unit testing in hardware :) | 13:03 |
wolfspraul | fixable how? do you want Adam to do more testing, to try to reproduce something? | 14:58 |
lekernel | but PCB-wise the DRAM is fine...I did a lot of testing last summer | 14:58 |
wolfspraul | also tricky to keep this in mind to improve the testing software for the next run | 15:01 |
wolfspraul | we have this 0x24 and it's on hold (won't be sold), and maybe we can learn something or introduce some fix, whatever fix, even if just to the testing software | 15:04 |
wolfspraul | NAND testing is quite sophisticated though, they have special fixtures and software from Samsung | 15:10 |
larsc | doing automated regular testing sounds like a good idea, but i guess you need go testcases then | 17:23 |
wpwrak | lekernel: (testing $?) how about command || exit ? | 17:39 |
lekernel | if it's for testing ftp, you can try the ramdisk | 23:52 |
---|---|---|
lekernel | reminds me of my multi-dozen-terabyte memory controller testing fun :) | 23:59 |
adamw_ | kristianpaul, this msg actully is good for me, at least no boot anymore..ha... I'm testing my Sch. 3 experiments: http://en.qi-hardware.com/wiki/Milkymist_One_Power_On_Off_Sequence#The_schematics_of_three_experiments | 03:46 |
---|---|---|
wolfspraul | well, the reason I am curiously following this is that we still have those 2 boards that I 'broke' in the initial round of testing | 14:39 |
wolfspraul | and the dram solder problem emerges from power cycle testing? | 14:41 |
lekernel | it can emerge at any time, and according to Murphy's law, during power cycle testing | 14:41 |
wolfspraul | the reason we are not looking into the old two, fully unbootable (and shelfed) boards right now is that back then we did a lot of testing with a lot of boards | 14:42 |
lekernel | though it serves its purpose of testing the PCBs | 19:25 |
---|
wolfspraul | lekernel: I told you we did pretty thorough/extreme testing. | 11:41 |
---|
Fallenou | thanks for testing anyway :) | 10:41 |
---|
Fallenou | maybe I did it wrong while testing | 21:14 |
---|
lekernel | but it's sometimes instable... if I ever participate in GSoC again i'll have a totalitarian policy about testing and bugs | 17:53 |
---|
481 matches in 4672 log files with 136339 lines (2.7 seconds).
Generated by irclogsearch.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!