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