lekernel changed the topic of #milkymist to: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs :: EHSM Berlin Dec 28-30 http://ehsm.eu :: latest video http://www.youtube.com/playlist?list=PL181AAD8063FCC9DC
sh4rm4 has quit [Remote host closed the connection]
xiangfu has joined #milkymist
xiangfu has quit [Quit: Leaving]
xiangfu has joined #milkymist
sh4rm4 has joined #milkymist
rejon has quit [Remote host closed the connection]
rejon has joined #milkymist
rejon has quit [Ping timeout: 276 seconds]
rejon has joined #milkymist
rejon has quit [Ping timeout: 248 seconds]
rejon has joined #milkymist
kilae has joined #milkymist
kilae_ has joined #milkymist
kilae has quit [Ping timeout: 245 seconds]
mumptai_ has joined #milkymist
kilae has joined #milkymist
Martoni has joined #milkymist
kilae_ has quit [Ping timeout: 252 seconds]
elldekaa has joined #milkymist
rejon has quit [Ping timeout: 246 seconds]
lekernel has joined #milkymist
cde has joined #milkymist
<cde> hey guys :)
<larsc> hi cde
<lekernel> hi
<cde> is it ok if I poweron the M1 while the JTAG adapter is plugged in and connect to the PC?
<cde> *connected
<larsc> should be, never had any problems with it
<cde> thanks :) on my way to reflash now
<cde> hmm I think the latest git already has the lockflash/unlockflash commands
<cde> I have the RC3 rev, do I need files from http://www.milkymist.org/updates/2011-07-13/for-rc3/ ?
xiangfu has quit [Ping timeout: 252 seconds]
togi_ has quit [Ping timeout: 245 seconds]
togi has joined #milkymist
<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
<lekernel> that's old software. better use http://milkymist.org/updates/2012-03-01/
<lekernel> or you can reflash without jtag, just connect ethernet and run the web update on the m1
<cde> thanks! I'll use jtag just to give it a try, next time I'll use either web update or rescue
<cde> I assume the lockflash fixes the nor corruption bug?
<lekernel> "for-rc3" simply means that those are the images that were used in the rc3 production
<cde> can bios.bin be also used for the bios-rescue partition ?
xiangfu has joined #milkymist
xiangfu has quit [Ping timeout: 276 seconds]
<cde> hmm let's try xiangfu's 20120717-1555 build!
<lekernel> no, they are different
kilae_ has joined #milkymist
kilae has quit [Ping timeout: 276 seconds]
xiangfu has joined #milkymist
<cde> it works! youpi :)
rejon has joined #milkymist
xiangfu has quit [Ping timeout: 244 seconds]
<cde> wow, the bios is very nice
<cde> is debian stable (squeeze) compatible with the toolchain required to build milkymist?
<Fallenou> yes
<Fallenou> I can build the bitstream (fpga) and the bios with debian squeeze
<Fallenou> and the toolchains
<Fallenou> I guess building rtems and flickernoise works as well
<cde> and there's an uart console over the ftdi. very cool!
<Fallenou> yes !
<Fallenou> best way to deal with uart is to use flterm tool under "tools/" directory in the milkymist repository
<Fallenou> flterm --port /dev/ttyUSB0
<cde> thanks. I noticed screen doesn't work too well with it, so I used microcom
mumptai_ has quit [Ping timeout: 252 seconds]
xiangfu has joined #milkymist
kilae has joined #milkymist
<kristianpaul> hi cde :)
kilae_ has quit [Ping timeout: 268 seconds]
<kristianpaul> afaik screen doesnt :(
<larsc> it's because of the stupid missing carriage returns
<cde> I haven't compiled the soc yet, but what percentage of the fpga will remain free for additional stuff?
<xiangfu> cde, ~50%
<cde> that's nice! btw, http://www.milkymist.org/debian/ is 404 :(
<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
<kristianpaul> no wait are/is other, looking...
<cde> my god, it's full of patches!
<kristianpaul> not all apply, quilt knows
<cde> shouldn't they (or some) be merged upstream?
<kristianpaul> one day will :)
<cde> ok, almost all have been applied. export-shell-fns.patch will fix the problem
<cde> thanks, kristianpaul
<Fallenou> pfiou
<Fallenou> it's becoming painful to build everything manually
<cde> oh, I meant almost all patches are already part of the git head. I just had to apply one manually
<cde> and it's compiled! very cool
elldekaa has quit [Remote host closed the connection]
<cde> ERROR:Map:258 - A problem was encountered attempting to get the license for this architecture.
<cde> damn you, Xilinx
<kristianpaul> Fallenou: not at all, milkymist.org/script do most of the work
<kristianpaul> except werner patches
<kristianpaul> patch*
<cde> yep, it's very straightforward
<xiangfu> this may save some of your time. :)
<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?
fpgaminer has joined #milkymist
<cde> had to apply this patch when building clang: http://llvm.org/bugs/attachment.cgi?id=7756
<lekernel> no
<lekernel> milkymist-ng cannot run flickernoise yet
<lekernel> tmu should move to migen flow. should reduce the number of lines of code by a fair bit :)
<lekernel> but yeah... lots of work
<cde> llvm-lm32 compiled! now compiler-rt
<cde> ah well, I can also tinker with flickernoise on the classic soc
<cde> hmm, lm32-elf-ar: libc.o: No such file or directory. let's check everything again
<cde> lekernel: for the record, those two lines were not playing to well for some reason:
<cde> #%.o: %.c
<cde> # $(compile-dep)
<cde> (I commented them to make it work)
<cde> there is probably a nicer way to fix it
<cde> bios.bin, here we come
<cde> damn, easy_install won't install networkx
<cde> pygraphviz doesn't seem python 3.2 friendly :/
<cde> lekernel: how did you manage to get it to work?
mumptai has joined #milkymist
<lekernel> ah, yes, graphviz is a pain. but you don't need it for just building the soc, only some test benches use it.
<lekernel> I had to compile it manually
<lekernel> and will probably replace it with something else, the results don't look too good anyway
<cde> thanks
<cde> there is http://igraph.sourceforge.net/ as a possible alternative to networkx
kilae_ has joined #milkymist
kilae has quit [Ping timeout: 268 seconds]
<cde> hrm, my self-compiled flickernoise fails to compile Rovastar & Idiot24-7
<wpwrak> is this the only one with problems ? or just the first one where you run into them ?
<cde> oh, just the first. there were about 4/5
<cde> I just moved them around
<cde> is there a patch that uses the CCD camera?
<wpwrak> Lekernel\ -\ FullScreen\ Video-in\ Preview.fnp ? :)
<cde> cool
aeris has quit [Ping timeout: 252 seconds]
aeris has joined #milkymist
<cde> hrm. how do I get back to the gui
<wpwrak> Esc ?
<wpwrak> (if i remember correctly)
<cde> ok, my keyboard must be non-working
<cde> the thing with the giant caps lock key also does not work, although I can boot to the console with esc
<cde> well video input is working very well although the ccd camera gets hot a bit
<cde> btw not sure if Adam is here, but some time ago he was looking for a TSOP test clip. here's one: http://www.elitasia.com/360-Clip-for-PS3-Slim-50-pin-NOR-Flash
<wpwrak> the camera getting hot is "normal". not sure why they made it this way, though.
<cde> for those cold winter nights, I assume
<cde> hrm those BOOTP messages in the console are annoying
<hellekin> wpwrak: back to buenos aires
<hellekin> i'm leaving on the 15th
wolfspra1l has joined #milkymist
wolfspraul has quit [Ping timeout: 248 seconds]
kilae has joined #milkymist
kilae_ has quit [Ping timeout: 264 seconds]
<mwalle> Fallenou: if i switch on the itlb, are there nops required?
<Fallenou> mwalle: it depends on what you do afterward
<Fallenou> if you want to switch on itlb and then jump to a virtual address
<Fallenou> lemme check
<Fallenou> #define call_function_with_itlb_enabled(function) do { \
<Fallenou> no nop
<Fallenou> ignore the comment // FIXME, it's wrong now I have to remove this comment
<Fallenou> if you want to just switch on itlb and let the cpu continue executing the code, it depends if you map vaddr == paddr or vaddr != paddr
<Fallenou> if vaddr == paddr it's ok, you don't need a nop
<Fallenou> if vaddr != paddr you need 1 nop I would say
<mwalle> Fallenou: yes that was my next question, i assume vaddr == paddr is always needed for the code switching on the itlb and then branches
<Fallenou> mwalle: if your next operation is a jump/call you don't need a nop :)
<Fallenou> even if the code running (activating itlb) is not mapped
<Fallenou> at all
<mwalle> because the instruction is already fetched?
<Fallenou> because the timing is such that the itlb is actually ON for the fetch of the instruction being jump on
<Fallenou> jumped*
<Fallenou> and not before
<Fallenou> so you only need to worry about mapping the virtual address you jump to
<mwalle> mh
<Fallenou> if it does not do this, it's a bug :)
<Fallenou> but so far it's OK in my tests
<cde> how big of a speedup will I get with ASMI as compared to the classic SoC?
<Fallenou> I think it's more the idea that it's faster to write such things with migen than writting the signaling etc code in pure verilog
<Fallenou> handshacking, serialising etc is done automagically with migen :)
<Fallenou> so you only need to worry about what you want to do
<Fallenou> I guess that's a big speedup :)
<cde> could we get an ASMI implementation in the classic SoC?
<Fallenou> oh sorry I said bullshit
<Fallenou> I was talking about the dataflow stuff
<Fallenou> not ASMI
<Fallenou> I mixed up things in my head =)
<cde> multiplexing can be good. saves gates
<larsc> multipexers in fpga can be expensive though
<cde> BUFGMUX ftw ;)
kilae has quit [Quit: ChatZilla 0.9.88.2 [Firefox 15.0.1/20120905151427]]
<lekernel> cde: ASMI should bring 2x to 4x more memory bandwidth compared to the current memory system
<lekernel> cde: ctrl+esc to leave rendering mode
<lekernel> could we get an ASMI implementation in the classic SoC => bring the missing bits into milkymist-ng instead...
<cde> ok :) very nice perfs btw! also will the next milkymist be all digital? I think audio in/out jacks would still be useful
<cde> what are the missing bits?
<lekernel> USB for example
<lekernel> and TMU, but that's a difficult one
<cde> tmu is a bit scary, yes
<cde> how hard will it be to bring mmu into -ng?
<lekernel> either use DF and rewrite everything
<lekernel> or take some of the old verilog code
<mwalle> Fallenou: shouldn't we require some number of NOPs after switching on the ITLB?
<lekernel> either way with ASMI you need to implement the whole http://window.stanford.edu/papers/texture_prefetch/texture_prefetch_down.pdf
<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
<Fallenou> good to know :)
<Fallenou> where are the tests in the tree https://github.com/mwalle/qemu/tree/mmu ?
<mwalle> yeah, tests/tcg/lm32/test_mmu.S
<mwalle> i'm currently working on the itlb and the control interface update
<Fallenou> nice
<Fallenou> I modified my code to allow removing completely TLBCTRL csr
<Fallenou> to just use TLBVADDR with lower bits indicating the action to perform
<Fallenou> and to make the mapping enter the TLB while writting to TLBPADDR
<Fallenou> it's not pushed yet because I think there is a small bug (software one I think) lurking somewhere
<Fallenou> but it's almost done
<mwalle> http://pastebin.com/wj6XY1gY thats my current testcase
<Fallenou> I mostly write my tests in C ... I should do like you
<Fallenou> I lose a lot of time to ensure the C is translated into the correct ASM code
<GitHub47> [migen] sbourdeauducq pushed 3 new commits to master: https://github.com/milkymist/migen/compare/6490785b6c68...fc3187317b0e
<GitHub47> [migen/master] examples: update LM32 instance - Sebastien Bourdeauducq
<GitHub47> [migen/master] Multi-clock design support + new instance API - Sebastien Bourdeauducq
<GitHub47> [migen/master] examples: demonstrate multi-clock support - Sebastien Bourdeauducq
<Fallenou> if you map current code and then activate itlb, put a few nops and then calli something it will surely work
<GitHub101> [milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/b-apuw
<GitHub101> [milkymist-ng/master] Basic support for new clock domain and instance API - Sebastien Bourdeauducq
<Fallenou> it even work when current code is not mapped if the calli is right after wcsr :)
<Fallenou> which is kind of beautiful to see working
<mwalle> hehe
<Fallenou> but yes after you need to worry about interruptions messing everything up
<Fallenou> I will try to fix the few remainings problems and push the changes in the "API" before going to Oslo (on friday)
<Fallenou> mwalle: the "problem" with your code is that it would not print anything on uart :(
<Fallenou> so it's hard to check if it's really working
<Fallenou> but I can run it in ISim and check the simulation results :)
<mwalle> Fallenou: adjust the macros
<mwalle> should be easy to send some string via uart
<Fallenou> yes
mumptai has quit [Ping timeout: 276 seconds]
<Fallenou> thanks !
<Fallenou> going to sleep now :)
<Fallenou> gn8 !
<mwalle> gn8
<mwalle> pushing my changes now
<Fallenou> lekernel: how was the reaction to migen presentation ?
<Fallenou> at fpga world
<cde> azonenberg: and its too fast for my LA <- the LA1034 is supposedly fast enough for a 125 MHz SDRAM, and it's not too expensive
<azonenberg> cde: i was using DDR at 160 MHz
<cde> oh
<azonenberg> and i've been using my internal LA lately since it can go over 200 MHz and captures synchronous to an on-chip clock
<cde> your softcore is mips? is it open-sourced?
<azonenberg> cde: an older version of it is
<azonenberg> i'm doing current work on a private fork until i publish my thesis
<azonenberg> at which point i'll merge back to the mainline
<cde> oh. I remember using plasma some years ago. it worked reasonably well, although it lacked many featyres
<azonenberg> Yeah, mine is nicer
<azonenberg> plasma was slow, i think only three pipeline stages
<azonenberg> mine is five
<cde> very nice. do you also have non aligned memory access?
<azonenberg> Not implemented because gcc doesnt generate those opcodes by default
<azonenberg> but the patent is expired so i could add it if needed
<cde> yeah iirc some company got sued to oblivion a few years ago, very sad
<azonenberg> well afaik as long as you dont use the MIPS trademark when describing your design
<azonenberg> mips1 is unencumbered now
<cde> that's cool
<cde> btw did you see the mips16 isa? not many people use it I think, it reminds of a thumb copycat
<azonenberg> I think its still patented
<azonenberg> and it is
<azonenberg> My arch is pure 32 bit
antgreen has joined #milkymist
<GitHub25> [milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/x71_Sw
<GitHub25> [milkymist-ng/master] Define clock domains instead of passing extra clocks as regular signals - Sebastien Bourdeauducq
<cde> I was considering implementing MIPS I too. it doesn't look exceedingly difficult without the mmu
<azonenberg> well i'm going to need at least a basic mmu here but it wont be mips standard
<azonenberg> it's going to have to be full custom to interface with my NoC
<lekernel> why duplicate Lattice's and Fallenou's work?
<cde> oh, to learn things
<cde> by the way is the MIPS I ISA officially described somewhere? I could only find bits and pieces
<GitHub21> [migen] sbourdeauducq pushed 2 new commits to master: https://github.com/milkymist/migen/compare/fc3187317b0e...3b3e2f19eb21
<GitHub21> [migen/master] Merge branch 'master' of github.com:milkymist/migen - Sebastien Bourdeauducq
<GitHub21> [migen/master] setup.py: cosmetic - Sebastien Bourdeauducq
<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
<cde> azonenberg: http://code.google.com/p/utica-softcore/ <= this is your softcore MIPS CPU I assume?
<lekernel> something simpler then: get USB to work on -ng using the old verilog code
<cde> that seems doable! well I think
<cde> wow,
<cde> homecmos is quite awesome!
<cde> azonenberg: looking forward to your first IC :)
lekernel_ has joined #milkymist
lekernel has quit [Ping timeout: 276 seconds]
<azonenberg> Lol its a ways out
<azonenberg> cde: and yes
elldekaa has quit [Remote host closed the connection]