#milkymist IRC log for Friday, 2011-02-25

Fallenouworked with 304 Ko too00:08
Fallenougotta go will do more tests tomorrow00:09
kristianpaulFallenou: yaffs2 sorry :-)02:06
kristianpaulFallenou: and not in the sd card, did i meant that? sorry if..02:09
kristianpaulnice https://github.com/lekernel/llhdl/wiki/Example-LLHDL-interchange-file :-)02:43
aw_kristianpaul, with this http://en.qi-hardware.com/wiki/Milkymist_One_Power_On_Off_Sequence#Results02:45
kristianpaul:/ http://en.qi-hardware.com/wiki/File:M1rc2_0x2c_splash_wrongbackgroundcolor.jpg02:46
aw_if i want to dump from falsh, use "readmem ADR LEN FILENAME", my question is that with my met problem on "No boot medium found", What's the ADR I need to fill?02:46
aw_"readmem 0 ??? filename"02:47
kristianpaulwait give i'll give you right instructions02:47
aw_how long of copied memory length I should.02:48
kristianpaulwhole nand? :-)02:48
aw_yeah, but i don't think that i need to dump all. shall i?02:48
kristianpauli think, you should02:49
aw_also I don't know the allocation of current images they are.02:49
kristianpaulhttp://milkymist.org/wiki/index.php?title=Flashing_the_Milkymist_One <- [edit]  Flash Memory Distribution02:49
aw_so dump how many & start address where?02:49
aw_hm...those addresses are the allocation? hmm..good. thanks.02:50
kristianpauljtag> readmem 0 33554432 mm1_kristianpaul_dump02:52
aw_so my problem on "no boot medium found" will disconnection on which blocks probably?02:52
aw_just from 0? ..wow.02:53
kristianpaulno no02:53
kristianpaul0 will be nice, just in case02:53
kristianpaulbut you can read from 0x006E000002:53
kristianpaulreadmem 0x006E0000 1466036 file_dump02:54
kristianpaulwhy 1466036?02:54
kristianpaulI'm gessing the file size acording to the flickernoise bin i have here02:54
kristianpaulyou can increase that a bit02:54
aw_"REGULAR BITSTREAM", i was thought that BIOS works well, this means that bit stream inside fpga is already normally work well, doesn't it?02:55
kristianpaulwell, it should02:55
kristianpaulah sorry adam !02:55
aw_yeah...must be related to the image somewhere about flciknoise?02:55
kristianpaulis 0x00920000 not the other addres02:55
aw_am i worng?02:56
kristianpaul0x00920000 <- flicernoise02:56
kristianpaulno i was02:56
aw_ah...REGULAR APP is the start of likely flicknoise? is it that you want to say?02:56
kristianpaulfor the no media found message, yes,  related to flicernoise is the default asumption02:57
kristianpaulaw_: yes i do :_)02:57
aw_kristianpaul, hm..got it, much tks.02:57
aw_so i think i can still dump all..02:58
kristianpaulaw_: when you said background changed, what the color should be?03:00
kristianpaulwel not all, from 0 up to 0x00920000 + 200000003:00
kristianpauljust.. i dont remenber how update was you nand with mine.. as i wipedout nand and started from scratch..03:01
aw_i remember that background color is dark blue with many white mark grains.03:02
aw_yeah..my image is still old enough .03:02
aw_ok...then "readmem 0 0x02920000 mm1_adam_dump"..:-)03:05
kristianpaulyes i think03:05
aw_ans then how can i compare with my own current image?03:06
kristianpaulhow sense is now dump if you dont have a initial-dump to compare with?03:06
aw_no, i have..03:06
kristianpaulah you have two twin boards? good03:06
aw_so my question is how i can compare both dumped file?03:07
kristianpaulyes, wait03:07
aw_jtag> readmem 0x0 0x02920000 mm1_0x2c_dump_2011022503:10
aw_Error: cmd_readmem.c:57 cmd_readmem_run() illegal state: Bus missing03:10
kristianpaulbtw whole dump procedure http://paste.debian.net/108791/03:10
kristianpaulhey !03:16
kristianpaulfor comapre03:16
kristianpaulyou need installed hexdump and vimdiff03:16
kristianpaulare you aware of vim basic move commands?03:16
aw_i don't know. (:03:17
kristianpaulokay, first get the dumps so i have a bit of time to get another way just in case03:18
kristianpaulhmm that take time... (dump)03:18
kristianpaulstill reading on my side (same comands i send you)03:18
kristianpaulaw_: how is yours going?03:19
aw_okay..i need to learn that fjmem firstly i think.03:19
kristianpaulgoos, get the dumps it can be compared later03:20
kristianpaullet me paste what i did here03:20
aw_yeah..just saw u used pld load ***.bit03:20
kristianpaulah yes !03:20
aw_i haven't done this before..so need take time. :-)03:21
kristianpaulaw_: get this file http://www.milkymist.org/msd/fjmem.bit.bz203:21
kristianpaulI'm patient03:21
kristianpaulinside there is fjmem.bit03:21
kristianpaulso no more *** ;-)03:21
aw_could u paste what u did first...then i quite need to take time.(:03:22
kristianpaulah my fault03:22
aw_no no,, thks03:22
kristianpaulwait i'll paste again shortly version03:22
kristianpaulbut get that fjmem.bit !03:22
kristianpaulok some flood:03:24
kristianpaulcable milkymist03:24
kristianpaulinstruction CFG_OUT  000100 BYPASS03:24
kristianpaulinstruction CFG_IN   000101 BYPASS03:24
kristianpaulpld load fjmem.bit03:24
kristianpaulinitbus fjmem opcode=00001003:24
kristianpaulfrequency 600000003:24
kristianpauldetectflash 003:24
kristianpaulendian big03:24
kristianpaulreadmem 0 0x02920000 memory1_dump03:24
kristianpaulfor the record ;-)03:24
kristianpaulaw_: http://paste.debian.net/plain/10879203:24
kristianpaulall that in urjtag03:25
aw_where's the default of jtag path? so i need to copy fjmem.bit into it.03:25
kristianpaulmake sure put fjmem.bit in the same directory in wich you run urjtag03:25
kristianpaulsnowflakes pic looks like a sdram problem, *i think,*03:26
aw_okay...nice hint. I'll look at it.03:30
aw_just need to record first then i back to check h/w patch.03:31
aw_kristianpaul, i need to digest them, tks for those instructions above!03:32
kristianpaulOkay, i think you compare following like this http://paste.debian.net/108794/03:33
kristianpaulaw_: ok !03:33
kristianpaulI'll sleep now, so i can wake up early ;-)03:33
aw_oah..right..the most important is the comparisons.03:33
kristianpaulcheck the last link later i think you can compare that way03:33
kristianpaulI dint found a hexdump comparator _right_now_ so you can get something to work with that way i think03:34
aw_yes, sure03:35
kristianpaulwith gvim just scroll so is easy :-)03:35
kristianpaulI did some quick test here and seems to work03:35
aw_those stuffs are really useful to me. ;-)03:36
kristianpaulargg small typoe03:36
kristianpaulgvimdiff memory1_dump memory2_dump03:36
kristianpaulis actuallt03:36
kristianpaulgvimdiff memory1_dump_text memory2_dump_text03:36
aw_yes. :-)03:37
aw_lekernel, i dumped two brds(one with "No boot medium found" is Sch. 3, the other booted(flicknoise works well) is Sch. 1) memory from memory. See http://en.qi-hardware.com/wiki/Milkymist_One_Power_On_Off_Sequence#Results11:06
aw_when you have time, could you help on viewing secrets probably hidden behind two dumped texts?11:09
lekernelyou dumped at 0x02920000 ?11:11
aw_readmem 0 0x0292000011:12
lekernelthat's the filesystem11:12
aw_LEN = 0x0292000011:12
lekernelah, 0!11:12
aw_yeah..my background color is different with normal one.11:12
lekernelso you dumped the complete flash, right?11:12
aw_yeah..from 0x011:12
aw_i should say from 0 to 0x0292000011:13
aw_i was wrong on steps?11:13
lekernelobviously yes: the two files do not have the same size11:14
aw_yeah....0x14 have a huge size of 24.3MB, 0x2c is only 5.4MB11:15
lekerneljust dump the complete thing (32M)11:17
lekernelbtw you can use vbindiff to directly compare the binary data11:17
aw_hm..try now..11:19
aw_sorry, i misunderstood, vbindiff? I didn't know this.11:21
aw_hmm...good i just googled.11:21
aw_I'll not immediately replace 0x2c's chip except i have hard info said it was totally failure. So you think that it has been already failed?11:24
kristianpaulah, vbindiff, nice :-)11:47
lekernelno, it seems fine11:48
lekerneldon't replace anything11:48
aw_lekernel, seems fine? hmm...that's good. how to verify that it's fine. is there any obvious info. can you teach me? if it's hard, doesnt matter. :-)11:49
lekernelwell, if detectflash finds it, and if the data is not complete garbage, the flash chip is probably OK11:50
lekernelhave you read the complete 32MB already?11:51
aw_with 0x2000000(LEN)?11:51
kristianpaulaw_: why you dumped from different ADR in the both samples?11:54
aw_different ADR? No, i did with the same "readmem 0 0x2920000" on different boards(0x2c, 0x14).11:55
kristianpaulah, but size of dump is dramatically different between two boards, why?11:57
aw_yes, that's totally confused me a lot!11:57
aw_i dont know.11:58
kristianpaulokay let me see here11:58
aw_that's why i was thought if flash chip already got failed?11:59
kristianpaulaw_: the smaller one is a "bad" board?12:00
aw_kristianpaul, exactly12:01
scrts`hm, who made milkymist pcb? lekernel?12:01
kristianpaulscrts`: hu12:02
aw_scrts`, hi, we sharism.cc made.12:02
scrts`I can't find how to add fiducials in altium :\12:03
scrts`maybe someone knows? :)12:03
aw_scrts`, are you saying adding optical fiducial on board edge for smt auto mounted reference?12:05
aw_hmm...we let pcb maker added those fiducials.12:06
scrts`hmm... :\12:08
aw_those fiducials you should reference to your smt manufacturer firstly then get criteria they can make on their smt machine carrier/conveyor, then feedback/add into to your own design or just let pcb maker helped you.12:08
aw_pcb maker will serve you. :-)12:09
aw_and build suitable panel gerber for you. :)12:09
scrts`nah, he told me to do the fiducials12:12
scrts`since the company has a machine, the fiducials can be placed as I want12:13
scrts`I can;t find the function of the fiducial placement12:13
scrts`it could be a simple pad, but there has to be certain layers/masks..12:13
kristianpaulaw_: 0x14 board is the one with "No boot media found" isnt?12:16
aw_No, 0x2c board is the one with "No boot media found".12:17
kristianpaulah yes sorry12:18
kristianpaulaw_: 0x2c board have a boot splahs screen wich said rescue in the botton, inside a red square?12:19
aw_kristianpaul, no, it didn't appear in rescue in the screen. :(12:19
kristianpaulok ignore that question12:20
kristianpaulanyway 0x2c dump dont make sense to be smaller is is the good one12:20
aw_kristianpaul, maybe i just reflash 0x2c & 0x14 then compare them again?12:21
kristianpaulaw_: :-)12:21
aw_kristianpaul, you smiles means ok? or not? i know it's bad idea.12:22
aw_but why not? :-)12:22
kristianpaulaw_: i think you should read again 0x2c12:22
kristianpaulThen only diff i can see now are some bytes in standy bitstream12:22
kristianpaulI dunno if this a serial like number included in bitstream may be lekernel can add something?12:23
aw_scrts`, i don't know how to add. sorry that.12:23
kristianpaulaw_: Btw, What you think is the goal of dumping nand from the two boards and comparing then?12:24
lekernelaw_: what is the current status of 0x2c and 0x14 boards?12:24
lekerneldo you have one which no longer boots at all?12:24
lekernelor did it "revive"?12:24
aw_since i can't see/realize both them from dump, if you here can.12:24
aw_yeah...0x2c now it revived.12:25
lekernelso you never have the "No boot medium found" error again?12:25
aw_the day before yesterday, it can not booted anymore even.12:26
lekernelok, and now it always boots?12:26
lekerneland what is the problem on the 0x14 board?12:26
aw_no...after used Sch 3. it can be booted even shows flicknoise....then after 9 ~ 10 times fast power cycling...it shows "No boot meddium found"..12:27
aw_and under ">BIOS"..12:27
lekernelwhat is the problem on the 0x14 board?12:27
kristianpaullekernel: that process of flashing with impact included some file system with a wallpaper and patches on it?12:27
aw_then i kept trying to fast power cycling...then finally can not booted anymore.12:28
aw_0x14 board with RC2 schematic(Sch. 1)12:28
lekernelkristianpaul: no we don't flash a filesystem atm12:28
aw_and I let it booted to dump flash info to compare.12:29
lekernelwe should, but as I highlighted yesterday making the images is rather messy12:29
lekerneland, on the 0x2c board, have you experienced the "no configuration" bug?12:30
aw_so i tried to see here if you can see any obvious err on both boards.12:30
lekernelimo the "no boot medium" error has nothing to do with the flash12:30
aw_lekernel, yes, the 0x2c has experienced the unbooted condition.12:31
lekernelhave you experienced "no configuration" (ie LEDs weakly lit and no serial output) on 0x2c?12:31
lekernelthere are many unbooted conditions :)12:31
aw_yes. 0x2c has weakly for surely before12:31
lekerneleven with Sch. 3?12:31
aw_also no serial output12:31
aw_all Sch. 1, 2, 3. on 0x2c had have.12:32
lekernelso, even when you applied the "sch. 3" modification, you still have the intermittent no configuration problem12:32
lekernelwhose symptom is LEDs weakly lit after power up and no boot at all (no serial output)?12:33
lekernelright now we are tracking down the _configuration_ problems, so anything that can yield a serial output is a PASS12:33
aw_sometimes no SPLASH screen shown when no configuration. but not everytime.12:34
lekernelwhen there's no configuration, there is NEVER a splash screen...12:35
Fallenoulekernel: ubuntu may have soon a replacement for  X Window System :) it's called Wayland12:35
Fallenouit's in 11.04 repositories12:36
lekernelaw_: the reset IC is ONLY meant to track down "no configuration" issues12:37
aw_lekernel, hm..i should say more precisely, sorry12:37
lekernelanything else, like that "no boot medium found" error, is irrelevant12:37
aw_surely the reset IC is usefull12:37
lekernelso, after you have put that reset IC and the diode connected as in Sch. 3, the FPGA always configures reliably?12:38
aw_when i see there's no splash shown, the D2/D3 either weakly  lights or ON. that's so confused me!12:38
lekernelweakly lit is bad12:39
lekernelbut the configuration problem happens even before you boot12:39
lekerneljust apply power, and see if the LEDs are weakly lit or not12:39
aw_No, at the beginning of about 9~ 10times with Sch 3. it works well even with logo/splash shown...12:39
lekernelok, we don't care about high level things like logo/splash for now12:40
aw_before 9 ~ 10times, the D2/D3 works well.12:40
lekernelwe just care about whether the fpga always correctly loads its STANDBY bitstream (ie that waits for the middle pushbutton press) after power is applied or not12:40
lekernelwhich is what the reset IC is meant to fix12:40
aw_lekernel, second..connect 0x2c again.12:41
lekernelyou can tell if it works or not by power cycling and checking that the FPGA is immediately configured or not12:41
lekernelchecking for a configured FPGA can be done by checking that the LEDs are off (not weakly lit) and/or that the DONE pin is high12:41
lekerneldo not press any pushbutton12:41
lekerneljust apply power and check the FPGA configures itself12:42
kristianpaulFallenou: over flow !!12:43
Last message repeated 1 time(s).12:43
Fallenoudamn it12:43
Fallenouanyway the "memory allocated on stack" is indeed a bug, but it shouldn't not trigger overflow12:44
Fallenouso I had little hope to fix the overflow with that12:44
aw_ok...now it works well-configured and DONE pin finally pull high well.12:44
Fallenouthe only thing it can fix is that we have less chances to send garbage now :)12:44
lekernelaw_: does it do that all the time and very reliably or not?12:44
Fallenouthanks you for the test kristianpaul but now when the over flow does not happen, at least it should be more reliable (less garbage packets sent)12:45
lekernelaw_: may I remind you the problem we had before, and that the reset IC was meant to fix, was that in 1% of the power ups the FPGA did not load the standby bitstream from flash12:45
lekernelif we can power cycle the board, say, 1000 times, and the standby bitstream load always works, we can conclude the reset IC fixed it12:46
lekernelthat's the first thing to try...12:46
kristianpaulFallenou: (send garbage) oh, let me test that too12:48
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
Fallenoukristianpaul: yes, with the dma on the stack, the chances were high to send garbage, since the stack gets changes as soon as the send() function returns12:50
Fallenoukristianpaul: so now it does not depend on the stack state anymore12:50
kristianpaulFallenou: i dont remenber, you did test ttcp from rtems to host, isnt?12:52
Fallenouhumm yes I think so12:52
FallenouI tried both12:52
kristianpaulstill not working here :-/12:52
FallenouI will try again but I am pretty sure I did12:52
lekernelaw_: so, have you successfully loaded the standby bitstream from flash in 1000 successive power cycle attempts?12:52
Fallenoukristianpaul: btw yesterday I tried sending *and* receiving small files (like 400 kB) via FTP12:53
lekernelwith the reset ic connected?12:53
Fallenoukristianpaul: with md5sum correct in the end12:53
aw_lekernel, bad...start to count now. (:12:53
Fallenoukristianpaul:  I first send a file to rtems, then receive it back and test it's integrity, it worked, but I must say with a 9 MB file I had a failure on the md5sum12:53
Fallenoukristianpaul: Will do more tests with big files12:53
kristianpaulFallenou: oh, even on qemu...12:54
aw_lekernel, sure with Sch. 3 on 0x2c board.12:54
FallenouWill re-do the test to confirm12:54
Fallenoumaybe it was a problem related on the filesystem12:54
lekernelaw_: if yes, then we always put the reset IC and we're done with that12:54
Fallenousince I used the memory card12:54
lekernelgreat, one less problem :)12:54
aw_lekernel, don't know yet..stay tuned..12:55
Fallenouhow are you going to do 1000 power cycles and test DONE pin state ? :o12:55
Fallenouwill take hours12:55
Action: Fallenou is not familiar with tests in PCB factories12:56
kristianpauli think he have a hardware for automate that i hope ;-)12:56
kristianpaulwow 1000, i tought china's general rule was 50 ;-)12:56
aw_kristianpaul, i agreed this 1000, why not?12:57
kristianpaulaw_: sure go ahead ! :-)12:57
kristianpaulwill be fun12:57
aw_if not, we try other..(:12:57
lekernelFallenou: if it weren't hard, it wouldn't be called hardware :p12:59
aw_lekernel, hey..wait. you said that loaded standby bitstream from flash?12:59
lekerneland maybe not 1000, perhaps say 300-400 would suffice ;o)12:59
kristianpaul500 ! ;-)12:59
lekernelaw_: yes, the FPGA loads a standby bitstream from the flash immediately after power up13:00
kristianpaulso less bugs will appear13:00
lekernelit is this bitstream that waits for the middle pushbutton to be pressed and triggers the boot process13:00
aw_am i just watching they are all good display on splash you tried to say?13:00
aw_hmm..got it, i always do like this!13:01
lekernelno, NO SPLASH13:01
lekernelthe splash screen is displayed WAY AFTER the standby bitstream...13:02
aw_i pressed middle pushbutton surely13:02
Fallenoujust check the DONE pin13:02
aw_also check DONE pin on scope!13:02
Fallenouoh ok13:02
lekernelwhen you see the splash screen, not only the standby bitstream was loaded, but also the milkymist soc bitstream, which ran the BIOS from flash, which carried out DRAM memory tests, enabled the video controller, and finally loaded the splash screen from a flash partition13:02
lekernellots of stuff13:03
lekernelright now we test something very simple, the standby bitstream loading13:03
Fallenouunit testing in hardware :)13:03
lekernelthat's what we had problems with, not the rest13:03
lekerneldo not touch the pushbuttons. if you are thinking of a test for the reset ic that involves pressing the pushbutton, it is wrong13:04
lekernelyou can either check the DONE pin or the LEDs13:04
aw_hmm..just see either DONE pin or LEDs, i see.13:05
aw_21 times..now13:05
lekernel"LEDs weakly lit" is equivalent to "DONE pin low"13:05
aw_yes,,,,i discovered it.:-)13:08
aw_lekernel, reminding that i power on normally not fast power cycling surely.13:09
aw_man! if i have power relay to switch programly that would be wonderful.13:10
lekernelyeah, that's definitely something very useful for this kind of test13:11
lekernelalong with automonitoring of the done pin ...13:11
lekernelit'd make an interesting project: scriptable relay and measurement system13:12
aw_btw, do you think this maybe later you can help on easy main c code then I survey relay card on web firstly?13:12
aw_how do you think?13:13
aw_54 times now ...still good.13:13
aw_i used this http://cgi.ebay.com.sg/USB-16-Channel-Relay-Board-Virtual-Port-12V-/170432366651 before13:15
wolfspraulFallenou: in hardware and especially manufacturing nobody is afraid of 1000 times anything13:16
wolfspraulhow about 100k whatever step, or 1kk, or more? :-)13:16
wolfspraul1000 times, whatever it is, is almost zero, right Adam? :-)13:17
wolfspraul(just kidding, but partially it's true. 1000 times some test - no big deal) in a factory you easily have a lot of workers, so after you did the first 50 yourself, you introduce some kid to the procedure, and go out for lunch :-)13:17
wolfspraulI've personally reflashed 2000 Ben NanoNote by now, although on the second thousand I cheated by offloading some steps to nice and helpful worker hands...13:18
aw_wolfspraul, wait..if this can pass over 500 times, surely we have confidence on adding reset ic idea. i agreed since it's stupid tests but extremely tests.13:18
wolfspraulthat was a lot more relaxing, I could drink a coffee and watch them flash13:18
wolfsprauland yes, you can automate everything, but that costs time and money again so the question is whether the 1k becomes 10k or not, or when, and then you decide whether it's worth to automate it or not13:19
kristianpaulFallenou: i cant confirm this right now, but i think transfer (than send) data from mm1 now is faster and work with ~ 3Mb files so far13:20
aw_lekernel, btw, would you also try to think that if it's passed then what steps..we should...13:21
lekernelif it's passed, we put the reset IC, period!13:22
aw_because I was surely that I ran into unbooted status when fast power cycling..13:22
lekernelthe only unbooted status that matters here is "no configuration"13:22
lekernelall other bugs are irrelevant to this case13:22
wolfspraulaw_: was that with weakly lit leds?13:22
wolfspraulif I understand lekernel correctly the best criteria to test the reset IC now is to watch for weakly lit led13:23
lekernelto watch for weakly lit leds *immediately after power up*13:23
wolfspraulif you don't see that, it's not the problem we are trying to fix13:23
lekernelafter power up, actually the LEDs should be weakly lit for less than a second (while the fpga reads the standby bitstream from flash) and then go completely off13:24
aw_wolfspraul, right, like lekernel just said. it immedaitely leds(D2/D3) on after power up.13:24
wolfspraullekernel: can they go back to weakly lit later?13:24
lekernelyeah, if the standby bitstream fails to reload the final bitstream for example13:25
lekernelwhen you push the middle button13:25
aw_sorry I should precisely said "weakly" lit during 200ms13:25
lekernelbut that would be a different bug13:25
aw_then off...this is OK.13:25
wolfspraulok got it13:25
lekernelaw_: yes, that's perfect, and the behaviour that the boards with the reset IC should always have13:25
aw_i must be have because configuration datasheet said that PROGRAME_B must pull low until power on ready on flash!!!13:27
aw_we just all missed this important info while design. :-)13:27
lekernelactually, the fpga only reads the flash after some 5 ms after power up13:28
aw_surely it didn't say to use rest ic.13:28
lekernelwhile the flash is ready in a few hundreds microseconds13:28
lekernelso it was supposed to work13:28
aw_but surely reset ic itslef has this behaviour.13:28
aw_yeah..also recommended P3(300us) on flash chip..well...we learnt this important stuff this time too.13:29
zumbilekernel: how did you get spartan6 chips? are those available to buy?13:30
aw_130 times13:30
lekernelzumbi: yeah, iirc you can find them at digikey13:31
lekernelotherwise just go to some xilinx trade show and you'll find plenty of distributors that will sell you some (and ask lots of questions)13:31
aw_200 times13:40
lekernelaw_: looks good13:40
aw_300 times13:50
aw_400 times, good :-)13:58
aw_i' happy now we passed 500 times.:-)14:05
Action: kristianpaul checks deadairspace14:06
lekernelgood, so this reset ic definitely fixed that startup problem we had14:06
wolfspraullekernel: do we want to increment the hardware revision counter for rc3?14:07
lekernelyeah, let's increment it all the time14:07
lekerneleven for the slightest pcb change14:07
aw_600 times14:13
kristianpauloops "452 Error writing file."14:14
aw_700 times, good.14:20
aw_kristianpaul, what's that?14:20
kristianpaulFallenou: wow, 500Kbytes/sec sending data from MM1, Thanks !!! i can start some work now that at least i can transfer data and faster14:20
kristianpaulaw_: ah, he and error when transfering a ~9Mb file to rtems running on MM1 :-)14:20
Fallenoukristianpaul: oh it improved the speed ? really ?14:20
kristianpaulFallenou: YEAH14:21
Fallenouoh oh :) nice ! but I don't understand why :p14:21
kristianpaulActually before that i wasnt able to transmit big (< 1Mb) from the mm114:21
kristianpaulFallenou: how i can create a dummy big file with rtems shell? ie dd ... but no dd so..14:22
kristianpaulah yes dd is there !14:22
Fallenoubut you can create the file on your computer14:22
Fallenouand send it via ftp14:23
Fallenouin /ramdisk14:23
kristianpauli mean yes, but i want a 20MB file :D14:23
kristianpaulthat crash the board..14:23
kristianpaulergg rtems14:23
kristianpaulwhat is /ramdisk for?14:24
Fallenouit's a ramdisk :)14:24
Fallenouit's RAM, mounted as a disque14:24
kristianpaulah i see14:24
Fallenouit's faster and more reliable than a filesystem14:25
kristianpaulhm interestinf14:25
Fallenouto do benchmarking of ethernet14:25
Fallenouyou should use the ramdisk14:25
kristianpauloh, yes14:25
kristianpauli dint knew it14:25
kristianpaulFallenou: whats the /dev/zero equivalent in rtems?14:26
Fallenoudon't know14:26
Fallenoumaybe there isn't one14:26
Fallenoubut you can easily code a driver that adds a /dev/zero14:27
Fallenoutake the gpio code, remove all useless code14:27
Fallenouand put return 0 somewhere14:27
Fallenouand you got it14:27
aw_800 times14:27
Fallenouaw_: :)14:27
kristianpauldammn, rtems got freezed when trying a rm..14:30
Fallenouwhere did you rm ?14:30
kristianpaulin /ramdisk14:30
Fallenoudon't know, shouldn't freeze :/14:31
Fallenoucheck in the code what is mounted in /ramdisk14:31
FallenouI didn't actually check if it is really ram14:31
Fallenoubut it should be14:31
kristianpaulhe, i filled14:32
kristianpaul4328960 bytes and no more space left :p14:32
Fallenouoh ok :)14:32
Fallenoumaybe that's the reason14:32
Fallenouyou can maybe increase the amount of ram mounted in the source code14:32
kristianpaul4Mb is too small :/14:33
Fallenouit's the same in linux14:33
Fallenoudefault ramdisk size is 4 MB14:33
Fallenoubut you can increase it14:33
Fallenouit's usefull to test hard disk/sd card speed14:34
Fallenouor ssd14:34
Fallenouinstead of copying from a disk to another14:34
kristianpaulnice i learn  a new thing14:34
Fallenouyou do a big ramdisk and then copy it to the disk you wanna test14:34
kristianpaulyeah IO is pain for benchmarking  this things14:34
aw_900 times14:35
aw_YES! 1000 times. MAKE IT! Although it's done manually. :-) Likely "manually reliable test on power start-up" test item. :-)14:42
Fallenouvery good !14:43
Fallenouproblem fixed14:43
aw_less bugs...14:43
aw_next steps: how to test "fast power cycling" with Sch. 3? hmm...hard to control a tiny interval like this : http://en.qi-hardware.com/wiki/File:M1rc2_0x2c_DONE_PROGRAM_B_rising_OnOffOn_marked_problems.jpg14:45
aw_Manually to test this. bad idea. (:14:46
wolfspraullekernel: let's assume the diode/reset ic fixed the original bootup bug completely.14:47
wolfsprauland let's further assume that there are more bugs at some later stage in the boot process14:48
wolfspraulwhat is the likelihood that any of those further bugs require hardware modifications to be fixable?14:48
wolfspraulas opposed to them being fixed by modifications on the software side14:49
aw_I'll try to think about this on fast power cycling test. ;-) Although my python is still studying..14:52
wolfspraulcalling it a day, I see the answer to my question later :-)14:53
wolfspraulgood news now, seems one real bug is fully fixed14:53
lekernelI haven't noticed other hardware bugs so far14:54
aw_wolfspraul, definitely fixed on start-up without configuration. ;-)14:54
wolfspraullekernel: so those other things adam described there are all things that can be fixed in software?14:55
wolfspraulcrc error, gray screen, no boot medium, no background picture, etc.14:55
wolfspraulhe didn't just 'describe' them, he actually took pictures :-)14:56
lekernelthose sound like DRAM issues14:57
wolfspraulfixable how? do you want Adam to do more testing, to try to reproduce something?14:58
lekernelbut PCB-wise the DRAM is fine...I did a lot of testing last summer14:58
wolfspraulthat reminds me that one time, on one board, only one of the DRAM tests in your test program failed14:58
wolfspraulbut the others passed14:58
lekernelit could be solder issues, semiconductor process variation issues (software fixable) or I/O timing calibration bugs (also software)14:59
wolfspraulmaybe it was hammer or crosstalk? need to check the records.14:59
lekernelyeah, we had that too14:59
lekernelthis one is weird14:59
wolfspraulwe saw this once, definitely (it's in the log file), but then it went away14:59
lekernelthat and the video chips that mysteriously burnt themselves...14:59
lekernelon the reworked boards15:00
wolfspraulboard 0x2415:00
aw_no, that dram problem i still have it(0x24)15:00
wolfspraulcrosstalk fails in about 1 of 10 attempts15:00
wolfspraulalso tricky to keep this in mind to improve the testing software for the next run15:01
lekerneldid the PCBs go through extensive e-test?15:01
wolfspraulwe already searched around that 0x24 with x-ray for >30 minutes15:01
wolfspraultons of pictures, nothing found15:01
wolfspraul(not to answer your e-test, just soldering issues and other x-ray identifiable problems)15:02
wolfspraulwell once Adam settles the diode/reset ic fully, he will turn to some of those others boards and issues we found15:02
wolfspraullike the 0x24 hammer/crosstalk case15:02
wolfspraulor others - Adam has best overview15:02
lekernelotoh I have run tests involving several dozens of terabytes transferred on RC1 on random addresses, and it all passed to the slightest bit15:03
aw_lekernel, what's your e-test meaning? impedance test on traces about dram?15:03
wolfspraulsure sure, but once you produce more and more units you find more and more irregularities. that's hardware.15:03
lekernelno, test that PCB traces do not touch one another and are not broken15:03
wolfspraulwe 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 software15:04
wolfspraulthat would be immediately visible in x-ray, I would think15:04
lekerneldunno, could be subtle and in one small location15:04
wolfspraulanyway I'm jumping around.15:04
wolfsprauldiode+reset ic first15:04
lekerneland there are hundreds of DRAM traces15:04
lekerneli'd say go for rc315:05
aw_hmm..the rc1 & rc2 did sure a test called open-short test while producing pcb. i always asked them do this on demand and paid. :-)15:05
wolfspraulyes but we had a big x-ray session with that particular board, trying to hunt down dram issues specifically.15:05
wolfspraulno, Adam will definitely try to dig into some of the other cases we found15:05
wolfspraulnot indefinitely, but now that the bootup bug is fixed finally he will have a clear mind to look a little into those other things - they were immediately sidelined at the beginning15:06
aw_the open-short test is the one connecting touch both sides on traces. ;-)15:06
wolfspraulI think that 0x24 is one of the more interesting open cases.15:07
wolfspraulmaybe others too15:07
wolfspraulthat's Adam's call15:07
wolfspraulthe reason I'm worried (and happy) about 0x24 is that if a test only fails in 1 out of 10 runs, that means 90% of this type of bug will slip through unnoticed15:08
wolfspraulso we don't even know whether other boards, even ones already sold, might have the same problem. we certainly didn't run the memory tests 10 times on all 40 boards.15:08
wolfspraulcannot go into rc3 like that, imho15:08
lekernelI can modify the test program to run the crosstalk test 100 or more times15:09
lekernelit's easy and that test is fast15:09
wolfspraulthat's a good first step15:09
wolfspraulI think15:09
wolfspraulaw_ - up to you really, not me.15:09
lekernelbtw, how do you test the nanonote sdram?15:10
wolfsprauldon't know, those are proprietary tools and test stations that weren't 'freed' yet :-)15:10
wolfspraulnot that there are big secrets there, but just nobodu had the time yet to dig this up15:10
wolfspraulNAND testing is quite sophisticated though, they have special fixtures and software from Samsung15:10
aw_lekernel, I'll take some times on 0x24, meanwhile u could provide me a s/w that can only test dram in 1000 times. :-)15:11
aw_because I didn't replace that 0x24 two drams. At the beginning of rc2, I reworked too much.15:12
Action: lekernel running git bisect for gcc... found bad/good commits for the lm32 breakage15:12
aw_the one may just some probably easy bug on producing not design, but dont know yet. so thanks that if have routinely s/w can test dram. :-)15:13
wolfspraulthe notes of 0x24 say U14/U15 was resoldered, but crosstalk test still fails in 1 out of 10 times15:13
wolfspraulmaybe we could also try to not just resolder, but replace U14/U15 with new dram chips? maybe it's a problem in one of the two chips?15:14
aw_wolfspraul, yes, i knew, but reworked board with very unknown condition. if I replace surely I  know that you would say it's probably a 'match' problem potentially from fpga to dram.15:15
wolfspraulif the crosstalk test is fast, it's always a good idea that Sebastien lets it run 500 or 1000 times, whatever is still bearable (say a few seconds or so)15:16
aw_so first with a routinely s/w (most likely reliable test) be provided, then things will be clear then.15:17
wolfspraulalright I'm out, late15:17
wolfspraulgood news on the bootup bug - thanks a lot for the solid work!15:18
aw_thanks all here...eastern world is sleepy...;-)15:20
Fallenouwhat is this crosstalk bug ? (don't understand crosstalk meaning)15:36
lekernelFallenou: crosstalk is when current or voltage in one signal induces an unwanted voltage in a nearby track because of high frequency effects15:55
lekernelone of the MM1 board from the RC2 batch appears to have such a problem on the DDR data lines - or, at least, the test detects it as such15:56
lekernelit could also be DC "crosstalk" like a short circuit :)15:57
Fallenouok understood16:28
lekernelcommit 74897bc755ddcb5ff67a91570c83e910ed950c7c16:40
lekernelAuthor: rth <rth@138bc75d-0d04-0410-961f-82ee72b054a4>16:40
lekernelDate:   Thu Aug 5 15:39:54 2010 +000016:40
lekernel    PR 4518916:40
lekernel    Unbreak ia64 build after last dwarf2out.c change.16:40
lekernel    16:40
lekernel    git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@162917 138bc75d-0d04-0410-961f-82ee72b054a416:40
lekernel74897bc755ddcb5ff67a91570c83e910ed950c7c is the first bad commit16:40
lekernelhow is the frame pointer supposed to work on lm32?16:53
lekernelhttp://gcc.gnu.org/ml/gcc/2003-10/msg01008.html of course no answer...16:55
lekernelhmm... it seems Jon's patch fixed the dwarf issue, then we run into another one16:56
lekernelis it possible to tell git-bisect not to touch some files?16:57
lekernelmaybe I can hack that into the git bisect run script... rewrite the files, run the test, restore the files :)16:58
lekernelwhat a mess...16:58
Fallenouso this is the patch git bisect points out lekernel ?17:01
Fallenouthe on you pasted17:01
lekerneldwarf issue that Jon fixed (confirming that atm)17:07
lekernelhow can you test the return value of the last command in bash?17:07
lekernelie if return value != 0 do something; exit17:08
lekernelyeah, Jon's patch fixed the dwarf related crash, then someone else broke LM32 again17:10
lekernelso I need git bisect to apply that patch everytime now17:10
larsclekernel: $?17:11
larscis last return value17:11
lekernelif $?; do17:11
lekernelecho prout;17:11
lekernelthis doesn't work17:11
larscif [$? -ne 0]; then echo foo; fi17:12
larscwith extra space after the [ and before the ]17:13
lekernelphew, thanks :)17:13
lekernelI always spend 10 min figuring out that damn syntax everytime I need a bash script17:13
lekernelBisecting: 2444 revisions left to test after this (roughly 11 steps)17:18
lekernelhere we go again...17:18
lekernelwe should set up a server that tests lm32 weekly... this would prevent the lm32-breaking commits from accumulating17:19
lekernelpeople like Ulrich Drepper probably love to break LM32, since this annoys "minorities" that don't help him in his "fight against Microsoft and Apple"17:20
larscdoing automated regular testing sounds like a good idea, but i guess you need go testcases then17:23
wpwraklekernel: (testing $?) how about    command || exit    ?17:39
lekernelI have two commands17:40
lekernelcommand || exit can also be replaced with set -e17:40
wpwrakcommand1 && command2 || exit17:40
lekernelbut I need to do something (in this case, revert the patch so git bisect doesn't stop) before exiting17:40
wpwrakah, command || { cleanup; exit; }17:41
lekernelmaybe next time :)17:41
wpwrakor  set -e   combined  with trap 0 ...17:41
lekernelanyone ever tried xynth?17:42
lekernellooks interesting17:42
lekernel(the windowing system)17:42
larscnever heard of it before17:43
kristianpaulsame here17:43
Fallenouand wayland ? :p17:44
lekernelwayland sounds like a big mess to get to work on rtems (or even uclinux)17:45
wpwrakin the end, X will win. it always does ;-) it's kinda like street gangs fighting the highlander :)17:46
kristianpaulxynth written i C, nice17:47
larscwpwrak: even keithp says wayland is the future17:47
larscwpwrak: http://linuxconfau.blip.tv/file/4693305/17:48
lekernelfortunately, dinosaurs die sometimes17:48
kristianpaullarsc: wayland share something with linux?17:48
lekerneland X deserves to17:48
lekernellook at ICCCM and the amount of cruft is has accumulated over the ages17:49
larsckristianpaul: what do you mean?17:49
kristianpaullarsc: integration17:49
larscwayland requires kms17:49
lekernelX people can't even get copy and paste to work17:49
kristianpaulhe, GTK v2.4.14 ported to xynth i cant imagige how smooth it feels :-)17:59
lekernelok, xynth isn't convincing17:59
lekernelyou can't even minimize windows17:59
kristianpauli liked this pic http://wiki.gp2x.org/wiki/Xynth18:00
lekernelyeah, but the screenshots basically show _everything_18:01
lekernelthat is the problem18:01
kristianpaulWhy you dont like microwindows?18:02
lekernelok, there is a 3rd lm32-breaking comming18:02
lekernelfuck, that's endless18:02
lekernelmicrowindows is X18:08
lekernelyou can't do anything with it unless you use it's nxlib X-emulation layer18:08
lekernelso it's just one more layer of crap... it's actually WORSE than X18:09
kristianpaulwhitix, interesting18:09
lekernellol, the default background is based on a pic of the university of a rather small city where I used to live18:30
lekernelquite funny to see it transformed in this way :)18:30
lekernelmwalle: seems I fixed the C compiler. shall I merge your linux gcc support patches?19:47
--- Sat Feb 26 201100:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!