<lekernel>
cde: yeah, no problems. just avoid plugging/replugging the JTAG/serial adapter to/from the M1 when the M1 is powered on or when the JTAG adapter is connected to the PC
<cde>
oh that's normal, just need to compile the toolchain
kilae_ has joined #milkymist
kilae has quit [Ping timeout: 246 seconds]
<cde>
hmm, should update the README to mention autoconf 2.69 is required
<cde>
and automake 1.12.2 as well
<cde>
do I need rtems-yaffs2?
<cde>
yep, I do
<cde>
hmm /opt/milkymist/flickernoise/src/main.c:251: undefined reference to `rtems_shell_init_env'
<kristianpaul>
larsc: yeah...
<larsc>
kristianpaul: i patched my bios...
rejon has quit [Remote host closed the connection]
<kristianpaul>
larsc: send to upstream :)
<kristianpaul>
no fork ;)
<larsc>
lekernel doesn't want it
<kristianpaul>
i kwno ;)
<kristianpaul>
but there 3 request now
<kristianpaul>
perhaps four, wpwrak ? :)
<kristianpaul>
developer should let wanted features to merge !
<kristianpaul>
;-)
<cde>
oh, it's not that big a deal
<wpwrak>
kristianpaul: hmm, what issue ?
<kristianpaul>
wpwrak: missing carriage return in m1 bios
<wpwrak>
ah .. i think neocon doesn't need it. or i somehow avoided running into the problem by some other means.
<cde>
hmm would it be possible to clock the vga gen core higher with a pll to enable higher resolutions?
<kristianpaul>
i think that trick is used in fn
<kristianpaul>
not sure
<kristianpaul>
wpwrak: like many other issues/bugs on m1 end by avoid running in to the problem by other means...
<wpwrak>
heh :)
<wpwrak>
"stay out of trouble" - best survival strategy ever ;-)
<kristianpaul>
lol ;)
<wpwrak>
e.g., don't pet that cute furry sabretooth tiger
<kristianpaul>
come on, thats the among top
<wpwrak>
right after "let's explore this mountain where the gods are making noises and are having a smoke"
<kristianpaul>
jaja
<cde>
still having this undefined rtems_shell_init_env error :/ anybody has an idea?
<kristianpaul>
you aplied the patches?
kilae has joined #milkymist
<cde>
hmm wait
<cde>
when building flickernoise, three patches are applied automatically: openjpeg-0001-for-milkymist-one.patch mupdf-0001-for-milkymist-one.patch and jansson-0001-for-milkymist-one.patch.patch
<cde>
when building lm32 toolchain, four patches are applied automatically: binutils-2.22-rtems4.11-20120427.diff gcc-core-4.5.4-rtems4.11-20120703.diff newlib-1.20.0-rtems4.11-20120705.diff and gdb-7.4.1-rtems4.11-20120706.diff
kilae_ has quit [Ping timeout: 260 seconds]
<cde>
gdb-7.3.1-32-bit-ism-and-more-sloppy-macros.patch was apparently not applied, although it doesn't seem related to the error
<cde>
yep, I'm using precisely this, it's very useful :)
<cde>
91s to compile the whole soc! ise 13.2 is not so bad
<kristianpaul>
what?!
<cde>
Total CPU time to Xst completion: 91.53 secs
<cde>
it used about half a gig of RAM
<cde>
hmm wait, I think it hasn't done place and route yet
xiangfu has quit [Quit: Leaving]
<cde>
looks like I spoke too soon. ISE is still as slow as ever before
<kristianpaul>
btw anyone with "acess" had tried vivado?
<lekernel>
vivado is free download for everyone now
<lekernel>
it's not compatible with ISE projects or UCF files, you have to convert a bunch of stuff
<lekernel>
(not that the UCF syntax is particularly nice, though...)
<kristianpaul>
oh
<lekernel>
I'm happy to see it go, assuming they didn't replace it with something even worse
jimmythehorn has quit [Quit: jimmythehorn]
<cde>
lekernel: if I load a simple test bitstream into the FPGA, do I have to ensure some I/O are pulled up or low to avoid hardware issues? (nor corruption, overheating, ...)
<cde>
hmm it would seem the LM32 runs at 50 MHz, unless I'm mistaken. is it possible to clock it higher?
<kristianpaul>
what soc are you building? ng or legacy one?
<cde>
legacy I think, the latest commit is from Jun 4 (softusb: interrrupt support for navre)
<lekernel>
lm32 is 80MHz
<lekernel>
and 83MHz in ng
<cde>
it might not be a good idea to clock it higher though, even if timing allows it. I don't want to overheat the fpga
Martoni has quit [Quit: ChatZilla 0.9.88.2 [Firefox 15.0/20120825202003]]
<lekernel>
it doens't overheat
<lekernel>
problem is that FPGAs are slow, that's all
<lekernel>
if overheating was the problem, we'd have installed cooling on the M1 and clocked that CPU at a more decent frequency
<cde>
so the compiled milkymist-ng should be compatible with my current flickernoise right? I assume only the bios must be updated (probably due to the different memory controller design)
<cde>
so let's install python 3.2 ;)
<kristianpaul>
heat is good it means more speed if we had it ;)
<cde>
speed doesn't matter. my first computer ran at 900 khz ;)
elldekaa has joined #milkymist
<kristianpaul>
cool :)
<kristianpaul>
:w!
<kristianpaul>
oops
<Hodapp>
:P
<cde>
wow, tmu2 is quite a piece of work
jimmythehorn has joined #milkymist
<cde>
lekernel: is there a PoC of implementing 3D graphics using pfpu+tmu2?
<lekernel>
DF system will provide components for doing this, but I'm not finished with them yet
<cde>
hrm are you sure about the switch to lua? there's easily a 10x-50x perf reduction as compared to C
<lekernel>
shouldn't matter for high level application code like describing a file-open dialog box
<lekernel>
this is a pain in the ass to do in C
<lekernel>
of course, performance critical software code will be in C or assembler
<cde>
ah yes, that makes sense
<Fallenou>
mwalle: what for ?
<Fallenou>
you can put a few nops just to feel safe but they should not be needed
<mwalle>
Fallenou: at which instruction can we be sure we are running out of a mapped page?
<lekernel>
cde: bufgmux is only for clocks
<lekernel>
for regular signals you use LUT and MUXFx
<Fallenou>
mwalle: running out ? I don't get this expression
<cde>
oh wow is wpwrak really the original author of LILO?
<Fallenou>
cde: it did the same effect on me =)
<cde>
this is quite awesome!
<cde>
when grub came I had to unlearn running lilo after a kernel compile ;)
<mwalle>
Fallenou: assume the transion ITLB off -> ITLB on, at some point (measured in instructions after the wcsr to PSW) instructions are fetched through a mapped page
<Fallenou>
yes , sure
<Fallenou>
I will have to check, but I would say : wcsr, nop, X
<mwalle>
i guess this isnt the first instruction, because in that case your call_func_with_itlb_enabled wouldnt work
<Fallenou>
and X is fetched from virtual address
<mwalle>
and if you say you dont require nops after the wcsr, you have to make sure the very next instruction after wcsr is always fetched with itlb disabled
<Fallenou>
but it's a complex question :p
<Fallenou>
I had to battle to make all of this work
<mwalle>
eg is that true if there is a interrupt between wcsr and the next instruction?
<Fallenou>
mwalle: the very next instruction after wcsr is "fetched" while wcsr is decoded
<Fallenou>
so it's fetched with itlb off
<Fallenou>
address->fetch->decode->execute->mem access->write back
<mwalle>
and if there is an interrupt in between?
<Fallenou>
that's a good question ^^
<Fallenou>
it depends if it happens while wcsr is in decoding or executing stage
<Fallenou>
exception happens in execution stage so after return from exception it will go back to what was in execute stage
<Fallenou>
but yes it's a very good question
<mwalle>
so if we require some nops after the wcsr, we make sure itlb is enabled
<Fallenou>
yes you're right
<Fallenou>
it may be safer
<mwalle>
of course you need a valid mapping for the current code
<mwalle>
i guess the same is true for ITLB on -> ITLB off?
<Fallenou>
I wonder if there is a use case for disactivating manually ITLB
<Fallenou>
surely
<mwalle>
at least my test case use that;)
<Fallenou>
hehe
<Fallenou>
each time I chat here I end up thinking I need more tests :)
<Fallenou>
I had a drop in motivation for a few weeks
<Fallenou>
but I am resuming slowly the task :)
<mwalle>
Fallenou: the qemu test cases should run on your milkymist too, with some adjustments
<lekernel>
you could also learn a lot of things e.g. implementing ASMI prefetch+cache in the TMU
<lekernel>
and the OSHW-CPU world will not have yet another half finished, buggy and generally unusable softcore
<cde>
hmm. that's a steep learning curve ^^
<lekernel>
seriously there is like, a hundred of open source softcores projects today
<lekernel>
only two are usable: LM32 and LEON
<hellekin>
lekernel: do you have a complete list?
<azonenberg>
openrisc?
<azonenberg>
no experience with it but i've heard its decent
<lekernel>
openrisc isn't usable. it's slow (less than half the speed of LM32), bloated (3x the size of LM32), and buggy
<azonenberg>
i see
<lekernel>
there's this recent reimplementation which seems to go in the right direction, but haven't tested yet
<lekernel>
and it has no MMU. at least, LM32 has part of it.
<mwalle>
gn8
<cde>
in my view, an MMU is a relic of the days when software was distributed in the form of binaries and a memory boundary was needed. with software distributed in source, and memory checks added by the compiler, an MMU becomes mostly irrelevant, although it can help for memory defrag
<cde>
the closed-source ecosystem adopted Linux precisely because it allows execution of proprietary, binary-only software. a truely Free OS would not allow that