lekernel changed the topic of #m-labs to: Mixxeo, Migen, MiSoC & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
nicksydney_ has joined #m-labs
nicksydney has quit [Ping timeout: 264 seconds]
nicksydney_ has quit [Remote host closed the connection]
Wind-Storm has quit [Ping timeout: 252 seconds]
nicksydney has joined #m-labs
<ysionneau> mwalle: in theory yes, I'm just wondering where to fetch this information :p
<ysionneau> I hope that curcpu()->ci_user_segtab is updated before the ASID is
mumptai has quit [Ping timeout: 240 seconds]
sb0 has joined #m-labs
mumptai has joined #m-labs
<mumptai> re
<sb0> hi
<mumptai> is there a reason why the c++ support in the lm32-rtem4.11 isn't build by the script?
zeiris_ has quit [Ping timeout: 252 seconds]
<sb0> not sure; try it :)
<sb0> I attempted to use C++ (Qt) on Linux/LM32, and things didn't work
<mumptai> a long time ago i had a similar problem
<sb0> there were some ICEs and more weird behaviour which may or may not be due to compiler bugs
<sb0> when it did compile, after disabling the parts that caused the ICE
<sb0> but linux-lm32 is very shaky, and was even more so when I did those tests
<mumptai> but now a simple helloworld just went through, i just have to build a system to run it on
<sb0> so I'm not sure if gcc is to blame for the weird stuff (like the wrong method being called sometimes)
<sb0> yeah, it seems many C++ features actually work
<sb0> I've successfully run Antigrain Geometry
<mumptai> mhmm, there seems to be a fair amaount of llvm&lm32 action on github, is it the better choice right now?
<sb0> last commit is more than a year old, well :)
<sb0> llvm/lm32 also needs work, probably more than gcc actually
<mumptai> feels like yesterday
<mumptai> how much is lm32 actually used?
<sb0> btw gcc 4.9.0 is out today, and should be the first gcc release for 2 years that doesn't have totally broken lm32 support
<sb0> not enough for some reason
<sb0> most people prefer slower, bigger, and/or proprietary softcores
<sb0> :(
<sb0> well, there are some ASICs that integrate LM32 cores, but nothing of this is public
<sb0> White Rabbit also uses it
mumptai has quit [Ping timeout: 255 seconds]
<sb0> I have some customers using it too (as well as MiSoC and/or Migen)
mumptai has joined #m-labs
<mumptai> re
<mumptai> yes, indeed
<mumptai> used xps once, and learn to dislike it passionately
<sb0> gcc-lm32 4.9 seems to work :)
aeris has quit [Quit: en a pas]
<mumptai> build from official sources, or rtems?
aeris has joined #m-labs
<sb0> lm32-elf vanilla
<ysionneau> hourra \o/
<mumptai> and ftp.gnu.org is slow today .. what a surprise
* ysionneau is using the French mirror
<ysionneau> goes at > 1 MB/se
Wind-Storm has joined #m-labs
nicksydney has quit [Ping timeout: 264 seconds]
nicksydney has joined #m-labs
nicksydney has quit [Remote host closed the connection]
nicksydney has joined #m-labs
nicksydney_ has joined #m-labs
nicksydney has quit [Ping timeout: 264 seconds]
<wpwrak> (gcc 4.9) heh, "generic selections" sounds neat. so that's operator overriding for C. one step closer to being able to twice code that's just naturally obfuscated, like in C++ ;-)
<sb0> wpwrak, what do you think of rpython (pypy's restricted python)?
<sb0> it does static analysis to infer all types, and then converts to C
sb0 has quit [Ping timeout: 255 seconds]
sb0 has joined #m-labs
mumptai has quit [Ping timeout: 252 seconds]
mumptai has joined #m-labs
<mumptai> re
<mumptai> is there a good way to access the lm32 system to develop software on a bram-only soc? (something like grlib's dsu)
<sb0> the misoc bios can download software to bram
<sb0> and run it
<sb0> and you can XIP that BIOS from serial or parallel flash
<mumptai> but is executed from the very same bram?
Jespers has joined #m-labs
<sb0> iirc LM32 also supports tightly integrated BRAMs
<sb0> instead of mapping a BRAM on the wishbone bus, which is slow and inefficient
<sb0> but I have never tried
<sb0> all my misoc implementations are on boards that have sdram
<mumptai> the JTAG in lm32 source is lattice plattform specific?
<sb0> mwalle ported it to spartan6
<sb0> but iirc the pc side software (openocd) isnt in a good shape
<mumptai> ultimately bram is always short, so in the long run there will be external memory
<sb0> there is also the debug rom that works with gdb and the serial port
<mumptai> mhmm, gdb-stub
<sb0> it is only implemented in legacy soc atm, no one ported it to misoc
<sb0> if there is external memory then you can start with a wishbone mapped bram
<mumptai> but i guess it only supports the basic functions and software-breakpoints
<sb0> and then replace that peripheral with the proper external mem core
<sb0> it supports hw breakpoints and watchpoints
<mumptai> so there is support from the cpu
<sb0> yes
<mumptai> mhmm
<sb0> brb
sb0 has quit [Quit: Leaving]
sb0 has joined #m-labs
<mumptai> i just build the gcc-4.9.0 and compiled the tdc-core demo with it
<mumptai> and it ran straight out of the box
<mumptai> that was the most pleasant gcc cross build _ever_
<mumptai> mhmm, i think the "test-coverage" of the tdc-core s/w didn't include negative temperatures ;)
Jespers has quit [Quit: Jespers]
<sb0> no, it doesn't - and it was only meant to do tests at room temperature
<sb0> and slightly above
<sb0> well, up to 48C at package surface
<mumptai> i understand the original intention, it's perfectly fine with me. i just gave sensor a good blast of "kältespray" and it went of scale
<ysionneau> :)
<sb0> you have a SPEC?
<mumptai> no, i just had lx45 and ds18b20 sitting on my desk
<mumptai> i'd actually would have liked to use an TDC for a laser rangefinder project some years ago, that was wall beyond my scope at that time
<mumptai> s/an/a/
mumptai has quit [Ping timeout: 265 seconds]
mumptai has joined #m-labs
mumptai has quit [Read error: Operation timed out]
sb0 has quit [Quit: Leaving]
Wind-Storm has quit [Ping timeout: 265 seconds]