#milkymist IRC log for Sunday, 2011-11-20

wpwrakhmm, http://www.milkymist.org/updates/2011-11-13/ lacks bios-rescue.bin splash-rescue.raw splash.raw standby.fpg07:38
wpwrakmay be nice to keep them around even if they didn't change07:38
wpwrakkewl. now also the 8 k SOC+BIOS boots.08:19
wpwrakdoes indeed seem to be the sample clock that's messing things up09:11
wpwraksb0: you have a scope with decent speed, right ?09:11
wpwrak(decent speed) let's say 50 MHz or better09:18
sb0at home? I have a 80MHz analog scope from the 80s09:19
wpwrakalright. that'll do :)09:20
wpwrakthat is, if it has more than just one channel :)09:21
wpwrakif you can output the sample clock somewhere, this will let you see where in the waveform you're sampling09:22
sb0yes, 2 channels09:25
sb0well I have already done a verilog simulation of this and it seemed ok09:25
wpwrakyes, i mean in the real waveform.09:26
sb0simulations are generally accurate :) want to try deglitch first?09:53
sb0hmm.. just got your email09:58
sb0want to try sampling 1/4 bit time later?09:59
mwallewpwrak: do you have ise running?11:15
wolfspra1lsb0: do you think we should make measurements to verify the analog signal quality of the usb wires?11:18
wolfspra1lor you think it's very unlikely that we will find a problem there?11:18
sb0I have already examined those signals when the rc1 boards went out (with a simple 12MHz oscillator in the FPGA) and I saw nothing unusual11:19
sb0according to Werner's email it sounds more like the FPGA sampling the signal at inappropriate times11:21
sb0what about a livecoding mode? where you edit the patch in the OSD layer while rendering it11:36
Action: sb0 is still digesting wpwrak's email11:36
wpwrakmwalle: (ISE) no, not yet11:48
wpwraksb0: the NRZI representation of the incorrect patterns looks like IN, but "stretched"11:49
wpwrakso this suggests that too many samples were taken11:49
sb0yes, but the same clock is used for TX as well, so if the frequency is wrong you'd get TX problems as well11:49
sb0maybe it is currently sampling just near the edge of the signal? and sometimes a wrong sample slips through11:50
wpwrakhow often do you synchronize the phase of the sample clock ? only at the very first edge of the SYNC ? or also inside the packet ?11:50
wpwrakyes, that could also be11:51
sb0at each transition11:51
sb0so inside the packet as well11:51
wpwrakthat could explain it :)11:51
wpwrakif yuo see too many transitions, your effective sample clock will run faster than the bit clock11:51
sb0the sample clock generator is very simple11:52
sb0it's just a counter that divides 48MHz by 411:52
sb0and a transition resets it11:52
wpwrakthat's enough to run too fast :)11:52
wpwrakintroduce glitches, and voila :)11:52
sb0if the transitions are improperly timed, yes11:53
sb0or glitches too11:53
sb0should we try a deglitcher too?11:53
wpwrakfor low-speed, does it also run at 48 MHz ? (with a larger offset then)11:53
sb0yes, same design, but the counter is larger11:53
sb0which makes the wrong sample point theory more plausible than glitches11:54
wpwrakthat would explain why it doesn't happen at low-speed: you have more room for errors11:54
wpwrakglitches also mean a wrong sample point. but yes, it's hard to tell the two apart with such a short pattern11:54
sb0wpwrak, what about a deglitcher based on deglitched = majority(deglitched, signal, signal_delayed_1_cycle) ?11:55
sb0running at 48MHz11:55
sb0or majority(signal, signal_d1, signal_d2)11:56
wpwrakor just (signal, signal_d1) ?11:56
sb0how do you tell a glitch from a legit transition if you have only two samples?11:57
wpwrakthey both have to be the same :)11:57
sb0yes, that's  majority(deglitched, signal, signal_delayed_1_cycle)11:57
wpwrakbut yes, depends on how big your glitches are. and what exactly they look like11:57
wpwrakthat looks like a filter over 3 cycles. but maybe i just misunderstand11:58
wpwrakin any case, what's important is that the deglitching happens before the clock synchronization11:58
sb0majority(b1, b2, b3) is the bit value that is the most present in the 3 samples11:59
wpwrakah, i see what you mean. yes, looks good12:00
sb0with deglitched = majority(deglitched, signal, signal_delayed_1_cycle), deglitched only changes when the two signals are the same and therefore change the vote12:00
sb0it's equivalent to updating only when signal = signal_d112:01
sb0wpwrak, want an untested patch to try before I go home?12:01
wpwrakif it comes with soc.fpg ... :) otherwise, it'll take longer anyway12:03
sb0depends on your bandwidth12:03
sb0my plane is in 6:30 hours ...12:03
sb0I should have installed ISE on my eee *g*12:04
wpwrakah, and how do you test the SYNC pattern ? if you get a partial SYNC, e.g., with the first transition missing, does the packet still make it ?12:07
sb0there's a FSM that waits for each transition, with a global timeout12:11
wpwrakif the SYNC pattern is corrupted (for example, not a SYNC at all), do you abandon the packet ?12:11
wpwrakor will basically anything that starts with a "0" be accepted as SYNC ?12:12
sb0no, it has to have all the SYNC transitions12:12
wpwrak(abandon) ah, good12:12
wpwrakthat explains why i didn't see any worse shifts12:12
sb0and the global timeout is just enough for a correct SYNC token12:13
wpwrakso each shift is basically a jump of the sample clock in one of eight possible positions12:13
sb0so any SYNC messup likely gets the complete packet discarded, unless that packet also happens to contain 0x8012:13
wpwrakgrr. i just realized that my mail doesn't make sense :)12:14
wpwrakwait a minute ...12:14
wpwrakjust mis-labeling :)12:14
wpwraks/IN/NAK/ :)12:16
sb0ah, yes :)12:17
sb0I was also wondering12:17
wpwrakso .. the BER (Bit Error Rate), if we want to call it this, is about 3000 ppm.12:18
wpwrakfrom this we could calculate the probability of a corrupt packet even passing the CRC check12:21
wpwrakabout 1:200000 if my estimates are right. still not too horrible for HID and such12:24
wpwrakof course for bulk data, the odds go to hell12:24
wpwraknaw, should be less. maybe 1:1.3 M12:28
wpwrakhmm, 260 M :) still too early to day to do math :)12:32
wolfspra1lwas work on the NOR corruption finished actually?12:55
wolfspra1lI think I will check tomorrow whether Adam is 100% clear on the final proposed rc4 reset circuit, then we should act on that asap12:56
wolfspra1lthat is - buy parts, design-verify 2 boards in Taipei, send one to Werner12:56
Action: mwalle could synthesize the soc for wpwrak (ise 13.1 here)13:05
wpwrakmwalle: thanks !13:18
wpwrakwolfspra1l: (NOR finished) no, and i also still have to run some more extensive tests. well, we can do that after the "official" rework.13:19
wpwrakworst case would be that it turns out the rework doesn't help and i just had one of those one-in-a-thousand statistical outliers13:20
mwallemh sebastien left13:21
mwallewpwrak: what patch should i apply now? the one sebastien mailed?13:21
wpwrakmwalle: the patch he's still working on (i think :)13:25
wolfspra1lbut we are reasonably sure that we have a 100% good rc4 plan now?13:25
wolfspra1lI think that would move this item pretty much to the top of Adam's priority list, to get those 2 boards fully reworked & verified asap, and 1 sent out to Buenos Aires13:26
wolfspra1luntil now I was under the impression that some bits of wisdom would still come from you before it moves over to Adam, but maybe not...13:26
wolfspra1lis he 100% clear on the final proposed circuit?13:27
wpwrakwe can be about 99.8% certain that my reset circuit made the NOR corruption go away13:30
wpwraknot sure how clear adam is on the final circuit. we discussed only bits. there, we seemed to agree.13:30
wolfspra1lwpwrak: ok, I will ask Adam tomorrow to write up a final and complete diff from the original rc313:38
wolfspra1lincluding the latest usb power switch stuff13:38
wolfspra1lit would be great if you could sign it off, then Adam tries to rework 2 boards asap13:38
wpwraksounds like a good plan13:39
wolfspra1lactually I think you did send some pieces already, just not sure about the latest or final version since it was so much in flux13:39
wolfspra1lok great13:39
wolfspra1lI want to close this one out :-)13:39
wolfspra1lmove onto bigger and better things...13:40
wpwraki also don't like spoon-feeding adam too much. he doesn't need that :)13:40
wolfspra1lsure, I just want to be clear on the process13:40
wolfspra1lotherwise you know how it is, everybody thinks someone else will do something, wait, etc.13:40
wolfspra1lbut I have a mental plan now, let's see whether it works out13:41
wpwrakyes, dining philosophers ;-)13:41
wpwrakwolfspra1l: ah, regarding labsw: i came to the conclusion that it's difficult to make a device suitable for larger numbers based on the current case. specifically, there's not enough room for some connectors that are good and easily available. the ones i use are hard to source and don't have entirely convincing properties.13:54
wpwrakso i shelfed it until i have time for a larger redesign13:55
mwallewpwrak: are you interested in a soc.bit with the patch sebastien mailed already applied?13:58
mwalle(the old one=13:59
wpwrakproblems with the current connectors include that they can be shaken loose from the front panel and that they have a very large area of exposed metal inside that can't be isolated. so if any cable comes loose inside the box, there's a risk of a short to a high voltage13:59
wpwrakmwalle: hmm, i think i'll wait for the new one, thanks :) just shifting the sample point probably won't help14:00
mwalleok so i'll do a make clean now :)14:01
wpwrakmwalle: a bad sample point would explain single-bit errors but not shifts of the remaining pattern. now, the errors i saw could still be explained by single-bit corruptions, but a clock problem seems far more likely14:01
wpwrakwe can optimize the sampling point later, when the clock is stable. there ought to be a nice gauss curve to fit to :)14:03
wpwrakah, and another things to look for would be an algorithm that used the whole information available to determine the clock. i think usb is designed such that you don't need to resync inside the packet. so the SYNC pattern alone should give you enough accuracy14:05
lars_mwalle: with the new uart core I get sometimes repeated input during tx.14:05
mwallelars_: on real hw and/or qemu?14:19
lars_real hw14:22
lars_haven't tested in qemu yet14:22
wolfspra1lunderstood [labsw]14:24
wolfspra1lwe have *LOTS* of stuff in different degrees of finishedness :-)14:24
wolfspra1lschhist, brdhist, boom, labsw, atben/atusb, ...14:25
wolfspra1lbut I think all fine, everything is in good shape and can be reactivated14:25
wpwrakyeah, the amount of semi-finished stuff is a bit embarrassing :)14:26
mwallelars_: repeated rx chars while you transmit sth?14:27
wolfspra1lno it's ok14:28
wolfspra1lwe are spread super thin14:28
wolfspra1lwhat can we do14:28
wolfspra1lnanonote case scans14:28
wolfspra1lI could go on :-)14:28
wpwrakcounterweight is kinda finished :)14:29
wpwrakand brdhist has never started. so i'm good there ;-)14:29
lars_mwalle: yes. the last received character is repeated14:31
lars_just as if the rx irq bit was set again14:31
wolfspra1lwpwrak: I think the documentation level on all these things is good, so I am not worried14:33
wolfspra1lsome are only in conceptual stage, some finished, some in between14:34
wolfspra1lfor labsw, if we have the nor corruption solved we can shelf it until the next real emergency/use case comes up14:34
wolfspra1lof course it would be better to finish those things on the spot, theoretically if we had a real money making company somewhere...14:35
wolfspra1lhopefully we can still do that later14:36
wolfspra1lgood seeds14:36
wpwraklabsw is kinda infrastructure. so that's something everyone doing design verification in the project has. i (still) strongly believe in having a "standard" lab infrastructure :)14:46
wpwrakof course, most elements of that would be expensive. labsw is the easy and cheap one :)14:46
kristianpaulwpwrak: btw this modification seabastien did to detecte NULL pointers is it working? and how it works?14:49
kristianpauli mean how it handle the expection14:49
wpwrakkristianpaul: i haven't tested it yet. but i don't doubt that it works14:49
kristianpaulof course14:50
wpwrakkristianpaul: i think you can set an exception vector (lm32 seems to have a table for that). or just let gdbstub signal it. not sure if gdbstub simply overrides the exception or if you have to choose at build time14:51
mwallekristianpaul: i think it generates a bus error if an address within the first 512kb is accessed14:51
kristianpaulmwalle: bus error? i tought that kind of errors werent handled either..14:51
mwalleDEBA and EBA can be set by yourself (iirc bus error is a debug exception)14:52
kristianpaulbut interesting14:52
kristianpauli think that explain (acess first 512kb) some hangs i had when using the bios14:52
kristianpauli just need to confirm14:52
mwallekristianpaul: well it isnt exactly a bus error, but sebastien is using that error (and its exception vector) to signal NULL pointer access14:52
kristianpaulBTW mwalle, there is a way to use gdb to debug bios and barematal apps for m1 in the real hw?14:53
kristianpaulor dint worth ?14:53
mwalleshould work right now14:53
mwallejust load the debug elf binary with your gdb14:54
kristianpaulyou mean i need add a gdb flag to my makefile and use flterm to load it?14:55
kristianpaulthen launch a gdb server that connect to serial port ? (wich binary btw?)14:56
mwallekristianpaul: lm32-elf-gdb <elf> then type load in gdb cli14:56
kristianpaulmwalle: so i dont need flterm?14:56
mwallejust for serial output14:56
mwalleuse it with the passthrough parameter14:57
kristianpaulok, yes because the thing is my program needs human interacion trouhgt the uart14:57
mwallebtw flickernoise is treated as a bare metal application too14:57
kristianpaulso is not a problem run gdb and flterm at same time14:57
kristianpaulah ok14:57
kristianpaulthats fair :-)14:57
wpwrakis the new UART the only difference between "old" and "new" SoC / milkymist+RTEMS+FN that isn't backward-compatible ?14:59
kristianpaullars_: btw, there is a reason why the busybox for uclinux is kinda limited, i mean really limited shell... so, if is just as simple as enable some configs in the make menuconfig or do i need to search somewhere else?15:01
kristianpaullars_: i'm talking about milkymist port of course15:01
wpwrakwolfspra1l: btw, my overall goal in M1 at the moment is to get controls to be generally usable15:02
mwallewpwrak: iirc thats the only one15:02
mwalleis anyone usiong reflash_m1.sh with snapshots?15:02
wpwrakwolfspra1l: hence MIDI and all that15:02
mwallereflash_m1.sh complains about missing md5sums file if i use it with --snapshot milkymist-firmware-11202011-000415:03
lars_kristianpaul: what is missing?15:14
kristianpaullars_: ls cp vi cat rx and poke ;-)15:16
kristianpaulsed !15:16
kristianpaulbut with those i'm happy15:17
kristianpauland could work15:17
lars_i have them15:17
kristianpaulwhy i dont..15:17
kristianpaulbtw there is a rx equivalent for tx? :-)15:17
kristianpaulwell i a printf works, just wondering :)15:18
kristianpaullars_: where i can confirm that those commands above are been included in openwrt-milkymist=15:20
lars_you can mount the image as a loopback locally15:21
kristianpauli meant in the source code for openwrt-milkymist15:22
kristianpauli was using qemu15:22
lars_kristianpaul: hm? the source code is standard upstream busybox15:35
kristianpaulokay seems i'm in the wrong channel to ask :p15:37
kristianpaullars_: last thingm can you share your .config for openwrt-milkymist ?15:39
lars_kristianpaul: http://pastebin.com/dvmk4wwk15:42
kristianpaulThasks ! :-)15:42
mwallelars_: does milkymist-linux/master work for you? i pulled it, cherry-picked the new-uart patch, boot seems to hang at "calibrating delay loop.."16:22
lars_mwalle: even in qemu?16:28
lars_mwalle: could this be due to the reordered irq numbers?16:37
lars_i only tested master with the current soc release16:37
mwallelars_: but there is no new uart driver in master?18:25
lars_i've tested the new uart driver with the new uart core, but not with the milkymist soc18:26
lars_at least not all of it18:26
lars_mwalle: but i'm pretty sure that it is because of the irq reording18:26
lars_getting stuck at 'calibrating delay loop' is always a good indication that there are no timer interrupts18:27
mwalleold dts ;)18:33
mwallearg we have to get rid of the asm/hw/ stuff :)18:50
mwallelars_: could you please send me (or me point me to) a working initrd/initramfs?18:53
lars_http://metafoo.de/initrd.bin works if you renable mmap support in the kernel18:55
mwallelars_: is sys_mmap2 not working?18:58
lars_it is18:58
lars_but is is an old initrd18:58
lars_but it is18:58
mwallefunny, my initramfs is working for qemu but not on the real hw18:58
mwalleon real hw it isnt even detected as an initramfs18:59
lars_btw. I'm working on something which auto-assigns memory addresses and irq numbers, generates a verilog file and dts from it and embeds the compiled dts into a on-SoC ROM. So no more out-of-date dts'19:00
wpwrakhmm, so "make" now has to re-sythesize ?19:01
lars_unfortunately that is probably something rtems isn't able to use19:01
mwallelars_: consider, that the mac address may be emedded into the dts19:01
lars_wpwrak: only if something changed ;)19:02
wpwrakhmm, kickstarting from repository will be tricky then19:03
Action: mwalle thinks that the dtb should be on a flash partition, but nonetheless autogenerating sounds nice ;)19:04
wpwrakbecause you'll need ISE just to get the build dependencies sorted out19:04
wpwrakafter applying the uart-interrupt patch, rtems build fails with things like MM_IRQ_UART not being define. who normally provides them ?19:05
kristianpaulwpwrak: rtems-milkymist/c/src/lib/libbsp/lm32/milkymist/include/system_conf.h19:08
wpwrakoh, rtems itself. interesting ...19:09
wpwrakindeed. there it is. thanks ! now .. why doesn't it find it ...19:09
kristianpaulmissing export RTEMS_MAKEFILE_PATH=/opt/rtems-4.11/lm32-rtems4.11/milkymist ?19:11
kristianpaulwich i personally consider ugly (dont ask me why)19:12
wpwrakgotta love those paths: ../../../../../../../../c/src/lib/libbsp/lm32/milkymist/../../lm32/shared/milkymist_console/uart.c19:12
wpwrakno, i have it set19:13
wpwrakand it should then only not find the things from milkymist.git, not its own headers (i hope :)19:14
wpwrakphew. compiles.19:22
wpwrakmwalle: (no --kernel requirement) nice ! :)19:23
wpwraki often just give it /etc/passwd, to make it shut up :)19:23
mwallei've passed /dev/zero :)19:24
mwalleand discovered a divbyzero bug ;)19:24
wpwrakvictory ! it boots again ! with the new soc ! :)19:25
wpwrakmwalle: seems strangely appropriate :)19:25
mwallewpwrak: is gdb still working ? :)19:25
wpwrakoddly enough, it seems to, yes19:27
mwalledoes bt work?19:27
wpwrakof course :)19:27
wpwrakand  medit 1234 5  produces a very satisfying SIGSEGV ;-)19:27
mwallelars_: do you happen to know if the initrd_end includes or excludes the last byte of the actual initrd?19:29
wpwrakhmm. would be nice if FN would say something if it segfaults without gdb around19:29
mwallewpwrak: mh, i guess fn cant figure out if a gdb is connected19:30
wpwrakhow does gdb find the segfault ? does FN catch it and tell gdbstub ?19:31
mwallethe cpu jumps to DEBA+x which is the gdbstubs exception vector19:32
mwalleoh, bus error seems to be a non-debug exception, then PC <- EBA+x19:35
mwalleso FN should have some logic which jumps to DEBA+x19:35
mwallewe could introduce a variable at some predefined address which tells you if a gdb is connected19:36
mwalleiff we can load a memory address with one register (r0)19:38
mwalleotherwise you'll destroy some register contents19:39
wpwrakhow does the communication between gdbstub and FN work ? i was imagining gdbstub was operating somehow like a supervisor to the CPU. a bit like jtag. but that's not the case, isn't it ?19:40
mwallewpwrak: there is no communication between the active program an the gdbstub19:41
mwallethe gdbstub is executed instead of the normal program once an exception occurs19:41
mwallethat is the gdbstubs mainloop polls for gdb packets and processes it, once you continue the program/exit gdb control is handed back to the original program19:42
wpwrakso gdbstub could simply execute the original exception vector if there is no gdb connected ?19:43
mwallewpwrak: yes, but that way you wont be able to connect with gdb once the execption occured19:45
mwalleeg post mortem analysis is not possible19:46
mwallesth like "an exception occured blubb blubb, please connect gdb or reset board" message wouild be really helpful :)19:47
wpwrakwell, gdb could wait, say, 5 second ;-)19:47
wpwrakbut you could also do the post-mortem from an FN exception handler. you'd just have a bit more stack to cover19:48
wpwrakfor FN, i was thinking more of a register dump and/or stack trace. like a linux kernel oops.19:49
mwallewpwrak: yeah and then jump to gdbstub :)19:49
wpwrakyeah, why not19:49
lars_mwalle: i would guess that it includes the last byte19:53
lars_on the other hand: memset((void *)initrd_start, 0, initrd_end - initrd_start);19:54
lars_so initrd_end - initrd_start = initrd_size19:54
mwallelars_: yep, like qemu does, now initramfs images are working :)20:06
lars_strange though, that it worked for me20:07
mwallelars_: initramfs or initrd?20:10
lars_you are using a compressed initramfs?20:13
mwallei guess there cant be a (fs) check :)20:13
mwallelars_: yep20:13
wpwrakand now, bit errors, your soul is mine. bwahaha !20:22
kristianpaulah nice, no more kernel, and yes i had passsed just the word moo and worked too :-)21:11
kristianpaularghh, again i "eat" the namuru_add wire...21:37
wpwrakbuen provecho ! :)21:56
kristianpaulwpwrak: is amazing the wire not defined and xst not generated a error, i guess a warning but come on...22:04
wpwrakif it doesn't work, isn't this warning enough ? :)22:05
kristianpaulsure but it doesnt work partially, but anyway vimdiff helped a lot :-)22:15
mwallewpwrak: nice script, you could add a "pld reconfigure" at the end of the jtag script23:00
wpwrakhmm, i always do a "make boot"23:00
mwallewpwrak: btw is gdb (with new uart) working with ^C for you?23:03
mwalleeg cont, ^C23:03
wpwrakyup. works fine23:04
mwallewpwrak: without flterm+gdbpassthrough?23:05
wpwraki only tried with flterm23:06
mwalle(m1nor) i dont have a makefile with boot target ;)23:09
wpwrakgood old wernermisc/m1/jtag-boot/ :)23:10
wpwrakit's way too much work to reach over to press that button :)23:11
wpwrakbesides, that may upset the delicate cabling that goes into my M123:11
mwallewhat i wanted to say is that i dont want another script :)23:11
mwalleimho you load fjmem but you dont unload it ;)23:12
wpwrakhmm, you may have a point there :)23:15
wpwrakinteresting. when i comment out debug output, softusb has fewer CRC problems23:29
wpwraknotabene debug output that is printed after a problem, not while things are still good23:29
--- Mon Nov 21 201100:00

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