Topic for #milkymist is now Milkymist One, Milkymist SoC & Flickernoise development channel (LLHDL/Antares are welcome too) :: Logs: http://en.qi-hardware.com/mmlogs :: JFDI
sb0 joined #milkymist
mumptai joined #milkymist
gbraad_china joined #milkymist
gbraad_china joined #milkymist
azonenberg joined #milkymist
wolfspra1l joined #milkymist
sh4rm4 joined #milkymist
<wpwrak> hmm, http://www.milkymist.org/updates/2011-11-13/ lacks bios-rescue.bin splash-rescue.raw splash.raw standby.fpg
<wpwrak> may be nice to keep them around even if they didn't change
mumptai joined #milkymist
<wpwrak> kewl. now also the 8 k SOC+BIOS boots.
azonenberg joined #milkymist
sb0 joined #milkymist
<wpwrak> does indeed seem to be the sample clock that's messing things up
<wpwrak> sb0: you have a scope with decent speed, right ?
r33p joined #milkymist
<wpwrak> (decent speed) let's say 50 MHz or better
<sb0> at home? I have a 80MHz analog scope from the 80s
<wpwrak> alright. that'll do :)
<wpwrak> that is, if it has more than just one channel :)
<wpwrak> if you can output the sample clock somewhere, this will let you see where in the waveform you're sampling
<sb0> yes, 2 channels
<sb0> well I have already done a verilog simulation of this and it seemed ok
<wpwrak> yes, i mean in the real waveform.
aeris- joined #milkymist
<sb0> simulations are generally accurate :) want to try deglitch first?
<sb0> hmm.. just got your email
<sb0> want to try sampling 1/4 bit time later?
<mwalle> wpwrak: do you have ise running?
<wolfspra1l> sb0: do you think we should make measurements to verify the analog signal quality of the usb wires?
<wolfspra1l> or you think it's very unlikely that we will find a problem there?
<sb0> I have already examined those signals when the rc1 boards went out (with a simple 12MHz oscillator in the FPGA) and I saw nothing unusual
<sb0> according to Werner's email it sounds more like the FPGA sampling the signal at inappropriate times
<wolfspra1l> ok
<sb0> what about a livecoding mode? where you edit the patch in the OSD layer while rendering it
* sb0 is still digesting wpwrak's email
<wpwrak> mwalle: (ISE) no, not yet
<wpwrak> sb0: the NRZI representation of the incorrect patterns looks like IN, but "stretched"
<wpwrak> so this suggests that too many samples were taken
<sb0> yes, but the same clock is used for TX as well, so if the frequency is wrong you'd get TX problems as well
<sb0> maybe it is currently sampling just near the edge of the signal? and sometimes a wrong sample slips through
<wpwrak> how often do you synchronize the phase of the sample clock ? only at the very first edge of the SYNC ? or also inside the packet ?
<wpwrak> yes, that could also be
<sb0> at each transition
<sb0> so inside the packet as well
<wpwrak> that could explain it :)
<wpwrak> if yuo see too many transitions, your effective sample clock will run faster than the bit clock
<sb0> the sample clock generator is very simple
<sb0> it's just a counter that divides 48MHz by 4
<sb0> and a transition resets it
<wpwrak> that's enough to run too fast :)
<wpwrak> introduce glitches, and voila :)
<sb0> if the transitions are improperly timed, yes
<sb0> or glitches too
<sb0> should we try a deglitcher too?
<wpwrak> for low-speed, does it also run at 48 MHz ? (with a larger offset then)
<sb0> yes, same design, but the counter is larger
<sb0> which makes the wrong sample point theory more plausible than glitches
<wpwrak> that would explain why it doesn't happen at low-speed: you have more room for errors
<sb0> yes
<wpwrak> glitches also mean a wrong sample point. but yes, it's hard to tell the two apart with such a short pattern
<sb0> wpwrak, what about a deglitcher based on deglitched = majority(deglitched, signal, signal_delayed_1_cycle) ?
<sb0> running at 48MHz
<sb0> or majority(signal, signal_d1, signal_d2)
<wpwrak> or just (signal, signal_d1) ?
<sb0> how do you tell a glitch from a legit transition if you have only two samples?
<wpwrak> they both have to be the same :)
<sb0> yes, that's majority(deglitched, signal, signal_delayed_1_cycle)
<wpwrak> but yes, depends on how big your glitches are. and what exactly they look like
<wpwrak> that looks like a filter over 3 cycles. but maybe i just misunderstand
<wpwrak> in any case, what's important is that the deglitching happens before the clock synchronization
<sb0> majority(b1, b2, b3) is the bit value that is the most present in the 3 samples
r33p joined #milkymist
<wpwrak> ah, i see what you mean. yes, looks good
<sb0> with deglitched = majority(deglitched, signal, signal_delayed_1_cycle), deglitched only changes when the two signals are the same and therefore change the vote
<sb0> it's equivalent to updating only when signal = signal_d1
<sb0> wpwrak, want an untested patch to try before I go home?
<wpwrak> if it comes with soc.fpg ... :) otherwise, it'll take longer anyway
<sb0> depends on your bandwidth
<sb0> my plane is in 6:30 hours ...
<sb0> I should have installed ISE on my eee *g*
<wpwrak> ah, 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 ?
<sb0> no
<sb0> there's a FSM that waits for each transition, with a global timeout
<wpwrak> if the SYNC pattern is corrupted (for example, not a SYNC at all), do you abandon the packet ?
<sb0> yes
<wpwrak> or will basically anything that starts with a "0" be accepted as SYNC ?
<sb0> no, it has to have all the SYNC transitions
<wpwrak> (abandon) ah, good
<wpwrak> that explains why i didn't see any worse shifts
<sb0> and the global timeout is just enough for a correct SYNC token
<wpwrak> so each shift is basically a jump of the sample clock in one of eight possible positions
<sb0> so any SYNC messup likely gets the complete packet discarded, unless that packet also happens to contain 0x80
<wpwrak> grr. i just realized that my mail doesn't make sense :)
<wpwrak> wait a minute ...
<wpwrak> just mis-labeling :)
<wpwrak> s/IN/NAK/ :)
<sb0> ah, yes :)
<sb0> I was also wondering
<wpwrak> so .. the BER (Bit Error Rate), if we want to call it this, is about 3000 ppm.
<wpwrak> from this we could calculate the probability of a corrupt packet even passing the CRC check
<wpwrak> about 1:200000 if my estimates are right. still not too horrible for HID and such
<wpwrak> of course for bulk data, the odds go to hell
<wpwrak> naw, should be less. maybe 1:1.3 M
<wpwrak> hmm, 260 M :) still too early to day to do math :)
<wolfspra1l> was work on the NOR corruption finished actually?
<wolfspra1l> I think I will check tomorrow whether Adam is 100% clear on the final proposed rc4 reset circuit, then we should act on that asap
<wolfspra1l> that is - buy parts, design-verify 2 boards in Taipei, send one to Werner
* mwalle could synthesize the soc for wpwrak (ise 13.1 here)
<wpwrak> mwalle: thanks !
<wpwrak> wolfspra1l: (NOR finished) no, and i also still have to run some more extensive tests. well, we can do that after the "official" rework.
<wpwrak> worst case would be that it turns out the rework doesn't help and i just had one of those one-in-a-thousand statistical outliers
<mwalle> mh sebastien left
<mwalle> wpwrak: what patch should i apply now? the one sebastien mailed?
<mwalle> s
<wolfspra1l> hmm
<wpwrak> mwalle: the patch he's still working on (i think :)
<wolfspra1l> but we are reasonably sure that we have a 100% good rc4 plan now?
<wolfspra1l> I 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 Aires
<wolfspra1l> until 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...
<wolfspra1l> is he 100% clear on the final proposed circuit?
<wpwrak> we can be about 99.8% certain that my reset circuit made the NOR corruption go away
<wpwrak> not sure how clear adam is on the final circuit. we discussed only bits. there, we seemed to agree.
roh joined #milkymist
<wolfspra1l> hmm
<wolfspra1l> wpwrak: ok, I will ask Adam tomorrow to write up a final and complete diff from the original rc3
<wolfspra1l> including the latest usb power switch stuff
<wolfspra1l> it would be great if you could sign it off, then Adam tries to rework 2 boards asap
<wpwrak> sounds like a good plan
<wolfspra1l> actually I think you did send some pieces already, just not sure about the latest or final version since it was so much in flux
<wolfspra1l> ok great
<wolfspra1l> thanks!
<wolfspra1l> I want to close this one out :-)
<wolfspra1l> move onto bigger and better things...
<wpwrak> i also don't like spoon-feeding adam too much. he doesn't need that :)
<wolfspra1l> sure, I just want to be clear on the process
<wolfspra1l> otherwise you know how it is, everybody thinks someone else will do something, wait, etc.
<wolfspra1l> but I have a mental plan now, let's see whether it works out
<wpwrak> yes, dining philosophers ;-)
<wpwrak> wolfspra1l: 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.
<wpwrak> so i shelfed it until i have time for a larger redesign
<mwalle> wpwrak: are you interested in a soc.bit with the patch sebastien mailed already applied?
<mwalle> (the old one=
<wpwrak> problems 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 voltage
<wpwrak> mwalle: hmm, i think i'll wait for the new one, thanks :) just shifting the sample point probably won't help
<mwalle> ok so i'll do a make clean now :)
<wpwrak> mwalle: 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 likely
<wpwrak> we can optimize the sampling point later, when the clock is stable. there ought to be a nice gauss curve to fit to :)
sh4rm4 joined #milkymist
<wpwrak> ah, 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 accuracy
<lars_> mwalle: with the new uart core I get sometimes repeated input during tx.
<mwalle> lars_: on real hw and/or qemu?
<lars_> real hw
<lars_> haven't tested in qemu yet
<wolfspra1l> understood [labsw]
<wolfspra1l> we have *LOTS* of stuff in different degrees of finishedness :-)
<wolfspra1l> schhist, brdhist, boom, labsw, atben/atusb, ...
<wolfspra1l> but I think all fine, everything is in good shape and can be reactivated
<wpwrak> yeah, the amount of semi-finished stuff is a bit embarrassing :)
<mwalle> lars_: repeated rx chars while you transmit sth?
<wolfspra1l> no it's ok
<wolfspra1l> we are spread super thin
<wolfspra1l> what can we do
<wolfspra1l> counterweight
<wolfspra1l> nanonote case scans
<wolfspra1l> I could go on :-)
<wpwrak> counterweight is kinda finished :)
<wpwrak> and brdhist has never started. so i'm good there ;-)
<lars_> mwalle: yes. the last received character is repeated
<lars_> just as if the rx irq bit was set again
<wolfspra1l> wpwrak: I think the documentation level on all these things is good, so I am not worried
<wolfspra1l> some are only in conceptual stage, some finished, some in between
<wolfspra1l> for labsw, if we have the nor corruption solved we can shelf it until the next real emergency/use case comes up
<wolfspra1l> of course it would be better to finish those things on the spot, theoretically if we had a real money making company somewhere...
<wolfspra1l> hopefully we can still do that later
<wolfspra1l> good seeds
mumptai joined #milkymist
<wpwrak> labsw 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 :)
<wpwrak> of course, most elements of that would be expensive. labsw is the easy and cheap one :)
<kristianpaul> wpwrak: btw this modification seabastien did to detecte NULL pointers is it working? and how it works?
<kristianpaul> i mean how it handle the expection
<wpwrak> kristianpaul: i haven't tested it yet. but i don't doubt that it works
<kristianpaul> of course
<wpwrak> kristianpaul: 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 time
<mwalle> kristianpaul: i think it generates a bus error if an address within the first 512kb is accessed
<kristianpaul> mwalle: bus error? i tought that kind of errors werent handled either..
<mwalle> DEBA and EBA can be set by yourself (iirc bus error is a debug exception)
<kristianpaul> but interesting
<kristianpaul> i think that explain (acess first 512kb) some hangs i had when using the bios
<kristianpaul> i just need to confirm
<mwalle> kristianpaul: well it isnt exactly a bus error, but sebastien is using that error (and its exception vector) to signal NULL pointer access
<kristianpaul> BTW mwalle, there is a way to use gdb to debug bios and barematal apps for m1 in the real hw?
<kristianpaul> or dint worth ?
<mwalle> should work right now
<mwalle> just load the debug elf binary with your gdb
<kristianpaul> you mean i need add a gdb flag to my makefile and use flterm to load it?
<kristianpaul> then launch a gdb server that connect to serial port ? (wich binary btw?)
<mwalle> kristianpaul: lm32-elf-gdb <elf> then type load in gdb cli
<kristianpaul> mwalle: so i dont need flterm?
<mwalle> just for serial output
<mwalle> use it with the passthrough parameter
<kristianpaul> ok, yes because the thing is my program needs human interacion trouhgt the uart
<mwalle> btw flickernoise is treated as a bare metal application too
<kristianpaul> so is not a problem run gdb and flterm at same time
<kristianpaul> ah ok
<kristianpaul> thats fair :-)
<wpwrak> is the new UART the only difference between "old" and "new" SoC / milkymist+RTEMS+FN that isn't backward-compatible ?
<kristianpaul> lars_: 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?
<kristianpaul> lars_: i'm talking about milkymist port of course
<wpwrak> wolfspra1l: btw, my overall goal in M1 at the moment is to get controls to be generally usable
<mwalle> wpwrak: iirc thats the only one
<mwalle> is anyone usiong reflash_m1.sh with snapshots?
<wpwrak> wolfspra1l: hence MIDI and all that
<mwalle> reflash_m1.sh complains about missing md5sums file if i use it with --snapshot milkymist-firmware-11202011-0004
mumptai joined #milkymist
<lars_> kristianpaul: what is missing?
<kristianpaul> lars_: ls cp vi cat rx and poke ;-)
<kristianpaul> sed !
<kristianpaul> but with those i'm happy
<kristianpaul> and could work
<lars_> i have them
<kristianpaul> why i dont..
<kristianpaul> btw there is a rx equivalent for tx? :-)
<kristianpaul> well i a printf works, just wondering :)
<kristianpaul> lars_: where i can confirm that those commands above are been included in openwrt-milkymist=
<kristianpaul> ?
<lars_> you can mount the image as a loopback locally
<kristianpaul> i meant in the source code for openwrt-milkymist
<kristianpaul> i was using qemu
<lars_> kristianpaul: hm? the source code is standard upstream busybox
<kristianpaul> okay seems i'm in the wrong channel to ask :p
<kristianpaul> lars_: last thingm can you share your .config for openwrt-milkymist ?
<lars_> kristianpaul: http://pastebin.com/dvmk4wwk
<kristianpaul> Thasks ! :-)
<mwalle> lars_: does milkymist-linux/master work for you? i pulled it, cherry-picked the new-uart patch, boot seems to hang at "calibrating delay loop.."
<lars_> mwalle: even in qemu?
<lars_> mwalle: could this be due to the reordered irq numbers?
<lars_> i only tested master with the current soc release
gbraad joined #milkymist
gbraad joined #milkymist
wolfspraul joined #milkymist
<mwalle> lars_: but there is no new uart driver in master?
<lars_> yes
<lars_> i've tested the new uart driver with the new uart core, but not with the milkymist soc
<lars_> at least not all of it
<lars_> mwalle: but i'm pretty sure that it is because of the irq reording
<lars_> getting stuck at 'calibrating delay loop' is always a good indication that there are no timer interrupts
<mwalle> old dts ;)
<mwalle> arg we have to get rid of the asm/hw/ stuff :)
<mwalle> lars_: could you please send me (or me point me to) a working initrd/initramfs?
<lars_> http://metafoo.de/initrd.bin works if you renable mmap support in the kernel
<mwalle> lars_: is sys_mmap2 not working?
<lars_> it is
<lars_> but is is an old initrd
<lars_> but it is
<mwalle> funny, my initramfs is working for qemu but not on the real hw
<mwalle> on real hw it isnt even detected as an initramfs
<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'
<wpwrak> hmm, so "make" now has to re-sythesize ?
<lars_> unfortunately that is probably something rtems isn't able to use
<mwalle> lars_: consider, that the mac address may be emedded into the dts
<lars_> wpwrak: only if something changed ;)
<wpwrak> hmm, kickstarting from repository will be tricky then
<lars_> why?
* mwalle thinks that the dtb should be on a flash partition, but nonetheless autogenerating sounds nice ;)
<wpwrak> because you'll need ISE just to get the build dependencies sorted out
<wpwrak> after applying the uart-interrupt patch, rtems build fails with things like MM_IRQ_UART not being define. who normally provides them ?
<kristianpaul> wpwrak: rtems-milkymist/c/src/lib/libbsp/lm32/milkymist/include/system_conf.h
<wpwrak> oh, rtems itself. interesting ...
<wpwrak> indeed. there it is. thanks ! now .. why doesn't it find it ...
<kristianpaul> missing export RTEMS_MAKEFILE_PATH=/opt/rtems-4.11/lm32-rtems4.11/milkymist ?
<kristianpaul> wich i personally consider ugly (dont ask me why)
<wpwrak> gotta love those paths: ../../../../../../../../c/src/lib/libbsp/lm32/milkymist/../../lm32/shared/milkymist_console/uart.c
<kristianpaul> 0_o
<wpwrak> no, i have it set
<wpwrak> and it should then only not find the things from milkymist.git, not its own headers (i hope :)
azonenberg joined #milkymist
<wpwrak> phew. compiles.
<wpwrak> mwalle: (no --kernel requirement) nice ! :)
<wpwrak> i often just give it /etc/passwd, to make it shut up :)
<mwalle> i've passed /dev/zero :)
<mwalle> and discovered a divbyzero bug ;)
<wpwrak> victory ! it boots again ! with the new soc ! :)
<mwalle> hehe
<wpwrak> mwalle: seems strangely appropriate :)
<mwalle> wpwrak: is gdb still working ? :)
<wpwrak> oddly enough, it seems to, yes
<mwalle> does bt work?
<wpwrak> of course :)
<mwalle> mh
<wpwrak> and medit 1234 5 produces a very satisfying SIGSEGV ;-)
<mwalle> lars_: do you happen to know if the initrd_end includes or excludes the last byte of the actual initrd?
<wpwrak> hmm. would be nice if FN would say something if it segfaults without gdb around
<mwalle> +pointer
<mwalle> wpwrak: mh, i guess fn cant figure out if a gdb is connected
<wpwrak> how does gdb find the segfault ? does FN catch it and tell gdbstub ?
<mwalle> the cpu jumps to DEBA+x which is the gdbstubs exception vector
<mwalle> oh, bus error seems to be a non-debug exception, then PC <- EBA+x
<mwalle> so FN should have some logic which jumps to DEBA+x
<mwalle> we could introduce a variable at some predefined address which tells you if a gdb is connected
<mwalle> iff we can load a memory address with one register (r0)
<mwalle> +from
<mwalle> otherwise you'll destroy some register contents
<wpwrak> how 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 ?
<mwalle> wpwrak: there is no communication between the active program an the gdbstub
<mwalle> the gdbstub is executed instead of the normal program once an exception occurs
<mwalle> that 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 program
<wpwrak> so gdbstub could simply execute the original exception vector if there is no gdb connected ?
<mwalle> wpwrak: yes, but that way you wont be able to connect with gdb once the execption occured
<mwalle> eg post mortem analysis is not possible
<mwalle> sth like "an exception occured blubb blubb, please connect gdb or reset board" message wouild be really helpful :)
<wpwrak> well, gdb could wait, say, 5 second ;-)
<wpwrak> secondS
<wpwrak> but you could also do the post-mortem from an FN exception handler. you'd just have a bit more stack to cover
<wpwrak> for FN, i was thinking more of a register dump and/or stack trace. like a linux kernel oops.
<mwalle> wpwrak: yeah and then jump to gdbstub :)
<wpwrak> yeah, why not
<lars_> mwalle: i would guess that it includes the last byte
<lars_> on the other hand: memset((void *)initrd_start, 0, initrd_end - initrd_start);
<lars_> so initrd_end - initrd_start = initrd_size
<mwalle> lars_: yep, like qemu does, now initramfs images are working :)
<lars_> strange though, that it worked for me
<mwalle> lars_: initramfs or initrd?
<lars_> initrd
<lars_> you are using a compressed initramfs?
<mwalle> i guess there cant be a (fs) check :)
<mwalle> lars_: yep
<wpwrak> and now, bit errors, your soul is mine. bwahaha !
<kristianpaul> (aw
<kristianpaul> ah nice, no more kernel, and yes i had passsed just the word moo and worked too :-)
<kristianpaul> arghh, again i "eat" the namuru_add wire...
<wpwrak> buen provecho ! :)
<kristianpaul> s/add/adr
<kristianpaul> wpwrak: is amazing the wire not defined and xst not generated a error, i guess a warning but come on...
<wpwrak> if it doesn't work, isn't this warning enough ? :)
<kristianpaul> sure but it doesnt work partially, but anyway vimdiff helped a lot :-)
<mwalle> wpwrak: nice script, you could add a "pld reconfigure" at the end of the jtag script
<wpwrak> hmm, i always do a "make boot"
<mwalle> wpwrak: btw is gdb (with new uart) working with ^C for you?
<mwalle> eg cont, ^C
<wpwrak> yup. works fine
<mwalle> wpwrak: without flterm+gdbpassthrough?
<wpwrak> i only tried with flterm
<mwalle> (m1nor) i dont have a makefile with boot target ;)
<wpwrak> good old wernermisc/m1/jtag-boot/ :)
<wpwrak> it's way too much work to reach over to press that button :)
<wpwrak> besides, that may upset the delicate cabling that goes into my M1
<mwalle> what i wanted to say is that i dont want another script :)
<mwalle> imho you load fjmem but you dont unload it ;)
<wpwrak> hmm, you may have a point there :)
<wpwrak> updated
<wpwrak> interesting. when i comment out debug output, softusb has fewer CRC problems
<wpwrak> notabene debug output that is printed after a problem, not while things are still good
<mwalle> gn8