Topic for #milkymist is now Radical Tech Coalition :: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs
lekernel has joined #milkymist
<Fallenou> yep I added 3 new csr to gnu as
<dvdk> Fallenou: found that out already :)
<Fallenou> hehe you are finding too fast :)
<dvdk> Fallenou: why didn't you just use hexcodes in asm("")?
<Fallenou> where ?
<dvdk> well, there is no need to patch binutils, afaics
<Fallenou> well I could just generate ram.data files directly entering binary
<Fallenou> but I prefer compiling C or assembling asm
<Fallenou> I actually didn't know I could directly put opcodes in hex in asm()
<Fallenou> but it's really more convenient to write instructions rather than opcodes in hex :)
<dvdk> well making it work it's more difficult than i first thought.
<Fallenou> oh I just noticed I havn't pushed the code I'm using to do my tests
<dvdk> you need a fixed register to use so you could do something like "mv r1,%0; .word 0x..hexcode.." and tell GCC via clobber list that "r1" is clobbered.
<Fallenou> oh ok I did it on a different branch "mmu-bios"
<dvdk> BTW i've just added CSR read/write support to the lm32 gforth image i built
<Fallenou> modifying gnu as allows me to do this kind of thing : https://github.com/fallen/milkymist-mmu/blob/mmu-bios/software/mmu-bios/crt0.S
<dvdk> in case you want to test CSRs without having to load firmware over and over
<Fallenou> oh nice job :) thanks !
<Fallenou> (line 133 for the link I posted)
<Fallenou> gotta go running out of battery !
* dvdk would have just used a macro that spits out .word 0x...
<Fallenou> gn8 ! see you tomorrow
<dvdk> night
<dvdk> out of battery: me too :)
wolfspraul has joined #milkymist
<wpwrak_> dvdk: (csrs) you can access them from the FN console
<wpwrak_> dvdk: mdump, medit, etc.
<wpwrak_> dvdk: of course, having that in your forth system is nice, too :)
<dvdk> mpwrak_: that'd be a little bit too high-level?
<wpwrak_> why high-level ? it's just register read/writes
<dvdk> i mean, it's from within RTEMS, with lots of code running concurrently, IRQs enabled etc. Might not be a good idea to mess with the MMU in such an environment
<wpwrak_> ah, i see. yes, for mmu experiments, you probably want to start simple
<dvdk> i mean, in forth I can do stuff like 1234 EBA! and it still runs. try to write EBA from RTEMS :)
<wpwrak_> so you're planning to use forth to (de)bug the mmu ?
<wpwrak_> i don't even know what EBA is ;-)
<dvdk> "exception base address", i.e. start of vector table :)
<wpwrak_> ah yes. i can see how this might lead to tragedy :)
<dvdk> yeah, let's see whether i can help with the mmu stuff. can't wait to get linux running on the mm1
<dvdk> i mean, a real linux
<wpwrak_> you're not alone there :)
* dvdk just forgot something important when disturbed by Mr wpwrak_underscore
<dvdk> hmm, what was it?
wolfspraul has joined #milkymist
<wpwrak_> oh, didn't notice i got underscored
<dvdk> BTW the LM32 cpu nicely survives reading non-existing CSRs. thought that woudl lead to an illegal instruction irq or sth
<wpwrak> most devices probably don't even decode all the address bits
<wpwrak> and since read don't have a side-effects, nothing bad can happen
<dvdk> wpwrak: hmm, with the mdump references above, maybe we're misunderstanding as to what a CSR is? I mean three-letter-acronym collisions etc.?
<wpwrak> thinking of it ... i wonder if one couldn't make them have side-effect, though :)
<dvdk> i'm talking about the intra-cpu registers, no MMRs
<dvdk> but you're right intra-cpu there should be some kind of address decoder, too
lekernel_ has joined #milkymist
<wpwrak> Scopeuk: hmm, you mentioned that you have a trigger-finger. do these pads send control messages ? or notes ?
wolfspraul has joined #milkymist
<wolfspraul> wpwrak: if we are going into R4 layout, should we make it a nice-to-have item to move/rearrange the microsd slot a little so that ubb would fit?
<wolfspraul> I think ubb only extends a few mm, so maybe not much space is needed...
<wpwrak> hmm. lemme have a look
<wpwrak> don't bother ;-)
<wpwrak> in this connector, UBB is upside-down. almost nothing could be done with it in this configuration
<wolfspraul> too crowded?
<wolfspraul> ah ok
<wolfspraul> yes that's true
<wolfspraul> on the bottom of ubb, is that conductive?
<wolfspraul> just looking at it too..
<wolfspraul> looks like a gnd plane, and I see a via going to the bottom side, I think
<wpwrak> yes, correct
<wolfspraul> so the entire bottom side of ubb is conductive?
<wpwrak> yes
<wolfspraul> ok
<wolfspraul> alright, got it. idea doesn't work :-)
<wpwrak> you could make a reverse ubb that has vias for everything, but ...
<wolfspraul> layout can focus on our other 25 objectives :-)
<wolfspraul> no no, I just try to make the most of our R4 layout work
<wpwrak> yeah. they're not going to run out of work :)
<wpwrak> molex don't even specify the vertical clearance of the card above the PCB. i've measured 0.9 mm, which looks about right. maybe you can fit a ribbon cable. but i wouldn't bet on it
<wpwrak> to make something useful for ubb, the connector should be at the board edge. and preferably on the bottom, like in the ben
<wpwrak> but since we already have these nice expansion headers ...
<wolfspraul> sure
<wolfspraul> it was an idea, which doesn't make sense now - done
<wolfspraul> :-)
<wolfspraul> something along the lines of "can an expansion board power the m1?" :-)
<wpwrak> yuck :)
<wolfspraul> ah speaking about power, can dvi-i power an attached monitor?
<wolfspraul> lemme see..
<wpwrak> at long as it draws no more than 50 mA ...
<wpwrak> that's what it is allowed to draw from the +5 V supply on the DVI connector
<wolfspraul> pin 14 = 5V power for monitor when in standby ?
<wpwrak> yes, that kind of thing
<wolfspraul> seems the idea is to only power standby mode?
<wpwrak> hmm, where's adam's nice document when you need it ...
<wpwrak> section 2.2.6, page 15
<wpwrak> 2.2.6.2 even
<wpwrak> 50 mA in standby, 10 mA otherwise
<wolfspraul> hmm, read it
<wolfspraul> but what's the bigger point? I don't understand right now
<wolfspraul> the idea is definitely not that the monitor powers itself from that 5V source
<wolfspraul> so the monitor is supposed to have a second independent power source?
<wolfspraul> but what if some magic new monitor only needs 50 mA total?
<wolfspraul> why should the monitor, under the spec, draw less when powered on than in standby?
<wolfspraul> what if it draws 50 mA all the time (except for being 'out of the spec' then)?
<wpwrak> dunno :)
<wpwrak> i suppose it will get no pudding, for being a bad monitor
<wolfspraul> there must have been some thinking behind this
<wolfspraul> why less in 'normal' op than standby? makes no sense
<wolfspraul> you think a notebook will turn off a monitor that nastily draws 50 mA all the time?
<wolfspraul> that would need extra circuitry to enforce this rule, since it must be able to supply 50mA in standby already - no?
<wolfspraul> and I guess the underlying assumption here is that no monitor will ever be able to operate in normal 'on' with only 50mA
<wpwrak> maybe the idea is to limit the overall power budget on the signal source. if the monitor is off, it doesn't need to generate a signal, so it consumes less power and can give more to the monitor
<wpwrak> but i'd have to work on my telepathic skills to be certain
<wpwrak> and yes, they don't seem to be ready for your 50 mA monitor :)
<wolfspraul> not needing power for not generating a signal seems very far fetched
<wolfspraul> since the system may very well be running full power still, even though the monitor is disconnected or in standby
<wolfspraul> but we are all just guessing, I got the facts already...
<wolfspraul> so the spec says we must be able to provide 50mA over pin 14, and R4 will do that?
<wolfspraul> and I assume R4 can provide that all the time, and will not enforce the "10mA during normal on" rule?
<wpwrak> if you want power, you could always use displayport. there, you have 500 mA at 3.3V, according to wikipedia
<wolfspraul> sure I can imagine that they are moving to integrating power
<wolfspraul> but we do dvi-i now :-)
<wolfspraul> I just try to understand
<wpwrak> the R4 situation is still unclear
<wolfspraul> so our design can provide 50mA on pin 14?
<wpwrak> with just a resistor, not 50 mA at any sensible voltage
<wpwrak> (a 47 Ohm resistor)
<wpwrak> adam is looking for current-limiting circuits
<wolfspraul> ah ok
<wolfspraul> didn't know/follow that that was the issue currently being worked on
<wolfspraul> I just had the "how about power on dvi-i" popping up in my dreams :-)
<wpwrak> i've described a BJT-based current limiter: http://downloads.qi-hardware.com/people/werner/m1/tmp/r142.pdf
<wpwrak> that should work in real life as well. but it can burn quite a bit of power in the transistor if shorted
<wolfspraul> is the led circuit settled now btw?
<wolfspraul> I read some things about choosing the right caps/resistors and how bright the leds could still be...
<wpwrak> from my side it is. dunno if adam will have more questions
<wolfspraul> as long as software is in control, I don't mind more brightness :-)
<wolfspraul> I guess we all do...
<wpwrak> M1r4 will make a nice flashlight ;-)
<wpwrak> wolfspraul: (lattice) so communication has been established, at long last :)
<wolfspraul> yes, a first small string
xiangfu has joined #milkymist
<wpwrak> told you you don't have to give up so quickly :)
kyak_ has joined #milkymist
roh_ has joined #milkymist
sh4rm4 has joined #milkymist
wolfspraul has joined #milkymist
guyzmo has joined #milkymist
rejon has joined #milkymist
<GitHub102> [flickernoise] wpwrak pushed 6 new commits to direct-midi: http://git.io/kDrT9Q
<GitHub102> [flickernoise/direct-midi] compiler/doc: icons for MIDI controls - Werner Almesberger
<GitHub102> [flickernoise/direct-midi] stimuli: raise threshold for range -> button from 1 to 64 - Werner Almesberger
<GitHub102> [flickernoise/direct-midi] stimuli: treat toggle -> button like toggle -> range - Werner Almesberger
antgreen has joined #milkymist
fpgaminer has joined #milkymist
kyak has joined #milkymist
wolfspraul has joined #milkymist
wolfspra1l has joined #milkymist
xiangfu has joined #milkymist
mumptai has joined #milkymist
wolfspraul has joined #milkymist
wolfspraul has joined #milkymist
<xiangfu> wolfspraul, Hi
xiangfu has joined #milkymist
<Fallenou> morning
wolfspraul has joined #milkymist
kilae has joined #milkymist
<kristianpaul> morning
<kristianpaul> shame.. when seting loop2 = 4 not just only par did kept running for 600minutos
<kristianpaul> for saying that ~15000 were not routed and timing was not met..
<kristianpaul> s/ loop2 = 4/ loop2 = 2
* kristianpaul trying loop2 = 4 now
<wpwrak> ah, another day. now, what shall we do with it ? fix the economy ? hmm, maybe later. bring world peace ? boring. eliminate world hunger ? yes, this sounds like a worthwhile plan. first step, breakfast ...
azonenberg has joined #milkymist
<xiangfu> wpwrak, Hi. I have a question about DX2
<xiangfu> wpwrak, I have a USB--> MIDI converter. it have two MIDI port. TX and RX.
<xiangfu> I connect the DX2(midi out) to USB->MIDI(RX port).
<wpwrak> yes ...
<xiangfu> what ever I press the button or turn the encoder. the USB->MIDI get nothing. (there is a LED light on the converter) what ever I do, the LED stay off. never flicker
<xiangfu> is this DX2 broken?
<wpwrak> does the LED normally flicker when there's traffic ?
<wpwrak> and what does the usb-midi connect to, a pc ? or m1 ?
<xiangfu> usb-midi connect to a pc.
<xiangfu> I can sure the usb-midi converter works fine. (test with M1 and LV3)
<xiangfu> You can activate the controller
<xiangfu> The yellow Sys-Mon-LED next to shift is on to signal this mode.
<xiangfu> No midi signals are sent as long as the controller is in this mode. Only the incoming commands via midi-in slot are sent directly to the midi-out.
<xiangfu> ---
<xiangfu> I activate 'the controller's system mode'
<xiangfu> also there is nothing output from midi-out
<xiangfu> (I send midi message to DX2's midi-in by using LV3)
<wpwrak> the DX2 has proper power ?
<xiangfu> yes.
<xiangfu> I tested with build-in battery.
<xiangfu> and tested with a 5V power .
<wpwrak> and if you exit "system mode", is it still silent ?
<xiangfu> (the milkymist power adapter)
<xiangfu> still silent
<wpwrak> maybe try changing FX1/FX2
<xiangfu> how to do that.
<wpwrak> press the button :)
<wpwrak> maybe you have to do it in system mode, then exit back to normal mode
elldekaa has joined #milkymist
<wpwrak> what are you using to monitor it ? midi2osc ?
<wpwrak> because, if you get note events, midi2osc wouldn't print them
<wpwrak> and it seems that note events are most of what that controller sends
<xiangfu> yes midi2osc and the LED on the converter :)
<wpwrak> maybe add a printf on SND_SEQ_EVENT_NOTEON
<xiangfu> nothing output. :(
<wpwrak> hmm. and you did connect it with qjackctl after restarting midi2osc ?
<xiangfu> yes
<wpwrak> and on the M1 it doesn't work either ?
<wpwrak> connected via MIDI
<xiangfu> connect the DX2 to M1 through MIDI cable. donesn't work either :(
wolfspraul has joined #milkymist
<xiangfu> ~~~To choose between two possible setups you have to use the two middle green keys of the FX-
<xiangfu> section and press the shift-key in the system mode:
<xiangfu> -FX1-LED = setup 1 (CC/note-data is sent on channel 16)
<xiangfu> -FX2-LED = setup 2 (CC/note-data is sent on channel 1)
<xiangfu> wpwrak, I also tried this.
<xiangfu> same result. nothing from midi-out :(
<wpwrak> hm, then i'm running out of ideas :-(
<xiangfu> ok. then it's broken :)
<kristianpaul> good loop2 = 4 get ok.. lets try 3 and cross fingers..
<wpwrak> xiangfu: maybe stop midi2osc and qjackctl and run rosegarden. that also has a nice MIDI monitor. maybe it can see something
<xiangfu> wpwrak, download and installing..
<xiangfu> I guess it will not help. since the hardware indicate LED never flicker. :(
<wpwrak> maybe try it first with a known to be good midi device
<wpwrak> yeah, that's suspicious
<wpwrak> i think it's safe to try plugging things in a different order. so maybe try the other port on the DX2. or if this doesn't help, the other connector on the USB-MIDI dongle
<wpwrak> you have a total of four combinations :)
<xiangfu> :) ok. doing that now.
<GitHub130> [flickernoise] xiangfu pushed 1 new commit to master: http://git.io/cTem3g
<GitHub130> [flickernoise/master] Makefile flash: remove useless parenthesis, only reflash regular partition - Xiangfu Liu
<xiangfu> wpwrak, no luck. :(
<xiangfu> and I also tried this with 'mixxx'
<xiangfu> under 'MIDI controllers' . there is a MIDI Learning Wizard.
<xiangfu> no message when I press buttons under DX2.
<wpwrak> hmm, doesn't look good then
<xiangfu> ok. mark as broken. :)
<wpwrak> problem solved :)
<xiangfu> wpwrak, another thing is the my ICON usb midi controller also not working under latest flickernoise(mater branch)
<wpwrak> does uSB work at all ? i noticed that i sometimes get a completely dead usb. a reboot or two usually solve this.
<xiangfu> usb keyboard and mouse works.
<xiangfu> this ICON using most channel 0.
<xiangfu> is the LV3 still works on your side?
<xiangfu> both ICON and LV3 not working under latest 'mater' branch. (latest milkymist and flickernoise repo)
<wpwrak> yes, LV3 works here
<xiangfu> wpwrak, I think I got quiet some not working device now. :)
<wpwrak> but it sometime needs a few reboots
<xiangfu> hmm..
<xiangfu> but I even can't get midi message from MIDI port on m1.
<xiangfu> wpwrak, more infor about ICON: http://en.qi-hardware.com/wiki/Milkymist_One_accessories#MIDI
<wpwrak> yes, that looks right
<xiangfu> now. when I setup the 'vmpk', m1 'MIDI settings' 'Latest active controller' get nothing :(
wolfspraul has joined #milkymist
wolfspraul has joined #milkymist
sh4rm4 has joined #milkymist
wolfspraul has joined #milkymist
<GitHub132> [flickernoise] wpwrak pushed 5 new commits to direct-midi: http://git.io/iGEOgg
<GitHub132> [flickernoise/direct-midi] stimuli, compiler: renamed "toggle" to "switch" - Werner Almesberger
<GitHub132> [flickernoise/direct-midi] compiler/doc: renamed "toggle" to "switch" - Werner Almesberger
<GitHub132> [flickernoise/direct-midi] compiler/doc: changed "MIDIC" to "MIDICC" to match MIDI terminology - Werner Almesberger
kyak has joined #milkymist
DJTachyon has joined #milkymist
kyak has joined #milkymist
<qi-bot> The Firmware build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-20120212-1439/
DJTachyon has joined #milkymist
<kristianpaul> damn timing failure.. http://paste.debian.net/156010/
abushcrafterforg has joined #milkymist
krispaul has joined #milkymist
<Fallenou> I don't get it, my asm volatile (); in main.c bios does not end up in bios.elf
<Fallenou> I can't see it if I do lm32-rtems4.11-objdump -D bios.elf
<Fallenou> I put something like this :
<wpwrak> gcc -S will tell you if it makes it to the assembler output
<Fallenou> it does not end up in main.S
<Fallenou> main.s
<wpwrak> very suspicious
<Fallenou> I would expect gcc to give me at least a warning before deleting my asm volatile poeme :'
<wpwrak> it's not really supposed to ...
<wpwrak> well, try adding a memory clobber. shouldn't make a difference, though
<whitequark> try __asm__ __volatile__
<whitequark> iirc it means "this is REALLY volatile."
<Fallenou> it was working "before" with asm volatile()
<Fallenou> but I was not using any register
<Fallenou> now I use one (r11)
<Fallenou> and I added it to the clobber list
<abushcrafterforg> VJs: Any opinions,notes,thoughts,hints on the state of gnu/linux sound to light dmx control software? for this newbie who is just started reading about it
<Fallenou> let's try __volatile__ and "memory"
<wpwrak> whitequark: afaik, __xxx__ just means xxx but without namespace pollution
<wpwrak> Fallenou: there isn't something like an if (0) before it by any chance ? ;-)
<Fallenou> adding "__" didn't help
<Fallenou> addind , "memory" didn't help either
<Fallenou> wpwrak: hehe no :p
<Fallenou> I will paste all the code
<wpwrak> (memory) yeah, the "volatile" should go the trick
<wpwrak> s/go/do/
<Fallenou> code is ugly sorry about that
<Fallenou> I tried several things
<Fallenou> none worked :)
<wpwrak> more things to check: 1) put a syntax error to see if this is really the file you're compiling. 2) lower the optimization level.
<Fallenou> ok
<wpwrak> are you calling dtlbtest ?
<Fallenou> yes
<Fallenou> and right before modifying the asm code I uploaded the bios to the M1 and the function run
<Fallenou> I could see the two puts()
<wpwrak> change the content of the puts to confirm that what runs really comes from the same source
<Fallenou> a C error makes compilation fail
<wpwrak> hmm. optimization levels next ;-)
<wpwrak> and you may want to be careful with your macros. extra parentheses may avoid surprises
<Fallenou> oh wait ...
<wpwrak> ;-)
<Fallenou> I was searching for "tlb" or "dtlb" in the objdump output
<Fallenou> but it's upper case ....
<wpwrak> heh :)
<Fallenou> ok sorry :)
<Fallenou> thanks !
<wpwrak> but why wasn't it in the asm output ?
<Fallenou> it was there I think
<wpwrak> of did you mis-search there, too ?
<Fallenou> I just didn't see it
<wpwrak> ah :)
<Fallenou> yep ok it's in bios.elf as well, good
* Fallenou was getting crazy
<Fallenou> in a few minutes it's time to either open champaign or put a gun in my mouth
<wpwrak> make it champagne vs. hard liquor. one to celebrate, the other to wash away the frustration :)
<whitequark> alias grep='grep -i'
<Fallenou> whitequark: yep :)
<Fallenou> wpwrak: good point :p
<Fallenou> ok I enter dtlbtest and it spits out : "Star"
<Fallenou> hu mhu m!
<Fallenou> ok removing the "*addr = 0x42;" makes the test print FAILURE instead of crashing the M1
<Fallenou> which proves at least something is going on when mmu is enabled :p
<Fallenou> on/wrong ? :p
<whitequark> heh
<wpwrak> wrONg :)
sh4rm4 has joined #milkymist
<Fallenou> ;)
<Fallenou> ok let's eat a little bit and then back to make this work
kristianpaul has joined #milkymist
<Fallenou> ok it does not even boot this time
<Fallenou> damn it
dvdk has joined #milkymist
<Fallenou> Hi dvdk
<dvdk> hi
<lekernel> Fallenou: I think you should validate things first in simulation before trying to run on FPGA
<dvdk> just trying to compile/synth your -mmu branch
<dvdk> (that is: just started to /try/ to compile it)
<lekernel> first there are lots of things that can go wrong, so it's important to be able to observe/process internal signals
<lekernel> second the synthesis tools are slow
<kristianpaul> argh, come on fpga4fun ant is rtl uart core is non-free :-|
<dvdk> so can we actually run code in the simulated lm32 core?
<lekernel> yes, of course
<dvdk> i.e. is it fast enough?
<dvdk> i mean, simulated as in verilog-simulattion
<kristianpaul> s/ant/and
<lekernel> yes, but the test should be only a few dozen instructions at most anyway
<dvdk> ok, I'd guess it could even run gforth, well let's try that later.
<Fallenou> lekernel: so far I have been doing simulations a lot
<dvdk> Fallenou: mind if i patch your code (bios etc.) to run with standard binutils?
<Fallenou> it seemed to be working pretty well
<Fallenou> so I started on the FPGA
<lekernel> well, if you feel like doing a sim environment with bidirectional uart etc
<Fallenou> dvdk: it's not working yet you are losing your time if you are trying to synthetise it
<Fallenou> dvdk: but you can look at the simulation project, it is starting to have promising behaviours :)
<dvdk> Fallenou: I figured that. just trying to find a spot to start with
<dvdk> (simulation) where?
<Fallenou> this
<dvdk> already had it via google :)
<Fallenou> atm I am working on this, it allows me to see what's going on inside the lm32 cpu
<dvdk> ok, you branched off the full lm32 designs
<Fallenou> to look at wave forms of wires and regs
<Fallenou> I just put the lm32 cpu and sram
<dvdk> what sw are you using for simulation?
<Fallenou> using migen to generate interconnect arbiter etc
<Fallenou> dvdk: I tried to document it, there is a README file
<Fallenou> I am using a modified stripped down "bios"
<dvdk> no bios sourcecode ther?
wolfspraul has joined #milkymist
<Fallenou> the ram.data and bios.bin are provided in the "simulation" project
<Fallenou> but if you want to generate your own end modify it etc you can read README.advanced
<dvdk> i only have ise 13.3 installed here. i guess that's sufficient?
<Fallenou> yes sure
<dvdk> a Makefile
<dvdk> !
* dvdk loves makefiles
<Fallenou> :)
* dvdk hates the ISE toolchain
<Fallenou> if you have ISE installed you can run the simulation within seconds just by reading the README
* kristianpaul follows dvdk
<Fallenou> which will tell you to source a file and do make :)
<dvdk> the ram.data is just for testing, i.e. whatever is in there is ok?
* dvdk already skimmed the readme
<dvdk> ok, i can see the isim gui.
<Fallenou> basically for now I'm just testing the DTLB
<Fallenou> I didn't modify the instruction stage
<Fallenou> one step at a time
<Fallenou> the bios just set r0 to 0, set EBA, and jumps to _crt0 which contains a few tests
<Fallenou> a few memory loads to test that the cpu is working
<Fallenou> which was not the case when I started simulating :)
<Fallenou> and then I add an entry in the DTLB
<Fallenou> and I test if it works
<Fallenou> and by looking at D_ADR_O / load_data / load_q_m store_q_m etc in the wave window
<dvdk> just looked at soc.v
<Fallenou> you can check if it works or not
<dvdk> quite a huge testbench
<Fallenou> soc.v was generated by migen :)
<Fallenou> I stripped it down a little bit that's all
<Fallenou> there was uart and flash at first, I removed it
<whitequark> folks. tomorrow my m1 arrives
<whitequark> what's the work which needs to be done?
<whitequark> ... actually it's "today" already at UTC+4
<Fallenou> 22:46 < dvdk> Fallenou: mind if i patch your code (bios etc.) to run with standard binutils? < you really prefer having unreadable ".word 0xaabbccdd" in the code ?
<Fallenou> instead of readable instructions ?
<dvdk> Fallenou: you could define a gnu as macro to handle that.
kilae has joined #milkymist
<Fallenou> oh ok
<Fallenou> dvdk: well ok it would allow someone so generate code without the head ache of recompiling gnu as :)
<dvdk> Fallenou: that was my motivation. Lower the barrier for people to start hacking
<Fallenou> eventually it will be needed, I think, but for now it's cool if we can lower the entry barrier
<Fallenou> ok awesome !
<Fallenou> I would appreciate and commit it
<dvdk> ok, starting on it. the soc.v still gives me headaches, need something easy to begin with :)
<Fallenou> I barely read it :p
<Fallenou> but I am starting to know by heart lm32_dcache.v huhu
<dvdk> isn't there an easier way to debug the model than to look at the isim plots? like adding a lot of debug output and just reading logs instead?
<kristianpaul> printf
<dvdk> would also allow to add more automatic test-cases.
<dvdk> to look for regressions etc.
<Fallenou> dvdk: yes lekernel suggested that as well
<Fallenou> I am deeply convinced that I could not understand lm32 internal stuff with just adding $display() around
<Fallenou> but by looking at wires
<dvdk> Fallenou: yeah, that's the problem with fully concurernt hdl designs.
<kristianpaul> or understading blocks by blocks
<kristianpaul> ?
<Fallenou> but maybe now that I'm more familiar with the internal behaviour I could maybe add display
<Fallenou> to lose less time
<Fallenou> because yes it's really painfull to read all those wires
<dvdk> what about a gforth debug console into the running simulation? :)
<Fallenou> oh by the way
<Fallenou> I wanted to ask you about gforth
<Fallenou> I am kind of ignorent about this language
<dvdk> Fallenou: yeah, it's like a dead language.
<dvdk> anyways.
<Fallenou> you were saying it could help having a console to debug the mmu
<Fallenou> but, gforth interpreter is code that runs on the lm32 cpu, right ?
<dvdk> but it's low-level and very compact intereter core. can read/write raw memory, define test-cases etc. just from the interpreter console
<dvdk> yes.
<dvdk> (running on the cpu)
<Fallenou> yep
<Fallenou> I think it's safer and maybe easier to just make little bios.bin files
<Fallenou> to test mmu
<Fallenou> because you really control what runs on the cpu
<dvdk> well, wrt to the gforth interpreter core, that's written in assembly (mostly by myself), so I do control what runs. But you're right let's keep it simple.
<Fallenou> you write a few assembly lines, you know what you expect from them, and you can simulate it or run it if you're confident on the fpga
<Fallenou> ok yes you seem to control what you do, sure :)
<Fallenou> but I think I wouldn't :p
<dvdk> ok, going to look at the csr stuff
pablojavier has joined #milkymist
pablojavier has quit [#milkymist]
<kristianpaul> dvdk: your plans with gforth port is just a debug platform for m1?
<kristianpaul> pehaps an alternative and simple bootloader too?
<Fallenou> dvdk: nice ! thank you !
<Fallenou> I think it could be nice to debug things too, but here with the mmu it's really a touchy thing
<kristianpaul> touchy ;)
<Fallenou> even C can screw you :)
<Fallenou> var = value; in C generate a memory load for example, even if var is declared as register
<Fallenou> because value is not "in the opcode", it's stored in a memory section and loaded
<Fallenou> so if you are not carefull you do a memory load, and maybe it was unsafe to do it there :)
* Fallenou doing another synthesis
* kristianpaul reads about uart
<Fallenou> hum weird
<Fallenou> I have flterm running
<Fallenou> if I plug the M1 I can see the uart tx led blinking
<Fallenou> indicating bios is running
<Fallenou> but I don't see anything in flterm
<wpwrak> many things to try :) restart flterm. check if you have more than one ttyUSBn. check dmesg.
<wpwrak> also, does flterm work with the regular system ?
<Fallenou> just one ttyUSB0
<Fallenou> nothing weird in dmesg
<Fallenou> just one flterm
<Fallenou> I did a few make load-bitstream with a custom bitstream
<wpwrak> fuser -v /dev/ttyUSB0 (as root)
<kristianpaul> ah i had see/sufer than before (flterm gone..)
<Fallenou> but I think unplugging power should restore the bitstream
<kristianpaul> j just re-load usbserial and ftdi kernel modules to get it work again
<Fallenou> wpwrak: shows nothing
<wpwrak> not sure how you're loading your bitsteam. i always flash mine.
<Fallenou> OK kristianpaul thank you
<Fallenou> that was it
<Fallenou> rmmod ftdi_sio and usbserial
<Fallenou> and unplug / plug usb cable
<Fallenou> wpwrak: I load it using make load-bitstream from top src dir
<Fallenou> it just sends it to fpga from jtag
<Fallenou> does not put it in flash
<Fallenou> puts(); in bios is asynchronous ?
<Fallenou> when I run dtlbtest from bios it just spits out "Star" and then crash M1
<Fallenou> it should at least print two messages entirely before crashing
<Fallenou> wait, is it OK to write to flash with just *addr = value; from bios ?
<Fallenou> I guess it's locked and I must erase it first etc
<Fallenou> I should test with ram instead of flash :)
<Fallenou> for memory stores
<wpwrak> the write protocol for flash is a little tricky
<wpwrak> not only is it probably locked, but you also have a write enable sequence
<wpwrak> if you have RAM, then it should be considerably easier to use
<Fallenou> OK, I somehow crazyly thought it was taken care of by some magic hardware block somewhere in the soc :p
* Fallenou crazy
<Fallenou> let's go for the RAM then
<wpwrak> naw, you don't want writes to NOR to "automatically" succeed. imagine, one stray pointer ... ;-)
pablojavier has joined #milkymist
pablojavier has quit [#milkymist]
<Fallenou> arglh :x
<Fallenou> yep it's better I agree :)
<whitequark> wpwrak: is the NOR mmapped?
<whitequark> er. stupid question.
<whitequark> obviously yes.
<wpwrak> it's mapped, at physical address 0
<kristianpaul> flash.h tell more about the "partitions"
<Fallenou> damn it
<Fallenou> it does not work either with a ram address
<Fallenou> same "Star" thing
<kristianpaul> try a hello world
<Fallenou> and commenting the asm block which does the store word instruction prevent M1 from crashing
<Fallenou> so it really is this memory store which crashes the M1
<kristianpaul> or not hello world, but not something like bios doing a whole initialization protocol :-)
<Fallenou> kristianpaul : well the bios works
<kristianpaul> ah
<Fallenou> I have the prompt
<Fallenou> I type "dtlbtest"
<Fallenou> it runs the dtlbtest() function
<Fallenou> and then it crashed :)
<Fallenou> crashes*
<Fallenou> the bios is OK
<Fallenou> it's just my mmu which is not :p
<Fallenou> at least it can enter user mode and get back to kernel mode without crashing everything
<Fallenou> if it does nothing while in user mode :p
<Fallenou> let's go back to simultion I guess
dvdk has joined #milkymist
<dvdk> Fallenou: here you are:
<dvdk> when disassembled with objdump -D it now shows
<dvdk> wcsr ???,r1
<Fallenou> hey back
<dvdk> (or just give me write access then i'll just push it; to lazy too create a github clone for myself)
<Fallenou> what's your login on github ?
<dvdk> dvdkhlng
<dvdk> BTW the patch is only for .s files, for GCC inline asm() it'll be a little bit more (ugly) work
<Fallenou> here you go :)
<Fallenou> for the simulation we only need crt0.S , it's perfect !
<Fallenou> thank's
<dvdk> uh, I pulled via https. how do I switch URL to use ssh protocol?
<Fallenou> you can ush via https
<Fallenou> push*
<Fallenou> it will just ask for your github password in the console
<Fallenou> if you really want to use ssh key + ssh protocole just edit .git/config
<dvdk> yeah, now it will ask every time i push :)
* dvdk is editing the .git/config
<Fallenou> for testing on fpga with dtlbtest I'm using massively asm() in main.c
<Fallenou> but recent tests showed that MMU is not ready yet for fpga test :)
<Fallenou> it still needs some love in the simulator
<Fallenou> seems easy to use (your macro)
<dvdk> hmm did the git push do it? can't see the commit on https://github.com/fallen/milkymist-mmu/commits/mmu
<dvdk> yet it says "Everything up-to-date" here
<Fallenou> switch to the mmu-bios branch
<Fallenou> on the github web vie
<Fallenou> w
<Fallenou> and you will see your commit
<dvdk> ah, now i see it
<Fallenou> I use "mmu" branch for verilog devel and modifying real bios to add a nice dtlbtest
<dvdk> ok.
<Fallenou> and mmu-bios branch to do the simulation stuff
<Fallenou> to generate bios.bin and ram.data files
<Fallenou> with the software/mmu-bios/ stripped down version
<Fallenou> containing only crt0.S file
<dvdk> yes makes sense
<Fallenou> so you pushed in the right place :)
<dvdk> in dcache.v it says "IMPORTANT: THIS FILE IS AUTO-GENERATED BY THE LATTICEMICO SYSTEM."
<dvdk> but you still edit it directlry?
<Fallenou> yes
<Fallenou> all of their lm32*.v files are "generated"
<Fallenou> I guess it's their synonym for "copy pasted"
<Fallenou> I don't really know what they mean by "auto-generated"
<dvdk> if it's as ugly as xilinx coregen, i don't want to hear about it :)
<Fallenou> it's I guess it's something like coregen
<dvdk> auto-generation is for people who can't properly factor source-code into libraries
<Fallenou> but the truth is lm32 seems to be quite nicely done and there is plenty of conditional stuff ifdef etc
<Fallenou> and it depends on macros defined (or not) in lm32_include.v
<Fallenou> which IMO should be the only auto generated file
<Fallenou> 00:11 < dvdk> when disassembled with objdump -D it now shows
<Fallenou> 00:11 < dvdk> wcsr ???,r1
<Fallenou> cool !
<Fallenou> Now I know I didn't mofidy binutils for nothing !
<Fallenou> I have a nicer objdump output than you have ;)
<dvdk> but: :)
<dvdk> the full line was this: " d3 a1 00 00 wcsr ???,r1"
<dvdk> so we still have the hexcode :)
<Fallenou> yes yes :p
* Fallenou is just kidding
<Fallenou> ok it seems to generate good opcodes
<Fallenou> at least for the few wcsr I have in crt0.S
<Fallenou> simulation is still the same
<dvdk> i double checked it with known IM reg opcodes
<Fallenou> basically you can see at time 13 680 ns , at the bottom of the wave screen (last line)
<Fallenou> the latest wcsr which enables the mmu
<Fallenou> put it into "user mode"
<Fallenou> you see the "kernel_mode" register drops from 1 to 0 which means going from kernel to user
<Fallenou> then you go back all the way up to the first line of the wave window
<Fallenou> you go forward a little bit when the first line (memadr) shows 0x005c
* dvdk is running the simulation
<Fallenou> and you can see that D_ADR_O has the value 0x1040 which means the mmu correctly swapped the virtual address 0x0040 to the physical address 0x1040
<Fallenou> it corresponds to the crt0.S code line 161 (lw r2, (r0+0x0040))
<Fallenou> I should document all of this
<Fallenou> it's a cache miss so the cache tells lm32_load_stores.v to refill the cache so it puts the refill_address on data path lines (d_adr_o)
<Fallenou> that's why we can see D_ADR_O having the value
<Fallenou> because cache is refilling
<Fallenou> it's more subtile the next time on line 165 , you have to look at the load_data line to see it has loaded the right value from the cache
<dvdk> here kernel_reg is '1' all the time. (at least up to 20us)
<Fallenou> for me it drops down to 0 at 13 680 ns
<Fallenou> hum hum :o
<dvdk> ah, wrong bios.bin?
<Fallenou> maybe
<dvdk> software/bios.bin is ok?
<Fallenou> you have to git checkout mmu-bios && cd software/mmu-bios && make && cp bios.bin ~/your_simulation_directory/
<dvdk> ok.
<Fallenou> then cd ~/simulation_directory && h2a bios.bin > ram.data && make
<Fallenou> you can try h2a bios.bin 1050 > ram.data instead
<Fallenou> to have some padding
<Fallenou> what's the first line of your ram.data ?
<dvdk> perfect, kernel_mode changes at 13680
<Fallenou> :)
<Fallenou> nice !
<Fallenou> our cpu are synchronized
<Fallenou> without ntp
<Fallenou> that's nice
<dvdk> maybe in the LM32_CSR_TLB_CTRL write-access check,
<dvdk> it should be case (csr_write_data[5:1]) or sth to reduce synthesis size?
<Fallenou> oh
<dvdk> (or use don't cares and casz (verilog has these, no?))
<Fallenou> Xst detects it's not used
<Fallenou> or that there is no load
<Fallenou> and should not route it
<dvdk> no, currently it has to check for zero? because the source register has all the bits
<Fallenou> but you're right
<Fallenou> yes it may not be really elegant
<Fallenou> let's only check for meaningful bits
<dvdk> maybe don.t care is cleanest. then Xst can detect and eliminate
<Fallenou> yes but it will force us to write 31'bxxxxx something ?
<dvdk> with 5 bits 2 compares fit into a single lut :) (afair)
<Fallenou> I vote for 5:1 :)
<dvdk> yeah. cleanest
<Fallenou> actually I'm not in the "let's optimize the hell out of it" phase right now, it does not work yet, but since you spotted it
<dvdk> just counting LUTs while reading :)
<dvdk> (no just kidding)
<Fallenou> ahah :p
<Fallenou> isn't it 4:1 ?
<Fallenou> let's save bits
<dvdk> bit 5 was for future upgrades (v2) :)
<Fallenou> hehe :p
<Fallenou> ok let's put 4:1 for now