lekernel changed the topic of #milkymist to: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs :: Something to do? https://github.com/milkymist/bugs/issues
hypermodern has joined #milkymist
<Fallenou_> mwalle: why would you replace the DCM by a PLL in system.v ? *trying to understand the patch*
<Fallenou_> to generate more different clock frequencies ?
voidcoder has joined #milkymist
<wolfspraul> Fallenou_: maybe you already saw this, but I was also reading the patch now and at the top it says "use two chained PLLs to generate all needed clocks. this makes it possible to switch the USB clock to 72mhz"
<wolfspraul> but reading through line by line is still above my head... learning :-)
rejon has joined #milkymist
rejon has joined #milkymist
sb0 has joined #milkymist
hypermodern has quit [#milkymist]
voidcoder has joined #milkymist
<wpwrak> i find the one entitled "Switch USB clock to 72MHz" a bit scary. particularly the softusb_rx.v changes are far from obvious
<wpwrak> Fallenou_: btw, does your recent success mean that you found the problem that prevented the MMU from working ?
sb0 has joined #milkymist
hypermodern has joined #milkymist
mumptai has joined #milkymist
roh has joined #milkymist
voidcoder has joined #milkymist
sb0 has joined #milkymist
Gurty has joined #milkymist
<mwalle> wpwrak: yeah there is a need for some better commit messages ;)
<mwalle> Fallenou_: you cant generate the 72mhz from one dcm using two plls you are able to generate all required clocks inside and outside the system, apart from the vga pixel clock
<mwalle> and iirc xilinx doesnt recommend chaining two dcms
wolfspra1l has joined #milkymist
kilae has joined #milkymist
<Fallenou_> wolfspraul: yes I saw the commit message, I was trying to understand why switching from DCM to PLL, just curious
<Fallenou_> 06:57 < wpwrak> Fallenou_: btw, does your recent success mean that you found the problem that prevented the MMU from working ? < yes, this commit fixed the problem of crashing the whole SoC : https://github.com/fallen/milkymist-mmu/commit/c73e8e802bd6d79299f737777b828ccc1e32aa1c
<Fallenou_> mwalle: oh ok, got it !
<wpwrak> Fallenou_: (fixed) congratulations !
<Fallenou_> maybe there is more bugs, but at least those 15 test cases are passing for now :)
<Fallenou_> so I must be making at least some progress :)
<Fallenou_> if someone wants to write more tests, he is welcome !
<Fallenou_> I would like to go on to the next chapter now
<Fallenou_> i.e generating exception when dtlb miss, fix the mapping and then go back to the code
<Fallenou_> but test cases can still be written as a background task
<Fallenou_> it's pretty easy, just doing enable_dtlb(); some normal instructions using memory loads and stores disable_dtlb(); and check if the result is correct
<mwalle> wpwrak: once the 72mhz usb has been verified to be working (or at least doesnt introduce any regressions ;) ) i'll elaborate on the commit message
<mwalle> for now: those who are intereseted in the changes, please refer to http://www.usb.org/developers/whitepapers/siewp.pdf :)
<Fallenou_> I don't have my M1 nor my korg nanocontroller with me right now so I can't test
<Fallenou_> but next week maybe, if someone havn't tested before
voidcoder has joined #milkymist
<wpwrak> hmm, the LV3 seems unhappy
<wpwrak> doesn't enumerate
<wpwrak> but perhaps i need to update softusb as well ? let's see ...
rejon has joined #milkymist
voidcoder has joined #milkymist
<mwalle> wpwrak: mh, the timer offsets were changed from 0x11 -> 0x20
<mwalle> my bitstream use 0x20 as base offset
<mwalle> but that should affect all devices, not just the lv3
<wpwrak> the lv3 is the only one i had connected :)
<wpwrak> rebuilding things now ...
wolfspra1l has joined #milkymist
<wpwrak> interesting. FN completely deconfigured itself after updating
<wpwrak> and usb debug doesn't make a sound
<wpwrak> mouse doesn't work either
<wpwrak> mwalle: can you also upload an image of the FN your're using ?
aeris- has joined #milkymist
kyak_ has joined #milkymist
<mwalle> wpwrak: i'm just using the bios ;)
<mwalle> wpwrak: does the bios detect the mouse?
<wpwrak> hmm .. i didn't even build the bios ...
<wpwrak> phew/.. LOTS of warnings when compiling the bios
<wpwrak> of course, all of the "old-style function definition" kind
<mwalle> mh shouldnt that be fixed?
<wpwrak> bios does get debug messages from usb. so far, so good
<wpwrak> but that's about all that works
<mwalle> wpwrak: ahh i guess flickernoise/rtems use its own softusb headers?
<wpwrak> ah ! i was on a branch. that would explain some things :)
<wpwrak> let's try this again ...
<mwalle> wpwrak: ah, forget my last sentence, the changes are softusb internal ;)
<wpwrak> much better. MIDI and mouse detected
<mwalle> puh :)
<wpwrak> now i only lost the FN configuration, for some obscure reason
wolfspraul has joined #milkymist
<wpwrak> "unable to open file (permission denied)". interesting
<wpwrak> seems that there's some breakage in rtems-yaffs2 / rtems
<mwalle> sebhub committed some api changes, some time ago, dunno if thats connected
<wpwrak> maybe. or "Change mode of root and lost+found directory"
<wpwrak> but we're running as root, aren't we ?
<mwalle> i guess :)
<wpwrak> well, let's change the mode back ...
<wpwrak> still no permission to even load a patch:-(
<wpwrak> and of course, if i go to an earlier version, the build fails due to rtems api breakage. oh, the joy ...
<mwalle> wpwrak: cant you switch rtems/fn to the last version tag?
<wpwrak> which version tag ?
<mwalle> the last soc release?
<wpwrak> hmm ... where does that information live ...
<mwalle> 'git tag'
<wpwrak> and then ? 4.9.6 ?
<wpwrak> naw. then already our patch set fails
<mwalle> mh the daily works, doesnt it?
<mwalle> git://git.rtems.org/rtems.git master 8c6608bd1b1eed2a956f4268ea03fa0e05ec9a94
<wpwrak> hmm. these are the versions i have. daily therefore shouldn't work. let's see ...
<wpwrak> yeah, same behaviour from FN. good. so it's not my fault ;-)
<wpwrak> but USB looks very good. also the endless stream of errors is gone.
<sb0> ok, good for commit then?
<wpwrak> i think we can risk it :)
<Fallenou_> nice !
<wpwrak> if anything blows up, we can revert anyway. and it's not as if "bleeding edge" would always work - i.e., right now, it doesn't, due to the rtems/yaffs issue. annoyingly, just changing the permissions back didn't do the trick. so i'll have to find a set of versions that still works ...
<sb0> yeah, this regular rtems breakage is quite annoying
<mwalle> wpwrak: (streams of error) compared to the 48mhz variant?
<wpwrak> mwalle: compared to softusb before your changes. i didn't test between your first (assignments) and second set (72 Mhz)
<mwalle> wpwrak: the assignments shouldnt have any effect on the bitstream
<mwalle> sb0: but please let me cleanup the patches before you commit them ;)
<mwalle> sb0: and should i pin the pll by constraints? i dont know how i can find out the position/name/whatsoever
<sb0> ok, time to go to the next destination anyway
<sb0> yes, lock the PLLs. you can find the site names by opening the .ncd file in FPGA Editor
<mwalle> sb0: ah one more, seems like the dcm implicitly inferred an IBUF on clk50, because the net was named clk50_IBUF in the constraints
<sb0> or using xdl
<sb0> yes
<sb0> net names are messy
<sb0> again you can find the one that the tools picked with fpga editor or xdl
<mwalle> for the pll i had to infer it explicitly
<sb0> or even directly in the netlist
<mwalle> kk, will try
<mwalle> the fpga editor wont start on my machine, i'll find out ;)
<sb0> yes, it's a common problem
<sb0> xdl has fewer bugs
<sb0> bbl
<mwalle> bye
<kristianpaul> wpwrak: having a chipscope floss client will resolve your problems about getting signals easilly out of the fabric for debugging porpuses
<kristianpaul> if is that what i undertood correclty you require from verilog
kyak has joined #milkymist
Thorn__ has joined #milkymist
Thorn__ has joined #milkymist
voidcoder has joined #milkymist
bhamilton has joined #milkymist
elldekaa has joined #milkymist
<wpwrak> kristianpaul: ah, that may be something to look at, yes. anyway, it seems that mwalle already somehow made those errors go away. not having a problem beats having a great plan for solving it ;-)
<wpwrak> it's kinda interesting to note that the autocrap bootstrap of rtems takes about half as long as synthesizing the FPGA. talk about efficient bureaucracy.
<Fallenou_> it's horrible, the bootstrap
<Fallenou_> fortunately, you don't have to bootstrap everything if you just changed a few files in a few directory
<Fallenou_> a few makefiles/configure
<kristianpaul> as long indeed
<wpwrak> yeah, but if you jump around in the history, changing who knows what ... :-(
<kristianpaul> thats why i dont use rtems atm :=
<kristianpaul> and use a minimal SoC with cores just i need to the problem trying to solve
<kristianpaul> that way synthesis dont get long than 15m
<kristianpaul> at least..
<Fallenou_> hehe
<Fallenou_> 8 minutes for me ;)
<Fallenou_> I disactivated almost everything
<kristianpaul> oh wow
<Fallenou_> and Xst is running inside a debian virtual machine
<kristianpaul> form setup.v or something else?
<kristianpaul> wow
<Fallenou_> yes setup.v
<Fallenou_> oh, I kept memory card, I could remove it
<Fallenou_> it could be even faster
<Fallenou_> I kept FML meter I didn't know if it was mandatory
<kristianpaul> i remenber only mandatory is memtest in some cases
voidcoder has joined #milkymist
<kristianpaul> in the milkyminer i just kept FML, sysctl, sdram stuff and lm32 basically
<wpwrak> FML is very optional
<wpwrak> and it's a convenient source for a CSR address ;-)
<Fallenou_> is it really hard to add 1 bit to csr addresses ?
<wpwrak> dunno. maybe not. would mean editing lots of places, though
<Fallenou_> yes I guess
<larsc> you can decrease the per block space
<Fallenou_> and hard to debug if it synthetizez and crashes the soc
<larsc> i think it is 0x4000 currently
<kristianpaul> Fallenou_: is not
<kristianpaul> yes, some editing and replace in the cores
<larsc> which is much more than what is currently used
<wpwrak> hmm, in the led matrix controller, i use 9 address bits. three of them are reserved for geometries we don't use (but which could be selected by changing parameters)
<larsc> 512 registers?
<wpwrak> good news: with the right amount of pinning, things look friendly. including working usb-midi
<wpwrak> at least 256. could be more because it's a matrix. one bit switches between the PWM and the "administrative" bank
<Fallenou_> wpwrak: your ledm.v contains so much things I would not have thought to be "synthetizable" by Xst. it's amazing it works :) like triple arrays [][][], tasks, disable XXX,
<Fallenou_> but it makes the code looks nice
<wpwrak> ;-)
<wpwrak> yeah, i was quite surprised how clean you can make things
<wpwrak> there are still a number of silly oddities that don't seem technically necessary, such as having to name blocks for "disable" (to express my disdain, i thus used "_"), but verilog does seem to have a decent enough set of features for things of medium complexity
<wpwrak> oh, but i also ran into trouble: if you take the handling of "Z" too far, xst falls apart and generates an incorrect system
<Fallenou_> arg :/
<Fallenou_> what does "disable" do ?
<Fallenou_> first time I see it
<Fallenou_> gn8 !
<mwalle> gn8
<wpwrak> it's basically like a "break" or "return" in C
<wpwrak> it exits the block. so instead of if ... a little ... else ... lots of code ... you can just if ... begin ... disable end and leave out the else branch, along with indentation
<mwalle> mh my interrupts for the navre core seems to work somehow :)
<wpwrak> nice :) that's for USB out ?
<mwalle> wpwrak: i'm using the mm as a usb device, so its usb in from my pov
<wpwrak> ah, device mode. interesting.
<wpwrak> so we'll have an alternative to ethernet. well, for things that don't have to be very fast :)
<mwalle> think of another gdb channel (maybe fast this time ;) ..), DFU, mass storage, dunno ;)
<mwalle> gn8
voidcoder has joined #milkymist
Gurty` has joined #milkymist