#milkymist IRC log for Tuesday, 2012-07-31

wpwraki think that any case where icache needs this is a good moment to seriously think about all the things you're doing wrong ;-)00:12
Jiahi all, is wolf gang here the creator of U-Boot?02:02
wolfspra1lthat's another wolfgang not me and no he is not here02:03
wolfspra1lemail the uboot list02:03
JiaOh, I thought is you, so, I was wrong02:05
Action: Jia -> meeting02:05
wolfspra1lwhat happened to your supposed lm32/gcc patches?02:06
wolfspra1lit somehow went nowhere it seems?02:06
Jiawolfspra1l: I'm analyzer the code...03:21
Fallenoumorning06:23
wolfspra1lgood morning06:29
lekernelwolfspra1l: there were problems with the patch11:21
wolfspra1lFallenou: hi there ;-) I have a quick question12:13
wpwrakFallenou: btw, just curious: did you check the maximum clock you can run the FPGA at with the MMU ? if yes, is it the same as without MMU or is there some loss ?12:13
wolfspra1lwhen you work with the MMU, do you synthesize the full milkymist soc, or just some cores you need to work on the mmu?12:13
wolfspra1loops werner and me in sync ;-)12:13
wpwrakgreat minds type alike (-:C12:14
Fallenouwpwrak: recently I haven't checked12:15
Fallenoubut each time I checked it did not change the frequency12:15
wpwrakkewl. also with a complete system ?12:16
Fallenouhummm nop ^^12:16
Fallenouit's been some time since I last compiled a complete SoC12:16
Fallenouwolfspra1l: wpwrak : building a complete SoC takes 25 minutes, I usually build a small one which takes only 8 minutes :)12:17
wolfspra1lhow much of the total do you roughly work with regularly?12:17
wolfspra1lso only a small fraction - leave all unnecessary cores out?12:17
wolfspra1lsure, I understand. makes sense.12:17
Fallenouyes I only take necessary cores12:17
FallenouI only take lm32 + the minimum12:18
Fallenousince I'm only working on lm3212:18
Fallenouhttps://github.com/fallen/milkymist-mmu/blob/mmu/boards/milkymist-one/rtl/setup.v12:18
Fallenouhere is what I disabled12:18
wolfspra1lgot it - thanks!12:19
Fallenouno ethernet, no usb, no ac97, no pfpu no tmu12:19
Fallenouetc etc12:19
Fallenougot a meeting, bbl12:19
wpwrakregarding the clock, do you synthesize for a specific target clock or does the synthesis tell you what maximum clock you could use ? i.e., if the limiting element wasn't the core but some peripheral, and you remove that peripheral, would you notice that you could go faster ?12:20
larscboth12:40
larscsort of12:40
wpwrak;-)12:42
larscyou give a target frequency but you also get the max path delay after the synthesis12:42
larscso if e.g. a path doesn't meet the timing requirements you could try to eliminate it12:43
Fallenouremoving cores reduces occupation of the fpga12:43
Fallenouit changes the routing and maybe length of path12:44
wpwrakFallenou: so did you check the max path or just that the target frequency wasn't violated ?12:44
wpwrakFallenou: and yes, the question is whether it mattered that there was more room in the FPGA12:45
wpwraklarsc: i suppose the synthesis just produces an error if it can't meet the target frequency ?12:45
larscwpwrak: that's optional12:45
larscif you want to you can let it ignore the error12:46
wolfspra1lwelcome to the wonderful binary world of fpgas :-)12:46
wpwrakheh :) seems consistent with other serious problem reports i've experienced. "oh, it's not gonna work, but don't worry, we'll go ahead anyway"12:46
wpwrakwolfspra1l: naw, that's just dubious tools.12:48
wolfspra1lnot really as there are a lot of margins in these calculations12:48
wpwrakprobably because they're so slow, they try to make the most of a run. thus all errors become warnings. of course, that in turn means that you may overlook problems, needing more runs.12:49
wpwrakwell, could also be that12:49
wolfspra1lso at some point if you want to max out something you have to calculate yourself anyway, and the tool needs an option for you to override its internal logic/math12:49
wpwrakoverclocker's paradise :)12:49
larscabother issue is that you may overlook the important warnings under all those unimportant warnings.12:53
wpwrakyeah, that's a rather large issue12:53
wpwraki wonder if the amount of warnings we get on M1 is "normal" or if it's just the result of extreme sloppiness12:53
larscwell you get warnings for every signal that's optimized away, e.g. because it is const12:54
wpwrakat least if this was C, the programmer would deserve some serious spanking :)12:54
wpwrakis this a warning that's ever of real interest ?12:55
wpwrakand if not, can it be turned off ?12:55
larscmaybe12:55
wpwrak:)12:57
Fallenouwpwrak: for my small SoC with very few cores the timings are met12:57
Fallenoubut this does not mean I meet timing on complete SoC12:57
wpwraksomething worth finding out one day. maybe run a full build before going to bed some day :)12:58
Fallenouyes sure13:01
larscmwalle: thanks. does your qemu/master build for you?19:00
mwallelarsc: mh, doenst it work for you?19:23
mwalle(havent tried a clean build)19:24
mwallewpwrak: Fallenou: (cache inhibit bit) to overcome the "split the memory in cachable and non cachable addresses"19:24
mwallelarsc: works for me with ../qemu/configure --target-list=lm32-softmmu --audio-drv-list=alsa,oss --prefix=/home/mw/local19:27
mwalle$ git rev-parse HEAD19:29
mwalle63e5885478b8e4502e86c9ac8850da9e633b77fa19:29
larscmwalle: hm seems to work now, no idea why it wouldn't before19:39
larscwell, works is realtive. I get "./qmp-commands.h:3: error: expected identifier or ( before { token" now, but I got the same error in origin/master before as well19:40
larscmwalle: I think there is still a bug somewhere. It doesn't fall behind. But when I press left I get [DD while I would expect to get \x1c[D19:52
larscor is this a bug in the console driver?19:52
larscyeay, so in the driver we ack stat before we read the character20:13
larscfunny moving that after we've read the char breaks rx20:16
larscor tx for that matter20:16
larscI've moved the qemu_chr_accept_input to when we read the rx register, that seems to do the trick, no idea whether it is the right fix though20:17
mwallelarsc: reading the RXTX regisgter?20:25
larscyes20:26
mwalledidnt work for me, because 'uart_can_rx' will still return 020:26
mwallebecause the event wasnt acked20:26
larscbut in the driver we ack the event before we read the register20:27
mwallewell...20:27
mwalle;)20:27
larscand acking it afterwards breaks tx20:28
mwalletx?20:29
larscyes20:29
larscThe last 100 or so characters are missing20:29
mwallebtw are you talking about the bios driver or flickernoise├č20:30
larsclinux20:30
mwalleah *g*20:30
mwallebut why should acking the event register break tx?20:31
larscqemu sets the STAT_TX_EVT flag uppon writing the RXTX register20:31
larscso if we clear the flag after writing the register we don't get a interrupt20:32
larscdon't get the next interrupt20:32
mwallelarsc: (compile error) did you clean up (or removed the build dir if you build out of tree)?20:32
larscmwalle: I did make clean and git clean -df20:32
mwallestrange20:33
mwallelarsc: ah so its the same code path for rx and tx?20:33
larscyes20:34
mwalleshouldn't it be, rx char -> irq -> read char -> clear rx event, clear tx event -> tx char -> wait for irq?20:35
larscmaybe20:35
larscfor the real hardware it shouldn't matter, since there is no handshaking20:35
mwallemh?20:36
larscon the rx path the bit gets set when we recevice a new character20:36
larscand we'll get a overflow no matter what20:37
larscbtw. you wrote that driver ;)20:38
mwalleyes, but i guess you would get the same behaviour if the h/w would assert the event at the same time the register is written20:39
mwalleyeah, so it must be full of bugs ;)20:39
mwallelarsc: btw do git-clean respect gitignore?20:39
mwalletry git clean -dfx20:40
larsci'll just to read status; receive char if RX_EVT is set; clear status; write char if TX_EVT was set20:40
larscthat should work with the current qemu and doesn't have any additional overhead20:41
mwallelarsc: yep that should do the trick20:45
larscgit clean -xdf solved the compile issue20:47
GitHub54[linux-milkymist] larsclausen pushed 1 new commit to master: http://git.io/FOb0YA20:50
GitHub54[linux-milkymist/master] serial: milkymist_uart: Fix IRQ issues with QEMU - Lars-Peter Clausen20:50
mwallelarsc: seems like two commits to me ;)20:54
larsci can't follow20:55
larscdid you drink to much and see double?20:56
larsc:p20:56
mwallehttps://github.com/milkymist/linux-milkymist/commit/c1499b123c31d726e9195ad6d4fb6efdcbcce6a720:56
larscah20:57
mwallethere is the fix and some gpio stuff20:57
mwallemilkyio, nice ;)20:57
larsclala20:57
larscnobody pulled yet?20:57
mwallena, force push ;)20:57
mwallebtw you should remove the comment20:58
mwalleor at least split it20:59
mwalleanybody read "the soul of a new machine" by kidder?21:00
GitHub113[linux-milkymist] larsclausen force-pushed master from c1499b1 to 7d61df4: http://git.io/-IOmgg21:04
GitHub113[linux-milkymist/master] serial: milkymist_uart: Fix IRQ issues with QEMU - Lars-Peter Clausen21:04
GitHub47[linux-milkymist] larsclausen force-pushed master from 7d61df4 to 6b3e3a9: http://git.io/-IOmgg21:07
GitHub47[linux-milkymist/master] serial: milkymist_uart: Fix IRQ issues with QEMU - Lars-Peter Clausen21:07
--- Wed Aug 1 201200:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!