wpwrak | i 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 |
---|---|---|
Jia | hi all, is wolf gang here the creator of U-Boot? | 02:02 |
wolfspra1l | that's another wolfgang not me and no he is not here | 02:03 |
wolfspra1l | email the uboot list | 02:03 |
Jia | Oh, I thought is you, so, I was wrong | 02:05 |
Action: Jia -> meeting | 02:05 | |
wolfspra1l | what happened to your supposed lm32/gcc patches? | 02:06 |
wolfspra1l | it somehow went nowhere it seems? | 02:06 |
Jia | wolfspra1l: I'm analyzer the code... | 03:21 |
Fallenou | morning | 06:23 |
wolfspra1l | good morning | 06:29 |
lekernel | wolfspra1l: there were problems with the patch | 11:21 |
wolfspra1l | Fallenou: hi there ;-) I have a quick question | 12:13 |
wpwrak | Fallenou: 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 |
wolfspra1l | when 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 |
wolfspra1l | oops werner and me in sync ;-) | 12:13 |
wpwrak | great minds type alike (-:C | 12:14 |
Fallenou | wpwrak: recently I haven't checked | 12:15 |
Fallenou | but each time I checked it did not change the frequency | 12:15 |
wpwrak | kewl. also with a complete system ? | 12:16 |
Fallenou | hummm nop ^^ | 12:16 |
Fallenou | it's been some time since I last compiled a complete SoC | 12:16 |
Fallenou | wolfspra1l: wpwrak : building a complete SoC takes 25 minutes, I usually build a small one which takes only 8 minutes :) | 12:17 |
wolfspra1l | how much of the total do you roughly work with regularly? | 12:17 |
wolfspra1l | so only a small fraction - leave all unnecessary cores out? | 12:17 |
wolfspra1l | sure, I understand. makes sense. | 12:17 |
Fallenou | yes I only take necessary cores | 12:17 |
Fallenou | I only take lm32 + the minimum | 12:18 |
Fallenou | since I'm only working on lm32 | 12:18 |
Fallenou | https://github.com/fallen/milkymist-mmu/blob/mmu/boards/milkymist-one/rtl/setup.v | 12:18 |
Fallenou | here is what I disabled | 12:18 |
wolfspra1l | got it - thanks! | 12:19 |
Fallenou | no ethernet, no usb, no ac97, no pfpu no tmu | 12:19 |
Fallenou | etc etc | 12:19 |
Fallenou | got a meeting, bbl | 12:19 |
wpwrak | regarding 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 |
larsc | both | 12:40 |
larsc | sort of | 12:40 |
wpwrak | ;-) | 12:42 |
larsc | you give a target frequency but you also get the max path delay after the synthesis | 12:42 |
larsc | so if e.g. a path doesn't meet the timing requirements you could try to eliminate it | 12:43 |
Fallenou | removing cores reduces occupation of the fpga | 12:43 |
Fallenou | it changes the routing and maybe length of path | 12:44 |
wpwrak | Fallenou: so did you check the max path or just that the target frequency wasn't violated ? | 12:44 |
wpwrak | Fallenou: and yes, the question is whether it mattered that there was more room in the FPGA | 12:45 |
wpwrak | larsc: i suppose the synthesis just produces an error if it can't meet the target frequency ? | 12:45 |
larsc | wpwrak: that's optional | 12:45 |
larsc | if you want to you can let it ignore the error | 12:46 |
wolfspra1l | welcome to the wonderful binary world of fpgas :-) | 12:46 |
wpwrak | heh :) 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 |
wpwrak | wolfspra1l: naw, that's just dubious tools. | 12:48 |
wolfspra1l | not really as there are a lot of margins in these calculations | 12:48 |
wpwrak | probably 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 |
wpwrak | well, could also be that | 12:49 |
wolfspra1l | so 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/math | 12:49 |
wpwrak | overclocker's paradise :) | 12:49 |
larsc | abother issue is that you may overlook the important warnings under all those unimportant warnings. | 12:53 |
wpwrak | yeah, that's a rather large issue | 12:53 |
wpwrak | i wonder if the amount of warnings we get on M1 is "normal" or if it's just the result of extreme sloppiness | 12:53 |
larsc | well you get warnings for every signal that's optimized away, e.g. because it is const | 12:54 |
wpwrak | at least if this was C, the programmer would deserve some serious spanking :) | 12:54 |
wpwrak | is this a warning that's ever of real interest ? | 12:55 |
wpwrak | and if not, can it be turned off ? | 12:55 |
larsc | maybe | 12:55 |
wpwrak | :) | 12:57 |
Fallenou | wpwrak: for my small SoC with very few cores the timings are met | 12:57 |
Fallenou | but this does not mean I meet timing on complete SoC | 12:57 |
wpwrak | something worth finding out one day. maybe run a full build before going to bed some day :) | 12:58 |
Fallenou | yes sure | 13:01 |
larsc | mwalle: thanks. does your qemu/master build for you? | 19:00 |
mwalle | larsc: mh, doenst it work for you? | 19:23 |
mwalle | (havent tried a clean build) | 19:24 |
mwalle | wpwrak: Fallenou: (cache inhibit bit) to overcome the "split the memory in cachable and non cachable addresses" | 19:24 |
mwalle | larsc: works for me with ../qemu/configure --target-list=lm32-softmmu --audio-drv-list=alsa,oss --prefix=/home/mw/local | 19:27 |
mwalle | $ git rev-parse HEAD | 19:29 |
mwalle | 63e5885478b8e4502e86c9ac8850da9e633b77fa | 19:29 |
larsc | mwalle: hm seems to work now, no idea why it wouldn't before | 19:39 |
larsc | well, 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 well | 19:40 |
larsc | mwalle: 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[D | 19:52 |
larsc | or is this a bug in the console driver? | 19:52 |
larsc | yeay, so in the driver we ack stat before we read the character | 20:13 |
larsc | funny moving that after we've read the char breaks rx | 20:16 |
larsc | or tx for that matter | 20:16 |
larsc | I'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 though | 20:17 |
mwalle | larsc: reading the RXTX regisgter? | 20:25 |
larsc | yes | 20:26 |
mwalle | didnt work for me, because 'uart_can_rx' will still return 0 | 20:26 |
mwalle | because the event wasnt acked | 20:26 |
larsc | but in the driver we ack the event before we read the register | 20:27 |
mwalle | well... | 20:27 |
mwalle | ;) | 20:27 |
larsc | and acking it afterwards breaks tx | 20:28 |
mwalle | tx? | 20:29 |
larsc | yes | 20:29 |
larsc | The last 100 or so characters are missing | 20:29 |
mwalle | btw are you talking about the bios driver or flickernoiseß | 20:30 |
larsc | linux | 20:30 |
mwalle | ah *g* | 20:30 |
mwalle | but why should acking the event register break tx? | 20:31 |
larsc | qemu sets the STAT_TX_EVT flag uppon writing the RXTX register | 20:31 |
larsc | so if we clear the flag after writing the register we don't get a interrupt | 20:32 |
larsc | don't get the next interrupt | 20:32 |
mwalle | larsc: (compile error) did you clean up (or removed the build dir if you build out of tree)? | 20:32 |
larsc | mwalle: I did make clean and git clean -df | 20:32 |
mwalle | strange | 20:33 |
mwalle | larsc: ah so its the same code path for rx and tx? | 20:33 |
larsc | yes | 20:34 |
mwalle | shouldn't it be, rx char -> irq -> read char -> clear rx event, clear tx event -> tx char -> wait for irq? | 20:35 |
larsc | maybe | 20:35 |
larsc | for the real hardware it shouldn't matter, since there is no handshaking | 20:35 |
mwalle | mh? | 20:36 |
larsc | on the rx path the bit gets set when we recevice a new character | 20:36 |
larsc | and we'll get a overflow no matter what | 20:37 |
larsc | btw. you wrote that driver ;) | 20:38 |
mwalle | yes, but i guess you would get the same behaviour if the h/w would assert the event at the same time the register is written | 20:39 |
mwalle | yeah, so it must be full of bugs ;) | 20:39 |
mwalle | larsc: btw do git-clean respect gitignore? | 20:39 |
mwalle | try git clean -dfx | 20:40 |
larsc | i'll just to read status; receive char if RX_EVT is set; clear status; write char if TX_EVT was set | 20:40 |
larsc | that should work with the current qemu and doesn't have any additional overhead | 20:41 |
mwalle | larsc: yep that should do the trick | 20:45 |
larsc | git clean -xdf solved the compile issue | 20:47 |
GitHub54 | [linux-milkymist] larsclausen pushed 1 new commit to master: http://git.io/FOb0YA | 20:50 |
GitHub54 | [linux-milkymist/master] serial: milkymist_uart: Fix IRQ issues with QEMU - Lars-Peter Clausen | 20:50 |
mwalle | larsc: seems like two commits to me ;) | 20:54 |
larsc | i can't follow | 20:55 |
larsc | did you drink to much and see double? | 20:56 |
larsc | :p | 20:56 |
mwalle | https://github.com/milkymist/linux-milkymist/commit/c1499b123c31d726e9195ad6d4fb6efdcbcce6a7 | 20:56 |
larsc | ah | 20:57 |
mwalle | there is the fix and some gpio stuff | 20:57 |
mwalle | milkyio, nice ;) | 20:57 |
larsc | lala | 20:57 |
larsc | nobody pulled yet? | 20:57 |
mwalle | na, force push ;) | 20:57 |
mwalle | btw you should remove the comment | 20:58 |
mwalle | or at least split it | 20:59 |
mwalle | anybody 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/-IOmgg | 21:04 |
GitHub113 | [linux-milkymist/master] serial: milkymist_uart: Fix IRQ issues with QEMU - Lars-Peter Clausen | 21:04 |
GitHub47 | [linux-milkymist] larsclausen force-pushed master from 7d61df4 to 6b3e3a9: http://git.io/-IOmgg | 21:07 |
GitHub47 | [linux-milkymist/master] serial: milkymist_uart: Fix IRQ issues with QEMU - Lars-Peter Clausen | 21:07 |
--- Wed Aug 1 2012 | 00:00 |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!