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