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