| --- Log opened Sat Apr 05 00:00:51 2014 | ||
| stekern | _franck__, olofk: regarding 'test' systems, I believe those belongs more in fusesoc or in a seperate 'fusesoc-testsuite' than in orpsoc-cores | 05:52 |
|---|---|---|
| stekern | because, orpsoc-cores is just a user of fusesoc, it can't be it's task to look after it | 05:54 |
| stekern | _franck__: can you check if this works on your machine? https://github.com/openrisc/orpsoc-cores/pull/48 | 06:09 |
| stekern | dalias: I think I've got to the point in my TODO pipeline where musl was, so I'll start with the openrisc port now | 06:12 |
| olofk | stekern: Agree. I think we should just dump test-related stuff under tests in fusesoc | 06:26 |
| _franck__ | we agree, I've already started to create a tests folder in fusesoc | 06:46 |
| _franck__ | stekern: I'll test it when I get back to my dayjob | 06:46 |
| Findeton | hi | 09:18 |
| dalias | stekern, great | 11:15 |
| stekern | blueCmd: how is your atomic patch moving along? | 12:20 |
| stekern | I'm tempted to just implement ll/sc and let it be done... | 12:20 |
| blueCmd | stekern: for kernel space? | 14:19 |
| stekern | yes, for the kernel | 14:21 |
| stekern | I've started to port musl and I'm at the point where I should implement the atomic operations | 14:22 |
| blueCmd | stekern: No, I posted an updated patch but I got no response to that nor my ping | 14:31 |
| stekern | hmm, so in an old (very old) version of the arch spec, this text was present: http://pastebin.com/bv3DNJ8s | 14:45 |
| stekern | I'm thinking about proposing that we add that (or something similar) back in to the arch spec, and then sit down and put in support for it to the implementations that matter most - mor1kx, or1200, or1ksim and qemu (perhaps blueCmd or poke53282 could volunteer on the qemu part) | 14:58 |
| stekern | and then support for it in binutils | 14:59 |
| blueCmd | stekern: sgtm | 15:14 |
| blueCmd | stekern: btw, nice that you're porting musl | 15:15 |
| dalias | stekern, what's the way atomics would be done now? | 16:36 |
| dalias | fwiw, a true atomic CAS is much better than ll/sc | 16:36 |
| dalias | with ll/sc it's highly nontrivial to get any realtime guarantees about forward progress | 16:37 |
| stekern | dalias: sure, but given the added complexity of implementing true CAS (especially for a load/store RISC arch), I think ll/sc is a lot more feasible for us | 16:49 |
| stekern | and it's a whole lot better than the syscall "hack" we are using now | 16:49 |
| dalias | well yes, a syscall is a pretty horrible way to do it | 16:51 |
| stekern | without hw support, there's not much other options | 16:52 |
| stekern | niosII and microblaze are doing worse in uClibc btw, they turn off interrupts from userspace | 16:53 |
| stekern | but I noticed that microblaze have added ll/sc now, and are using that in musl | 16:53 |
| dalias | yes | 16:59 |
| dalias | btw on cpus that lack ll/sc originally but add it later | 16:59 |
| dalias | it's VERY nice if the kernel can emulate ll/sc on older models | 16:59 |
| dalias | this is less important on soft cores tho because you can just tell ppl to upgrade their softcore :) | 17:00 |
| stekern | there will be an illegal instruction exception generated on them, so at least theoretically it would be possible to emulate it | 17:17 |
| dalias | right | 17:17 |
| dalias | iirc linux does that for mips | 17:17 |
| dalias | for uniproc, emulating ll/sc is trivial | 17:17 |
| dalias | you just set a flag for ll then do it like a normal load | 17:18 |
| dalias | check the flag on sc and fail if it's not set | 17:18 |
| dalias | and clear the flag on context switches | 17:18 |
| dalias | for multiproc it's not possible afaik | 17:18 |
| stekern | right | 17:18 |
| dalias | but presumably cpus without ll/sc are not used/usable for multiproc | 17:19 |
| stekern | another reason we want to get the hw support for it ;) | 17:19 |
| dalias | :) | 17:20 |
| olofk | stekern: Was that in an older version of the arch spec? If so, why was it removed? | 18:16 |
| Findeton | okay I've got linux running under the openrisc sim | 18:20 |
| Findeton | the problem is | 18:21 |
| Findeton | I try to do ping 192.168.1.1 | 18:21 |
| Findeton | and in the host console it says: ERROR: Failed to write Ethernet packet data: Bad file descriptor. | 18:21 |
| Findeton | in the openrisc console nothing happens | 18:22 |
| olofk | Findeton: You probably need to edit your or1ksim config file | 18:22 |
| Findeton | olofk, that way I'll be able to connect with the host computer? | 18:22 |
| olofk | There are a few different ways to emulate ethernet in the simulator. I suspect that it is set up to read and write packets to files | 18:22 |
| Findeton | interesting | 18:23 |
| olofk | Findeton: Yes. You need to activate TUN/TAP support | 18:23 |
| olofk | I haven't done it in a while, so I can't remember the exact details, but I'll see what I can dig up | 18:23 |
| olofk | Are you familiar with tun/tap? | 18:23 |
| Findeton | no but I'll google that | 18:24 |
| Findeton | actually, I see there's a tap configuration already set up | 18:24 |
| olofk | Hmm.. iirc jeremybennett put some helper scripts somewhere | 18:25 |
| olofk | Yep, they should be in the or1ksim source directory | 18:26 |
| olofk | brstart-static.sh and brend-static.sh sets up and tears down an ethernet bridge | 18:26 |
| olofk | The bridge must be activated before or1ksim is started | 18:26 |
| olofk | And or1ksim must be set up to use tap instead of files, but it sounds like that was already taken care of | 18:27 |
| Findeton | uhm | 18:27 |
| Findeton | lets try that | 18:27 |
| olofk | Hmm.. there are brstart.sh and brend.sh as well | 18:28 |
| olofk | Can't remember what the difference is | 18:28 |
| stekern | olofk: yes, it was in an old version of the arch spec. as to why it was removed, no idea, perhaps mr Lampret didn't feel like it was ready for the masses and planned on adding it back at a later stage... and then it never happened | 18:29 |
| olofk | stekern: Oh, so it's that old? | 18:29 |
| stekern | yup | 18:29 |
| Findeton | anyway, I'm using the 2011 virtualbox machine so maybe it doesn't have those scripts | 18:30 |
| olofk | Findeton: Could be. You can get them here if you want to take a look yourself http://opencores.org/websvn,listing?repname=openrisc&path=%2Fopenrisc%2Ftrunk%2For1ksim%2F#path_openrisc_trunk_or1ksim_ | 18:30 |
| Findeton | thanks olofk, lets see | 18:32 |
| stekern | olofk: the note about removing the chapter is in the changelog in the latest spec: http://pastie.org/8996818 | 18:32 |
| stekern | so, it was still at that "late" stage in his involvement, maybe he just felt that he would never implement it and therefore scratch it from the arch manual... | 18:34 |
| Findeton | wtf I actually can't find the "openrisc directory" in the virtualbox | 18:36 |
| Findeton | I see a directory with the linux kernel files and so on | 18:37 |
| olofk | Findeton: Haven't used that VM in a while. What are you looking for? | 18:37 |
| Findeton | I think I just can't find my ass | 18:37 |
| Findeton | well you gave me a link to the openrisc trunk and I'm trying to find those files in my system, but I'll just download the script and run it | 18:38 |
| Findeton | but this is the virtualbox for openrisc, I should have a(n old) copy of the trunk lol | 18:39 |
| olofk | Findeton: I think the scripts might have been added after the VM was built | 18:44 |
| olofk | I think LoneTech knows the structure of the VM best. IIRC he was involved with creating it | 18:45 |
| olofk | But yeah, downloading the scripts is probably the quickest solution | 18:45 |
| olofk | Or just run the commands in the scripts manually | 18:46 |
| Findeton | Usage: ./brstart-static.sh <username> <groupname> <bridge> <eth> <tap> | 18:46 |
| olofk | Can't help you with your ass unfortunately. | 18:46 |
| Findeton | so what, ./brstart.sh openrisc users br0 eth0 tap0 | 18:47 |
| olofk | I would guess so | 18:47 |
| stekern | sounds right | 18:47 |
| olofk | It seems you need bridge-utils, openvpn and iptables, so make sure those are installed | 18:48 |
| Findeton | yeah ok | 18:49 |
| Findeton | $ sudo ./brstart.sh openrisc openrisc br0 eth0 tap0 | 18:55 |
| Findeton | eth0: error fetching interface information: Device not found | 18:55 |
| Findeton | eth0: error fetching interface information: Device not found | 18:55 |
| Findeton | eth0: error fetching interface information: Device not found | 18:55 |
| Findeton | Sat Apr 5 20:51:59 2014 TUN/TAP device tap0 opened | 18:55 |
| Findeton | Sat Apr 5 20:51:59 2014 Persist state set to: ON | 18:55 |
| Findeton | interface eth0 does not exist! | 18:55 |
| Findeton | Failed to create eth0 | 18:55 |
| Findeton | okay, it looks like it's eth8 from dmesg | more | grep eth | 18:56 |
| Findeton | lets see what happens when I run openrisc | 18:56 |
| Findeton | PING 192.168.1.1 (192.168.1.1): 56 data bytes | 18:57 |
| Findeton | ERROR: Failed to write Ethernet packet data: Bad file descriptor. | 18:57 |
| Findeton | and I don't know how to kill ping from the xterm | 18:57 |
| olofk | Findeton: Are you sure that or1ksim.cfg is setup to use tap? | 18:58 |
| Findeton | yeah I think I know what is happening | 18:59 |
| olofk | Good. Because I haven't got a clue :) | 18:59 |
| Findeton | I need brend | 19:00 |
| Findeton | because not everything was right when I run brstart | 19:00 |
| Findeton | device br0 already exists; can't create bridge with the same name | 19:01 |
| Findeton | Failed to create br0 | 19:01 |
| Findeton | maybe it created br0, but when it did it was with eth0 which doesn't exist | 19:01 |
| Findeton | and then I try with eth8 but br0 already exist | 19:02 |
| Findeton | I have to remove br0 and run the script right with eth8 | 19:02 |
| olofk | ah ok | 19:02 |
| Findeton | if it makes sense, because I'm not sure xd | 19:04 |
| Findeton | now it looks fine | 19:06 |
| Findeton | $ sudo /home/openrisc/brstart.sh openrisc users br0 0th8 tap0 | 19:06 |
| Findeton | Sat Apr 5 21:05:54 2014 TUN/TAP device tap0 opened | 19:06 |
| Findeton | Sat Apr 5 21:05:54 2014 Persist state set to: ON | 19:06 |
| Findeton | but ping still doesn't work lol | 19:06 |
| Findeton | same thing happens: bad descriptor | 19:06 |
| Findeton | this is my ethernet config for tap | 19:08 |
| Findeton | http://pastebin.com/T0cYf9PL | 19:08 |
| Findeton | I find openrisc very interesting because, at the speed the fpga runs, it looks like we are back to 1991 just when linux was created lol | 19:10 |
| olofk | Findeton: It | 19:10 |
| olofk | Findeton: It's actually slightly faster than that. Look here https://www.youtube.com/watch?v=BRr-BUbBV88 | 19:11 |
| Findeton | well | 19:13 |
| Findeton | that cat /proc/cpuinfo did give you 50MHz | 19:13 |
| Findeton | which is just right back to 1991 :p | 19:14 |
| olofk | Fair enough :) | 19:14 |
| Findeton | but it's fine for me | 19:14 |
| Findeton | I guess that if we wanted, we could use a more powerfull fpga | 19:15 |
| Findeton | up to about 400-500Mhz | 19:15 |
| Findeton | also, I don't know much about openrisc but it looks like it can have multiple cores and all that right? | 19:16 |
| Findeton | and that the normal dev board only supports one core | 19:16 |
| olofk | 400-500MHz is probably a bit too high, but I've built a stripped version of mor1kx for Virtex-6 and got it running at 200MHz at least | 19:16 |
| Findeton | but a good fpga could not only support 200Mhz but multiple cores right? | 19:16 |
| olofk | Yes. There's a project called optimsoc (http://www.optimsoc.org/) that has been working on multicore support | 19:17 |
| Findeton | and computers nowadays have too much power anyway lol | 19:17 |
| stekern | I for sure didn't have computers running at 50 MHz 1991 | 19:17 |
| Findeton | for what I know there were off the shelf computers running at 50MHz | 19:18 |
| Findeton | at that time | 19:18 |
| stekern | iirc 75 MHz pentiums were top-of-the-line 1995 | 19:18 |
| olofk | We had a DX2 66MHz, but that might have been 93 or 94 | 19:18 |
| Findeton | anyway | 19:18 |
| Findeton | it would be great to have an 300 Mhz multicore openrisc | 19:19 |
| stekern | yeah, I'm not saying there wasn't, just that the common ones you'd find at average Joes wasn't | 19:19 |
| Findeton | I think it could be a good computer for freedom advocates | 19:19 |
| Findeton | not only free software but free hardware :p | 19:19 |
| Findeton | with that kind of power you can do basic things like navigate and watch movies, and develop software too | 19:20 |
| Findeton | and the NSA would not be able to get inside your computer | 19:21 |
| olofk | And run RTL simulations :) | 19:21 |
| Findeton | yeah | 19:21 |
| Findeton | anyway, I cannot get this ping running lol | 19:21 |
| Findeton | I'm going to have dinner now see ya later guys | 19:21 |
| olofk | I finally got XST to use block ram for my wishbone RAM. But it's still using too many resources :( | 19:26 |
| olofk | I got a mor1kx, 16k RAM and 8 bits gpio | 19:27 |
| olofk | 8k doesn't work either, and I can't go lower unless I: | 19:31 |
| olofk | a) put _start lower than 0x1000 | 19:31 |
| olofk | b) Do some address decoding magic to avoid wasting like 4k on the interrupt vectors | 19:32 |
| olofk | stekern: Didn't you do some address magic for the sockit? | 19:32 |
| stekern | no, the allwinner guys did on the A31 | 19:33 |
| olofk | I thik I will do a special interrupt vector memory that implements 0x200, 0x400... as registers and returns wb_err for the other adresses | 19:34 |
| olofk | Or just mask the 8 lowest bits | 19:35 |
| olofk | Is it that simple or am I missing something? | 19:35 |
| stekern | the way their worked was that 0x100, 0x200... was mapped in to RAM | 19:36 |
| stekern | 0x104, 0x204... always returned 0x15000000 | 19:36 |
| stekern | everything else 0x0 | 19:37 |
| olofk | 15000000, is that nop? | 19:37 |
| stekern | yup | 19:37 |
| olofk | I'll do the same then | 19:38 |
| stekern | our libgloss is of course not compatible with that, so you'll have to roll your own crt | 19:39 |
| stekern | is that on the lx9? | 19:40 |
| olofk | yep, the lx9 | 19:40 |
| olofk | Hmm.. I don't understand the crt issue? | 19:40 |
| stekern | is there no other memory on it? | 19:40 |
| olofk | There is RAM, but I would prefer to get it running with only block ram to begin with | 19:41 |
| stekern | well, roll your own startup files | 19:41 |
| olofk | But why? | 19:41 |
| olofk | Are we using anything below 0x1000 that isn't 0x200, 0x400..? | 19:42 |
| olofk | (probably should objdump -d and find out myself) | 19:42 |
| stekern | no, but: https://github.com/openrisc/or1k-src/blob/or1k/libgloss/or1k/crt0.S#L76 | 19:42 |
| olofk | ahh.. reset | 19:43 |
| stekern | and 0x200, 0x300, 0x400.... is larger than 2 insn | 19:43 |
| olofk | Ok. it will be slightly hackier than I had expected, but I can probably still save some RAM here | 19:44 |
| olofk | 153 words for reset + 6 words for each exception vector | 19:45 |
| olofk | + some margin | 19:45 |
| stekern | yes, if you special case reset, 6 instructions per vector should be enough | 19:45 |
| olofk | Say 256 words => 1024 bytes | 19:45 |
| stekern | probably easier to make that 8 though | 19:45 |
| olofk | ...or! | 19:47 |
| olofk | I could just set an address to or1k_exception_handler and implement it all in hw | 19:48 |
| olofk | The exception vectors that is | 19:48 |
| olofk | That would require hacking crt0 though | 19:48 |
| olofk | Or do the exeption vectors differ between the C libraries (or whatever defines them)? | 19:48 |
| olofk | I'm just looking at a hello world dump that was built with or1k-elf | 19:49 |
| olofk | I mean, will the exception vectors for linux look different? | 19:49 |
| stekern | umm, newlib is newlib | 19:49 |
| stekern | linux is a completely different story | 19:49 |
| olofk | Just noticed that :( | 19:49 |
| stekern | but I doubt you'll be able to run Linux with 4KB RAM ;) | 19:50 |
| olofk | lol. Point taken :) | 19:50 |
| olofk | Yeah. I'm mostly doing this to get something running without having to fiddle with the coregen memory controller | 19:51 |
| olofk | I'm not as brave as you who runs without simulating | 19:51 |
| stekern | I'm not brave enough to simulate the MCB... | 19:52 |
| Findeton | 4KB RAM? that's not much lol | 19:53 |
| Findeton | is that memory fpga driven? | 19:53 |
| stekern | I've done it at some point, but at some point ISE broke the scripts I had to build the stuff for it, and then it took ~1 hour to build the core libs... | 19:54 |
| olofk | stekern: Which sim were you using then? | 19:55 |
| stekern | modelsim, which is another source of the problem | 19:56 |
| stekern | I don't have access to it | 19:56 |
| olofk | Yeah. Same here. isim is a no go. It's insanely slow and doesn't support VPI. Altera's modelsim version might possibly be able to use the Xilinx libs, but I doubt it | 19:59 |
| olofk | stekern: What's this for? mor1kx_simple_dpram_sclk | 20:04 |
| olofk | 256x100 bit RAM | 20:04 |
| stekern | it's used for several things | 20:05 |
| stekern | cache and mmu | 20:05 |
| olofk | Ahh.. it might be wise to disable the mmu's for now | 20:06 |
| olofk | newbie question. How do I calculate the cache sizes? From set_width, block_width, ways and limit width? | 20:07 |
| olofk | Yes! That did the trick. I got a .bit now | 20:10 |
| olofk | I'll celebrate that by pushing my ISE support | 20:13 |
| Findeton | shit I need to really get this tun tap thing working | 20:14 |
| Findeton | it still says bad file descriptor | 20:15 |
| olofk | We should add on your argument parser for 64 bit and ise path detection after that | 20:16 |
| olofk | Findeton: You got the bridge up and running now? | 20:17 |
| olofk | Not sure how it's supposed to work, but it looks like or1ksim will look for a tap0 device. Do you have that? | 20:18 |
| Findeton | yes, as far as I know | 20:18 |
| Findeton | $ sudo /home/openrisc/brstart.sh openrisc users br0 0th8 tap0 | 20:18 |
| Findeton | Sat Apr 5 22:18:19 2014 TUN/TAP device tap0 opened | 20:18 |
| Findeton | Sat Apr 5 22:18:19 2014 Persist state set to: ON | 20:18 |
| Findeton | I don't know how can I test it more than that | 20:18 |
| olofk | http://ejd021-linux.blogspot.se/2010/05/to-test-whether-tuntap-device-is.html | 20:19 |
| olofk | Seems like it's working :) | 20:19 |
| Findeton | maybe I should get the latest version of the or1ksim | 20:20 |
| olofk | Findeton: Yes. That might be it actually. And if you do, make sure to build it with --enable-ethphy | 20:21 |
| Findeton | yeah | 20:21 |
| Findeton | exactly | 20:21 |
| Findeton | that was what gave it away for me lol | 20:21 |
| olofk | stekern _franck__ juliusb: Where can I find the most awesome LED blinking program? | 20:26 |
| _franck__ | I have one here: http://www.elec4fun.fr/2011-03-30-10-16-30/2012-08-22-20-50-31/or1200-barebox-on-de1 | 20:27 |
| _franck__ | http://www.elec4fun.fr/downloads/led_blink.S | 20:28 |
| olofk | _franck__: Couldn't you at least have added one comment? :) | 20:31 |
| olofk | I'm trying to figure out how fast it should be blinking | 20:32 |
| _franck__ | look on the website | 20:32 |
| olofk | ah.. sorry :) | 20:32 |
| _franck__ | stekern: did you ever try to use vga_lcd with 8 bpp ? | 20:37 |
| Findeton | i'm doing a svn co http://opencores.org/ocsvn/openrisc/openrisc/trunk | 20:37 |
| olofk | Findeton: That might take a while | 20:37 |
| Findeton | is that too extreme? it's taking a lot of time | 20:37 |
| Findeton | yeah | 20:37 |
| stekern | _franck__: yes | 20:37 |
| olofk | Findeton: You can either just checkout openrisc/trunk/or1ksim or get it from github | 20:38 |
| _franck__ | stekern: ok, I just changed 16bpp -> 8 bpp and it stop working. Didn't try to find out why for now | 20:40 |
| stekern | are you using the upstream driver? | 20:41 |
| _franck__ | no | 20:41 |
| _franck__ | you told me I should | 20:42 |
| stekern | yes, you should | 20:42 |
| stekern | it's not working in the unupstream | 20:42 |
| stekern | that said, I actually don't think I ever got 8bpp working on my de0_nano LCD. The screen just started scrolling. | 20:43 |
| stekern | never figured out what was wrong | 20:43 |
| olofk | How does 8bpp work in VGA/LCD? Is it using a palette? | 20:44 |
| _franck__ | ok I'll try to find out. I really want to get my LCD to work | 20:44 |
| _franck__ | AFAIK, yes a Color look up table | 20:45 |
| stekern | yes, palette | 20:45 |
| olofk | I'm so fucking bad ass! I just figured out that I could cherry-pick a commit from one branch and apply to another | 20:51 |
| Findeton | well okay I get the latest or1ksim | 21:00 |
| Findeton | but how do I run linux with it? | 21:00 |
| olofk | Findeton: Same way as you did with the one you had in the VM? | 21:02 |
| stekern | olofk: I told you that last week =) http://juliusbaxter.net/openrisc-irc/%23openrisc.2014-03-30.log.html#t05:50 | 21:03 |
| olofk | stekern: Oh.. ok... damn! :( | 21:03 |
| Findeton | olofk: that was easy because the vm alreadid had everything done already :p | 21:04 |
| stekern | but since you didn't listen to me, I guess you can take the credit for figuring it out on your own now ;) | 21:04 |
| Findeton | I just run $ sim -f arch/openrisc/or1ksim.cfg vmlinux | 21:04 |
| olofk | stekern: I strongly suspect that I remembered it from last week somewhere in my head | 21:04 |
| olofk | Findeton: Shouldn't that be or32-elf-sim ? | 21:09 |
| olofk | Did you build and install it? | 21:09 |
| Findeton | yeah I built or1ksim | 21:09 |
| Findeton | I guess in 2011 it had another name? | 21:09 |
| stekern | nah, it's always been sim | 21:12 |
| stekern | unless you build it together with a toolchain | 21:12 |
| _franck__ | stekern: olofk : I started doing a test cores/systems in fusesoc | 21:20 |
| _franck__ | https://github.com/fjullien/fusesoc/commit/721568e6b90e1970044faa8b958062c5d766d1ea | 21:20 |
| _franck__ | It's full of copy/paste mistakes but feel free to comment | 21:20 |
| _franck__ | these are only working tests | 21:21 |
| Limb | Hey. I'm trying to adapt the board configs for a Nexys 4 (Artix7).. What would be the recommended base board to start modifying? | 21:26 |
| olofk | Limb: Your best option is to wait for a day or two. I'm just about to push support for building with Xilinx ISE and then stekern can push his Atlys port | 21:30 |
| olofk | Unless you need vivado support. We haven't done that yet | 21:30 |
| Limb | ISE support is just fine | 21:31 |
| Limb | What will be different with building with ISE now then it is currently? | 21:31 |
| olofk | Limb: There's no ISE support currently | 21:31 |
| olofk | Unless you are looking at orpsocv2 | 21:32 |
| Limb | To be honest I haven't a clue what I'm looking at really. I was following this guide: http://kevinmehall.net/openrisc/guide/ | 21:32 |
| Limb | Documentation seems to be all over the place. I figured I would've been able to build with ISE from the command line. I'm assuming this isn't correct? | 21:33 |
| olofk | Limb: Yes. We're sorry about the sad state of documentation. It's a bit messy :/ | 21:34 |
| Limb | Gotta start somewhere hehe | 21:35 |
| olofk | But yes, you can build with ISE manually. No problems | 21:35 |
| Limb | So you're going to push changes that would allow you to build with the ISE IDE? | 21:35 |
| Limb | stefan/orpsoc on the git repo, is this v1 v2 or v3? | 21:40 |
| olofk | Limb: v2 | 21:44 |
| olofk | There was an orpsocv3, but it has now transformed into fusesoc (which is what you want to use) | 21:44 |
| olofk | I really really need to write that clarifying blog post soon :) | 21:45 |
| Limb | Where is fusesoc located? | 21:45 |
| Limb | And would i be fine with v2? | 21:45 |
| olofk | github.com/olofk/fusesoc | 21:45 |
| olofk | We are working on deprecating orpsocv2 | 21:45 |
| olofk | Short back story: orpsocv2 was a big lump containing build scripts, software, or1200, a few cores and some other stuff | 21:46 |
| olofk | It turned out to be a bit painful to maintain as there were more cores and boards to support | 21:47 |
| olofk | So I started working on orpsocv3 which separated the build infrastructure from the RTL code | 21:47 |
| olofk | Along the way I realized that the build infrastructure didn't contain any OpenRISC-specific code, so I decided to rename it to fusesoc | 21:47 |
| olofk | fusesoc doesn't contain any RTL code. Instead it uses another repository called orpsoc-cores (github.com/openrisc/orpsoc-cores) | 21:48 |
| Limb | Ah. I can see why I'd want to use fusesoc haha | 21:49 |
| Limb | Can i mess around with it now? as in still be able to build from command line? | 21:49 |
| Limb | or should I really wait 2 days for that code push haha | 21:49 |
| olofk | If you want to get started right away you can export any of the supported systems and do the building step manually | 21:50 |
| olofk | stekern _franck__ : I pushed some quartus changes. Please tell me if I broke something. I rebuild de0_nano without any problems | 21:53 |
| olofk | Alright then. ISE support is pushed. stekern, it would be great if you could rebase your ISE patch to add the 64 bit selection and ise path stuff | 22:01 |
| olofk | And perhaps push the atlys port. Several people have asked for that one | 22:02 |
| olofk | oh... I forgot to update the documentation | 22:02 |
| olofk | I'll do that tomorrow | 22:02 |
| olofk | Good night for now | 22:02 |
| --- Log closed Sun Apr 06 00:00:53 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!