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