<Fallenou> lekernel: have you moved your debian repository for gtkterm and gcc-lm32 somewhere else ?
<Fallenou> this does not work anymore
<lekernel> it was old and unmaintainable, since i'm not using debian anymoe
<lekernel> so I removed it
<lekernel> all new software uses the rtems toolchain anyway
<Fallenou> yep there is a tutorial about how to compile the toolchain on the wiki
<Fallenou> and a few rpms I guess on rtems website
<kristianpaul> there is a script also for buils almost everyhting
<kristianpaul> s/for buils/to build
<Fallenou> yep which is really usefull since there is much more dependencies now than at the beginning :)
<Fallenou> s/is/are/
<kristianpaul> dependencies, oh yeah....
<GitHub171> [linux-milkymist] mwalle created new-uart (+1 new commit): http://bit.ly/pAcBqz
<GitHub171> [linux-milkymist/new-uart] lm32: update driver for new uart core - Michael Walle
<kristianpaul> mwalle: full rewrite?
<mwalle> kristianpaul: uart core?
<kristianpaul> yes
<mwalle> no only some small changes ;)
<mwalle> kristianpaul: btw did you get all 7 mails?
<mwalle> that is 6 patches and one cover letter
<Fallenou> I got the seven mails
<mwalle> ah theres an archive, so i can verify it myself ;)
<kristianpaul> yes all of then
<mwalle> kk so then we'll see us in two weeks :)
<kristianpaul> oh, bye then!
<mwalle> at least regularly, maybe there will be some open wlan
<mwalle> and maybe someone will find the bug, why some rx chars are dropped :)
<kristianpaul> those status and control bits should be mirrored/copied to others core  as well to make easy linux support?
<mwalle> i think some already have those
<mwalle> as a rule of thumb, a linux driver should not need to touch the IP register of the processor
<kristianpaul> (some alredy) hum, yes, now i was wonder why uart doesnt if was already part of CSR :)
<mwalle> simplicity
<Fallenou> mwalle: holidays ?
<kristianpaul> sure
<mwalle> Fallenou: yeah :)
<Fallenou> ahah have fun :)
<mwalle> thx
<kristianpaul> where you going btw?
<mwalle> fuerteventura
<kristianpaul> nice, go to the beach is always refreshing, most if an island
<kristianpaul> enjoy!
<Fallenou> lekernel: is configuring gcc with --disable-multilib wrong ?
<Fallenou> multilib thingies are still blurry to me
<Fallenou> As I understood multilib is here to provide multiple libgcc with different configurations, but we only want/need one configuration
<Fallenou> so I guess no need multilib
<lekernel> if you only build the multilib with all the CPU options enabled (divider, barrel shifter, ...) that's fine, at least for milkymist
<lekernel> multilibs are a simple thing
<lekernel> they're only the same libraries built for CPUs with different options (with/without multiplier, divider, etc.)
<lekernel> the LM32 implementation has all the options enabled, but by default, the libraries built by GCC leave out some of them, which makes software slower
<GitHub8> [milkymist] sbourdeauducq pushed 1 new commit to master: http://bit.ly/r6D3qd
<GitHub8> [milkymist/master] gdbstub: cosmetic cleanups - Michael Walle
<lekernel> <lekernel> if you only build the multilib with all the CPU options enabled (divider, barrel shifter, ...) that's fine, at least for milkymist
<lekernel> multilibs are a simple thing
<lekernel> they're only the same libraries built for CPUs with different options (with/without multiplier, divider, etc.)
<lekernel> our LM32 implementation has all the options enabled, but by default, the libraries built by GCC leave out some of them, which makes software slower
<Fallenou> ok thanks for the explanation
<Fallenou> lekernel: is there a way to check which cpu options are enabled ?
<Fallenou> I tried gcc -dumpspecs
<lekernel> option like -mdivide-enabled, -mmultiply-enabled are passed to gcc for that purpose
<Fallenou> it outputs this :
<Fallenou> *asm:
<Fallenou> %{mmultiply-enabled} %{mdivide-enabled} %{mbarrel-shift-enabled} %{msign-extend-enabled} %{muser-extend-enabled} %{v}
<lekernel> ah
<Fallenou> even without your patch
<lekernel> a sure way to check is to disassemble the generated libraries and check for the optional instructions
<Fallenou> yep
<lekernel> but it'd tend to thing that, using the --without-multilib option, gcc would build libraries without any option
<Fallenou> yes that's what I feared
<Fallenou> I removed the --without-multilib and am recompiling
<Fallenou> hum it's compiling newlib right now
<Fallenou> got lines like this :
<Fallenou> /opt/local/var/macports/build/_Users_fallen_ports_cross_lm32-rtems-gcc/lm32-rtems-gcc/work/build/./gcc/xgcc -B/opt/local/var/macports/build/_Users_fallen_ports_cross_lm32-rtems-gcc/lm32-rtems-gcc/work/build/./gcc/ -nostdinc -B/opt/local/var/macports/build/_Users_fallen_ports_cross_lm32-rtems-gcc/lm32-rtems-gcc/work/build/lm32-rtems4.11/mbarrel-shift-enabled/msign-extend-enabled/newlib/ -isystem /opt/local/var/macports/build/_Users_fallen_ports_cross_lm3
<Fallenou> sorry for the flood
<Fallenou> it seems it's not putting all the optimizations
<Fallenou> oh wait, looking at the directory path , it seems it's compiling a version with just those two cpu optimizations ...
<Fallenou> maybe it will compile another version with all the optimizations ...
<Fallenou> that's just crazy ...
<lekernel> yeah it compiles for all the options
<Fallenou> and all combinaisons ?
<lekernel> it takes a bit of time, but cpu and disk space are cheap those days :-)
<lekernel> yes
<Fallenou> omg
<Fallenou> crazy gcc is crazy
<lekernel> it's not that big
<Fallenou> Will try to disable multilib and see if it does compile only one libc libm etc, but with the right options
<Fallenou> I hope so
<Fallenou> an extract of the lm32-rtems4.11-gcc -dumpspecs : http://pastebin.com/DHr7XAh8
<lekernel> well, as long as it works...
<Fallenou> lekernel: I think if you put MULTILIB_OPTIONS = a/b/c/d instead of a b c d
<Fallenou> if will only build the abcd combinaison
<Fallenou> will try
<mwalle> lekernel: what happens if you ack the interrupt right after entering the isr
<lekernel> the CPU can still miss a second event while it's doing things like setting stack frames, reading IP, etc.
<lekernel> mh, no
<mwalle> mh? if i do sth like, irq fires, isr is called, ack irq, read stat, do stuff, return
<mwalle> there could be additional isr calls which actually do nothing
<lekernel> no, that would work
<mwalle> so thats not the bug, because its done that way
<kristianpaul> btw, i always wondered how DataBusErros are handled by lm32 and by then by software running on it, for example a slave wishbone core that never reply an ACK
<lekernel> kristianpaul, bus error jumps to exception, no ack reply locks up
<lekernel> mwalle, let's not spend time debugging this, since this will be changed to level sensitive interrupts later
<lekernel> which have no such problem
<mwalle> lekernel: using level sensitive interrupt and acking tx int by reading STAT and acking rx by reading STAT or reading RXTX ?
<lekernel> do not perform any action on CSR reads (just return values) - since the CSR bus has no strobe signal, it would react to invalid addresses on the bus
<lekernel> for interrupts, you can use bits that atomically clear when written with 1 in STAT
<lekernel> oh, and maybe the STAT register should not have an interrupt enable feature... can't IM be used?
<lekernel> either implement interrupt enables in the core or IM, but not both
<mwalle> for normal operation you wont need explicit interrupt acks imho, otho gdbstub needs something like that
<mwalle> no i have to disable the interrupts without accessing IM
<lekernel> so, should we remove IM?
<mwalle> remember IM/IP/IE is only accessible from arch/lm32 code
<mwalle> if we remove IM linux wont be able to mask spurious interrupts
<lekernel> is that important?
<mwalle> i would say yes :)
<lekernel> what do you mean, no explicit interrupt acks?
<lekernel> you should not alter the core state on a CSR read
<mwalle> uart rx int fires, you read RXTX, int is automatically acked, no need to perform any w1c or anything like that
<lekernel> when csr_we = 0, the addresses can correspond to either a valid read or anything
<kristianpaul> lekernel: (locks up) this is just a design missing feature from lm32 or something could be handled better therically implementated in the wishbone arbiter?
<lekernel> there's no strobe signal for reads
<mwalle> (implicit acks) the 16550 does it that way
<lekernel> yes, but i'd guess the 16550 has some form of read strobe signal
<mwalle> assign rx_rd = csr_selected & !csr_we & (csr_a[2:0] == 3'b000);
<lekernel> csr_selected is not a strobe signal, it just means that four bits of the address have some value
<mwalle> mh ok, then this could be the bug :)
<lekernel> if you use registers that modify state when read, it would react correctly when e.g. 0xe000d000 is read
<lekernel> but also induce a spurious state modification when 0x4000d000 (and others) are read by the CPU in SDRAM
<mwalle> ok, so DR should be w1c?
<lekernel> yes
<lekernel> csr_selected & csr_we, otoh, is a valid write strobe signal
<mwalle> yeah, and THRE wont need to be acked, a little bit asymmetrical
<lekernel> you can make THRE w1c as well, no?
<lekernel> to ack the interrupt when there are no more characters to be transmitted
<mwalle> then i would name it TD, or TX_DONE or sth like that, but i couldnt spin on it anymore
<mwalle> which is needed for a polling uart driver (gdbstub and linux console)
<lekernel> ok
<lekernel> so keep thre
<mwalle> stat = {tx_done, rx_event, thre} ?
<mwalle> tx_done and rx_event is w1c and irq = (tx_int_en & tx_done) | (rx_int_en & rx_event)
<lekernel> sounds good
<lekernel> and do you still need the interrupt masks then?
<mwalle> yes i need to be able to disable irq without accessing IM
<mwalle> btw (irq reordering) i didnt want to clutter the patch :)
<mwalle> gn8 and byebye
<mwalle> see u
<Fallenou> see u
<Fallenou> enjoy your holydays
<mwalle> thx Fallenou