lekernel changed the topic of #milkymist to: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs :: EHSM Berlin Dec 28-30 http://ehsm.eu :: latest video http://www.youtube.com/playlist?list=PL181AAD8063FCC9DC
jimmythehorn has quit [Quit: jimmythehorn]
<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 ;-)
Jia has joined #milkymist
voidcoder has quit [Read error: Connection reset by peer]
voidcoder has joined #milkymist
rejon has joined #milkymist
<Jia> hi all, is wolf gang here the creator of U-Boot?
<wolfspra1l> that's another wolfgang not me and no he is not here
<wolfspra1l> email the uboot list
<Jia> Oh, I thought is you, so, I was wrong
* Jia -> meeting
<wolfspra1l> what happened to your supposed lm32/gcc patches?
<wolfspra1l> it somehow went nowhere it seems?
xiangfu has joined #milkymist
stekern has joined #milkymist
jimmythehorn has joined #milkymist
jimmythehorn has quit [Quit: jimmythehorn]
xian9fu has joined #milkymist
xiangfu has quit [Ping timeout: 246 seconds]
<Jia> wolfspra1l: I'm analyzer the code...
jimmythehorn has joined #milkymist
jimmythehorn has quit [Quit: jimmythehorn]
<Fallenou> morning
<wolfspra1l> good morning
Hawk777 has quit [Quit: Coyote finally caught me]
Hawk777 has joined #milkymist
Martoni has joined #milkymist
xian9fu has quit [Quit: Leaving]
xian9fu has joined #milkymist
mumptai_ has joined #milkymist
rejon has quit [Ping timeout: 248 seconds]
rejon has joined #milkymist
voidcoder has quit [Read error: Connection reset by peer]
voidcoder has joined #milkymist
rejon has quit [Ping timeout: 248 seconds]
rejon has joined #milkymist
rejon has quit [Ping timeout: 248 seconds]
rejon has joined #milkymist
rejon has quit [Ping timeout: 260 seconds]
kilae has joined #milkymist
Jia has quit [Quit: Konversation terminated!]
voidcoder has quit [Quit: See you next time]
voidcoder has joined #milkymist
<lekernel> wolfspra1l: there were problems with the patch
rejon has joined #milkymist
voidcoder has quit [Read error: Connection reset by peer]
rejon has quit [Ping timeout: 255 seconds]
<wolfspra1l> Fallenou: hi there ;-) I have a quick question
<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 ?
<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?
rejon has joined #milkymist
<wolfspra1l> oops werner and me in sync ;-)
<wpwrak> great minds type alike (-:C
<Fallenou> wpwrak: recently I haven't checked
<Fallenou> but each time I checked it did not change the frequency
<wpwrak> kewl. also with a complete system ?
<Fallenou> hummm nop ^^
<Fallenou> it's been some time since I last compiled a complete SoC
<Fallenou> wolfspra1l: wpwrak : building a complete SoC takes 25 minutes, I usually build a small one which takes only 8 minutes :)
<wolfspra1l> how much of the total do you roughly work with regularly?
<wolfspra1l> so only a small fraction - leave all unnecessary cores out?
<wolfspra1l> sure, I understand. makes sense.
<Fallenou> yes I only take necessary cores
<Fallenou> I only take lm32 + the minimum
<Fallenou> since I'm only working on lm32
<Fallenou> here is what I disabled
<wolfspra1l> got it - thanks!
<Fallenou> no ethernet, no usb, no ac97, no pfpu no tmu
<Fallenou> etc etc
<Fallenou> got a meeting, bbl
<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 ?
voidcoder has joined #milkymist
<larsc> both
<larsc> sort of
<wpwrak> ;-)
<larsc> you give a target frequency but you also get the max path delay after the synthesis
<larsc> so if e.g. a path doesn't meet the timing requirements you could try to eliminate it
<Fallenou> removing cores reduces occupation of the fpga
<Fallenou> it changes the routing and maybe length of path
<wpwrak> Fallenou: so did you check the max path or just that the target frequency wasn't violated ?
<wpwrak> Fallenou: and yes, the question is whether it mattered that there was more room in the FPGA
<wpwrak> larsc: i suppose the synthesis just produces an error if it can't meet the target frequency ?
<larsc> wpwrak: that's optional
<larsc> if you want to you can let it ignore the error
<wolfspra1l> welcome to the wonderful binary world of fpgas :-)
<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"
sh4rm4 has quit [Ping timeout: 276 seconds]
<wpwrak> wolfspra1l: naw, that's just dubious tools.
<wolfspra1l> not really as there are a lot of margins in these calculations
<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.
<wpwrak> well, could also be that
<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
<wpwrak> overclocker's paradise :)
<larsc> abother issue is that you may overlook the important warnings under all those unimportant warnings.
<wpwrak> yeah, that's a rather large issue
<wpwrak> i wonder if the amount of warnings we get on M1 is "normal" or if it's just the result of extreme sloppiness
<larsc> well you get warnings for every signal that's optimized away, e.g. because it is const
<wpwrak> at least if this was C, the programmer would deserve some serious spanking :)
<wpwrak> is this a warning that's ever of real interest ?
<wpwrak> and if not, can it be turned off ?
<larsc> maybe
<wpwrak> :)
<Fallenou> wpwrak: for my small SoC with very few cores the timings are met
<Fallenou> but this does not mean I meet timing on complete SoC
<wpwrak> something worth finding out one day. maybe run a full build before going to bed some day :)
<Fallenou> yes sure
sh4rm4 has joined #milkymist
xian9fu has quit [Ping timeout: 252 seconds]
stekern has quit [Ping timeout: 250 seconds]
lekernel_ has joined #milkymist
lekernel has quit [Ping timeout: 248 seconds]
stekern has joined #milkymist
lekernel_ is now known as lekernel
kyak has joined #milkymist
kyak has joined #milkymist
kyak_ has joined #milkymist
kyak__ has joined #milkymist
sh4rm4 has quit [Ping timeout: 276 seconds]
kyak has quit [Ping timeout: 240 seconds]
kyak_ has quit [Ping timeout: 248 seconds]
kyak__ is now known as kyak
kyak has quit [Changing host]
kyak has joined #milkymist
kilae_ has joined #milkymist
kilae has quit [Ping timeout: 240 seconds]
sh4rm4 has joined #milkymist
jimmythehorn has joined #milkymist
antgreen has joined #milkymist
kyak has quit [Ping timeout: 260 seconds]
kyak has joined #milkymist
kyak has joined #milkymist
voidcoder has quit [Read error: Connection reset by peer]
voidcoder has joined #milkymist
voidcoder has quit [Client Quit]
voidcoder has joined #milkymist
antgreen has quit [Read error: Connection reset by peer]
mumptai_ has quit [Ping timeout: 248 seconds]
Hawk777 has quit [Quit: Coyote finally caught me]
Hawk777 has joined #milkymist
antgreen has joined #milkymist
Hawk777 has quit [Quit: Coyote finally caught me]
Hawk777 has joined #milkymist
<larsc> mwalle: thanks. does your qemu/master build for you?
jimmythehorn_ has joined #milkymist
jimmythehorn has quit [Read error: Connection reset by peer]
jimmythehorn_ is now known as jimmythehorn
<mwalle> larsc: mh, doenst it work for you?
<mwalle> (havent tried a clean build)
<mwalle> wpwrak: Fallenou: (cache inhibit bit) to overcome the "split the memory in cachable and non cachable addresses"
<mwalle> larsc: works for me with ../qemu/configure --target-list=lm32-softmmu --audio-drv-list=alsa,oss --prefix=/home/mw/local
<mwalle> $ git rev-parse HEAD
<mwalle> 63e5885478b8e4502e86c9ac8850da9e633b77fa
<larsc> mwalle: hm seems to work now, no idea why it wouldn't before
<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
<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
<larsc> or is this a bug in the console driver?
antgreen has quit [Ping timeout: 246 seconds]
<larsc> yeay, so in the driver we ack stat before we read the character
<larsc> funny moving that after we've read the char breaks rx
<larsc> or tx for that matter
<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
<mwalle> larsc: reading the RXTX regisgter?
<larsc> yes
<mwalle> didnt work for me, because 'uart_can_rx' will still return 0
<mwalle> because the event wasnt acked
<larsc> but in the driver we ack the event before we read the register
<mwalle> well...
<mwalle> ;)
<larsc> and acking it afterwards breaks tx
<mwalle> tx?
<larsc> yes
<larsc> The last 100 or so characters are missing
<mwalle> btw are you talking about the bios driver or flickernoiseß
<larsc> linux
<mwalle> ah *g*
<mwalle> but why should acking the event register break tx?
<larsc> qemu sets the STAT_TX_EVT flag uppon writing the RXTX register
<larsc> so if we clear the flag after writing the register we don't get a interrupt
<larsc> don't get the next interrupt
<mwalle> larsc: (compile error) did you clean up (or removed the build dir if you build out of tree)?
<larsc> mwalle: I did make clean and git clean -df
<mwalle> strange
<mwalle> larsc: ah so its the same code path for rx and tx?
<larsc> yes
<mwalle> shouldn't it be, rx char -> irq -> read char -> clear rx event, clear tx event -> tx char -> wait for irq?
<larsc> maybe
<larsc> for the real hardware it shouldn't matter, since there is no handshaking
<mwalle> mh?
<larsc> on the rx path the bit gets set when we recevice a new character
<larsc> and we'll get a overflow no matter what
<larsc> btw. you wrote that driver ;)
<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
<mwalle> yeah, so it must be full of bugs ;)
<mwalle> larsc: btw do git-clean respect gitignore?
<mwalle> try git clean -dfx
<larsc> i'll just to read status; receive char if RX_EVT is set; clear status; write char if TX_EVT was set
<larsc> that should work with the current qemu and doesn't have any additional overhead
<mwalle> larsc: yep that should do the trick
<larsc> git clean -xdf solved the compile issue
<GitHub54> [linux-milkymist] larsclausen pushed 1 new commit to master: http://git.io/FOb0YA
<GitHub54> [linux-milkymist/master] serial: milkymist_uart: Fix IRQ issues with QEMU - Lars-Peter Clausen
<mwalle> larsc: seems like two commits to me ;)
<larsc> i can't follow
<larsc> did you drink to much and see double?
<larsc> :p
<larsc> ah
<mwalle> there is the fix and some gpio stuff
aeris has quit [Ping timeout: 250 seconds]
<mwalle> milkyio, nice ;)
<larsc> lala
<larsc> nobody pulled yet?
<mwalle> na, force push ;)
<mwalle> btw you should remove the comment
<mwalle> or at least split it
<mwalle> anybody read "the soul of a new machine" by kidder?
aeris has joined #milkymist
<GitHub113> [linux-milkymist] larsclausen force-pushed master from c1499b1 to 7d61df4: http://git.io/-IOmgg
<GitHub113> [linux-milkymist/master] serial: milkymist_uart: Fix IRQ issues with QEMU - Lars-Peter Clausen
<GitHub47> [linux-milkymist] larsclausen force-pushed master from 7d61df4 to 6b3e3a9: http://git.io/-IOmgg
<GitHub47> [linux-milkymist/master] serial: milkymist_uart: Fix IRQ issues with QEMU - Lars-Peter Clausen
voidcoder has quit [Read error: Connection reset by peer]
voidcoder has joined #milkymist
kilae_ has quit [Quit: ChatZilla 0.9.88.2 [Firefox 14.0.1/20120713134347]]
voidcoder has quit [Read error: Connection reset by peer]