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