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