| --- Log opened Tue Sep 16 00:00:54 2014 | ||
| sb0_ | the two openrisc mailing lists are a mess | 02:21 |
|---|---|---|
| stekern | poke53282: the quickfloat conversions are only used for the filter, which I have turned off | 02:34 |
| stekern | sb0_: yes | 02:48 |
| poke53280 | dalias: I have corrected the input of the terminal. DEL finally works everywhere. | 03:03 |
| poke53280 | I still don't like the incompatibilities between the browser. Why do I have to send 0x1b, 0x5b, 0x35, 0x7e to the terminal for PAGE_DOWN | 03:05 |
| poke53280 | between the *terminals* I mean | 03:07 |
| poke53280 | stekern: I have implemented aligned memory access to see if descent1 is playable. The answer is a clear no. | 04:27 |
| stekern | poke53280: I'm going to go out on a limb here and assume you meant unaligned accesses :) | 04:52 |
| poke53280 | yes, unaligned | 04:53 |
| poke53280 | around 0.2 fps | 04:54 |
| poke53280 | with an undocumented function I get 1 fps. | 05:47 |
| poke53280 | http://pastie.org/9557974# | 05:47 |
| poke53280 | This is the most important part. | 05:47 |
| poke53280 | the scanline part of the rendering routine | 05:48 |
| poke53280 | looks more or less optimized for m | 05:49 |
| poke53280 | e | 05:49 |
| poke53280 | except of this first if then | 05:51 |
| poke53280 | yes, it's indeed the perspective correction for the texture that takes most of the time. | 05:56 |
| poke53280 | I can make a version with flat textures :) | 05:56 |
| olofk | poke53282: As a compromise you can use billboarding. Then you get a little perspective correction on one axis at least :) | 06:57 |
| poke53280 | even without perspective correction it's too slow. Maybe I can remove the lightning. | 07:09 |
| poke53280 | But I am afraid it will run smoothly only without textures | 07:10 |
| olofk | descent without textures and light sounds like a fun experience :) | 07:10 |
| poke53280 | lightning for every drawn polygon is still possible then. | 07:13 |
| poke53280 | Another possibility would be to execute an fixed function unit for the scanline rendering. | 07:15 |
| poke53280 | Or to use opengl to webgl converter. Well, maybe next year. | 07:15 |
| olofk | stekern: Yes! I'm in the space for whitespace camp as well. Main reason: The usage of tabs doesn't seem to be consistent for the verilog mode even between emacs versions, and I'm not sure there are any equivalent modes for other editors | 07:18 |
| poke53280 | Or I reduce the resolution to 320x200. | 07:18 |
| olofk | poke53282: 320x200 is the only resolution that has ever made sense to me :) | 07:18 |
| olofk | Can jor1k scale the buffer for you? | 07:19 |
| poke53280 | No really, sdl does not do it. jor1k could do it with a special option. | 07:19 |
| poke53280 | for frontier I changed the source to scale by a factor of two. | 07:20 |
| poke53280 | This is very fast. | 07:20 |
| olofk | But it should be even faster to do that in js on the final framebuffer I guess? | 07:21 |
| poke53280 | Yes, of course. | 07:21 |
| olofk | And wouldn't require any hacks for games that only support 320x200 | 07:21 |
| poke53280 | Unfortunately Linux framebuffers don't have such. The easiest would be to provide a second framebuffer with 320x200 | 07:22 |
| olofk | aha. Didn't know that | 07:22 |
| poke53280 | .... don't have such a feature | 07:22 |
| poke53280 | Let me think about it. 320x200 is maybe possible with a little effort. | 07:24 |
| poke53280 | But this would give me maybe 4fps with textures. | 07:24 |
| poke53280 | I wonder why. | 07:26 |
| poke53280 | 320x200 should run smoothly. Ok, no asm is used. | 07:26 |
| poke53280 | and we use 32 bit for the buffer. | 07:26 |
| poke53280 | anyway, olofk. I you want to play around try http://jor1k.com/jor1k | 07:31 |
| poke53280 | type "d1x-rebirth" | 07:31 |
| poke53280 | or d1x-rebirth -tmap quad | 07:31 |
| poke53280 | wait, I have to copy the correct files | 07:32 |
| poke53280 | now | 07:33 |
| olofk | poke53282: -tmap quad does what? | 07:35 |
| olofk | And how do you measure FPS? | 07:35 |
| poke53280 | it changes the algorithm for the textures. | 07:36 |
| poke53280 | This is undocumented. | 07:36 |
| poke53280 | -tmap fp is also possible | 07:36 |
| poke53280 | -tmap c is standard | 07:36 |
| olofk | Back after a reboot. Descent killed my computer :) | 07:37 |
| poke53280 | ? | 07:38 |
| olofk | Well, not really, but the charger is a bit flaky so I ran out of batteries | 07:38 |
| poke53280 | maybe your browser | 07:38 |
| olofk | But it took me a few seconds to realize that. | 07:38 |
| olofk | Any way to skip the insanely long intro? | 07:39 |
| poke53280 | ESC | 07:39 |
| olofk | Ah.. worked now. Thought I had tried that | 07:39 |
| poke53280 | you have several option in "d1x-rebirth -help" | 07:40 |
| olofk | And how to accelerate? Haven't played for like fifteen years | 07:40 |
| poke53280 | Also there is a config file .d1x-rebirth/descent.cfg | 07:40 |
| olofk | I'm getting 2 FPS as well here btw | 07:40 |
| olofk | More fun than usable right now | 07:41 |
| poke53280 | try without -tmap quad | 07:41 |
| poke53280 | and it will be really slow | 07:41 |
| olofk | Unlike the ultra fast experience I'm having now, you mean? | 07:42 |
| poke53280 | yes :) | 07:42 |
| poke53280 | and I don't know what is acceleration here | 07:42 |
| poke53280 | key 'a' | 07:43 |
| poke53280 | I get two fps too. | 07:44 |
| poke53280 | So with 320x200 it might be playable | 07:44 |
| poke53280 | for some reason he don't accept 320x200 | 07:49 |
| stekern | olofk: (between emacs versions) yes that's what I figured when looking through the code, even code that I have written is inconsistent, and I believe it's because of that | 07:59 |
| stekern | I've fixed my .emacs to just do spaces now | 08:00 |
| olofk | stekern: I found a lisp script to do that for me. Problem with the one I found was that it automatically converted the files as soon as I opened them, which was a bit painful | 08:02 |
| olofk | stekern: And my FIFO test bench currently loses 48/64 words when I send them through the FIFO. That's good enough, right? :) | 08:03 |
| stekern | I've got this now for mor1kx dev: http://pastie.org/9558181#26-30 | 08:04 |
| stekern | did you fix the 're' thing? | 08:04 |
| stekern | and enabled the bypass? | 08:04 |
| olofk | Same result | 08:06 |
| olofk | Not sure I have all the patches though | 08:06 |
| olofk | It sucks that gtkwave can't read 2d arrays | 08:08 |
| olofk | I always fire up modelsim for that, but it's a bit annoying to switch tools just for that | 08:08 |
| olofk | ah wait. The re signal is still hard coded to 1 | 08:09 |
| olofk | When it should really be connected to... [fill in the blanks] | 08:12 |
| olofk | Actually, read side looks ok | 08:15 |
| olofk | and write side too :( | 08:16 |
| olofk | Ahh.. the RAM wraps around | 08:19 |
| olofk | Why is writing and testing a FIFO so damn complicated? | 08:21 |
| olofk | Hmm.. looks like the FIFO still accepts a write even when it's full | 08:26 |
| olofk | Better. Now I only lose 9/64 words | 08:33 |
| olofk | Damn. I overshot. Now I'm getting more words back than I put in | 08:39 |
| stekern | olofk: didn't you just copy the new storebuffer from mor1kx as the FIFO? | 08:52 |
| stekern | http://oompa.chokladfabriken.org/openrisc/fifo/simple_dpram_sclk.v | 09:12 |
| stekern | http://oompa.chokladfabriken.org/openrisc/fifo/fifo.v | 09:13 |
| olofk | I just copied simple_dpram_sclk. Copying the fifo now | 09:13 |
| olofk | But I've spent most of the time debugging my FIFO writer BFM | 09:14 |
| stekern | the new simple_dpram_sclk should be indentical to the old if you tied re to '1' | 09:14 |
| olofk | I'll hold off the copying until I've sorted out the bugs in my BFM. That's where the problem is right now | 09:15 |
| stekern | yeah, just that you don't have a non-working mix between the old and new fifo/dpram, that's probably wise | 09:18 |
| olofk | verilog has way too many equivalent operators. I'm trying to understand why my while loop doesn't abort even though I clearly can prove that the condition is not fulfilled | 09:18 |
| olofk | Ah now I see it. What the hell was I thinking? | 10:08 |
| * olofk ! Overcomplicating things since 1982! | 10:09 | |
| olofk | stekern: The files that you linked above does not work for me | 10:38 |
| stekern | olofk: remember, a simple solution to a complicated problem is much more impressive than a complicated solution to a simple problem | 10:38 |
| stekern | olofk: they were only meant as a reference to show what I was speaking about, I didn't test them | 10:39 |
| stekern | what is the problem with them though? | 10:39 |
| stekern | also note that I updated them after I pasted the link, since I had forgot to change the name of the rd_en_i and wr_en_i signals | 10:41 |
| olofk | Haven't checked what's wrong yet, but I suspect it's the full logic | 10:46 |
| stekern | it should be completely equivalent to the old | 10:52 |
| stekern | the full logic I mean | 10:52 |
| olofk | I see errors when I set a write rate higher than the read rate, but I need to look deeper | 10:56 |
| stekern | is that in the stream_writer or stream_reader? | 10:58 |
| stekern | or is it just pure FIFO tb? | 10:58 |
| stekern | and is it through the fwft FIFO, or pure fifo? | 10:59 |
| olofk | I've mostly tested fifo_fwft | 11:04 |
| olofk | The writer is equivalent, but I have only implemented a fwft_reader | 11:04 |
| olofk | Your FIFO code works for me now | 11:04 |
| olofk | I replaced both instances of wr_en_i with wr_en_i & !full_o | 11:05 |
| olofk | In my world it makes no sense to allow writes to a full FIFO | 11:05 |
| olofk | But I'm not sure what's the common view here | 11:05 |
| olofk | Hmmm.. I could of course do that outside of the FIFO instead if someone really really wants to be able to mess up their FIFO | 11:06 |
| olofk | Doh.. I never actually tested your FIFO | 11:09 |
| stekern | yeah, the 'fifo' (storebuffer) assumes that no-one is so silly that they try to write to a full FIFO | 11:09 |
| olofk | Well, your FIFO works | 11:10 |
| stekern | because IMO doing wr_en_i & !full_o, doesn't make sense neither | 11:10 |
| stekern | and just add overhead logic (even if it in the end is just on a source level) | 11:10 |
| olofk | Yeah. You still need to implement the same logic outside of the FIFO | 11:11 |
| stekern | because, you still need logic outside the FIFO to pushback the writer | 11:11 |
| stekern | since that write got lost anyway | 11:11 |
| olofk | Weird thing now is that my additions doesn't seem to do any differnce | 11:12 |
| stekern | what you migh want to add though, is a "WARNING" $display on the wr_en_i & full_o condition | 11:14 |
| olofk | Ahh.. I have the same condition in fifo_fwft :) | 11:14 |
| stekern | and read_en_i & empty & !wr_en_i | 11:15 |
| olofk | Yeah. That might be a good idea | 11:15 |
| olofk | Finally it's not working anymore! | 11:16 |
| stekern | mmm, things that work are no fun to tinker with | 11:18 |
| olofk | Especially when they are supposed to be broken | 11:19 |
| olofk | Ok, so I'm pushing the updated FIFO now based on yours with `OR_ASYNC_RST removed and rearranged the always @(posedge) block a little | 11:20 |
| olofk | Let's see what broke in wb_streamer then :) | 11:23 |
| olofk | Nothing so far | 11:24 |
| olofk | stekern: There was some bug in wb_stream_writer that I was supposed to fix before I dove down in the FIFO stuff. Can you remember what it was and if it's still there? | 11:29 |
| olofk | Ah.. I added the busy flag in the ctrl module, but haven't hooked it up yet | 11:31 |
| stekern | olofk: yeah, sorry, I didn't get around to do any proper patches for you yesterday | 11:32 |
| olofk | I'll do some other stuff in the meantime. | 11:36 |
| maxpaln | Howdy all, I have a question on the way the arbiter addressing works - | 12:25 |
| maxpaln | we are starting to debug a peripheral on the wishbone bus that has a large size (0x100000). But we are finding that any accesses above 0x0000001F cause a bus error. Haven't debugged the root cause yet but wondered if it could be related to the way I have set up the arbiter addressing. | 12:27 |
| maxpaln | I am looking in wb_intercon.v to try and correlate the MATCH_MASK with the address space I've attempted to allocate to the peripheral | 12:28 |
| maxpaln | that all make sense for the smaller peripherals - but the one for my large peripheral looks odd | 12:28 |
| maxpaln | Here is the .conf file entry: | 12:28 |
| maxpaln | [slave hostif0] | 12:28 |
| maxpaln | datawidth=32 | 12:28 |
| maxpaln | offset=0x93000000 | 12:28 |
| maxpaln | size=100000 | 12:28 |
| maxpaln | And here is the entry in the wb_intercon.v: | 12:29 |
| maxpaln | wb_mux | 12:29 |
| maxpaln | #(.num_slaves (5), | 12:29 |
| maxpaln | .MATCH_ADDR ({32'h00000000, 32'h90000000, 32'h93000000, 32'hb0000000, 32'hc0000000}), | 12:29 |
| maxpaln | .MATCH_MASK ({32'hfe000000, 32'hffffffe0, 32'hfffe7960, 32'hfffffff8, 32'hfffffff8})) | 12:29 |
| maxpaln | wb_mux_or1k_d | 12:29 |
| maxpaln | The mask for the 3rd peripheral looks incorrect based on the address and size in the .conf - although I am not too familiar with how translation from .conf to the arbiter works. | 12:30 |
| olofk | Yeah, that does look wrong | 12:30 |
| olofk | But 100000 is decimal,right? | 12:30 |
| olofk | You need powers of two for size | 12:31 |
| maxpaln | aaargh, I forgot to add the hex qualifier on the size!! | 12:31 |
| olofk | wb_intercon_gen should warn for that | 12:31 |
| maxpaln | grrrr! | 12:31 |
| maxpaln | I don't think I saw a warning when I ran wb_intercon_gen | 12:32 |
| maxpaln | I'm about to rebuild. I'll check then. | 12:32 |
| olofk | "should warn" means "should warn, but that's not implemented yet" | 12:33 |
| maxpaln | :-) ah I see | 12:34 |
| maxpaln | well, I can confirm it doesn't warn right now :-) | 12:34 |
| olofk | so how's it going otherwise? | 12:35 |
| maxpaln | good - I'm with the customer at the SW house that will be doing the linux development | 12:35 |
| olofk | Great | 12:36 |
| maxpaln | Linux is behaving as expected, the processor is holding up well. I am nearing the stage where I can focus on the broader job of producing some ports for our eval boards | 12:36 |
| olofk | awesome | 12:36 |
| maxpaln | Thankfully these guys have a lot of embedded Linux experience - | 12:37 |
| olofk | That helps :) | 12:37 |
| maxpaln | a lot - better than my mickey mouse attempts at Linux development! :-) | 12:37 |
| stekern | olofk: time to stop doing other stuff | 12:39 |
| olofk | stekern: Ok. Hungry baby will have to wait | 12:39 |
| stekern | that's the spirit! | 12:40 |
| olofk | I should teach her autotools, so she can 'make food' herself | 12:41 |
| olofk | well, 'sudo make food' since a lot of the ingredients require elevated privileges to reach | 12:41 |
| stekern | our girl is big enough to use a stool to elevate her privileges | 12:43 |
| olofk | Ah, I see. We haven't added our girl to the furniture group yet | 13:18 |
| olofk | gtg bbl fyi | 13:19 |
| * olofk is down with the kids! | 13:20 | |
| stekern | yeah, don't, our violated her priviliges with permanent markers on our white leather sofa... | 13:29 |
| poke53282 | stekern: Did you solve the tinysid problem? | 15:53 |
| stekern | nope | 15:54 |
| poke53282 | does the problem also occur when you compile for x86? | 15:56 |
| stekern | don't know, but the same code worked for arm 5 years ago | 15:57 |
| poke53282 | well, you should test it, or I will test it. | 16:02 |
| stekern | is that a threat? ;) | 16:17 |
| poke53282 | Hehe, sounds for me | 16:21 |
| poke53282 | You will waste my precious time with this task. | 16:22 |
| olofk | stekern: Did you prepare patches, or did you just | 16:26 |
| olofk | want me to stop doing other things? | 16:26 |
| stekern | olofk: I did a pull request | 16:31 |
| olofk | Aha. I usually get mails for these kind of things so I never checked github | 16:37 |
| olofk | C00l. I'll test and report back later tonight | 16:38 |
| olofk | Seems to work so far. Tried 100000 reads with different burst size, buffer size and start address. I'll update the test bench to test IRQ stuff too before I push | 16:42 |
| olofk | Interested to see your bare metal driver as well | 16:43 |
| stekern | olofk: http://oompa.chokladfabriken.org/openrisc/wb_streamer_test/ | 17:20 |
| stekern | all streamer stuff is in main.c | 17:24 |
| olofk | stekern: urgh.. C? Why did you choose that? You could have used Chisel instead. Everybody uses Chisel | 17:45 |
| olofk | And Labview of course | 17:45 |
| PaulfraOSAA | If I compile a simple program (Hello, world) with or1k-elf-gcc -mnewlib -mboard=or1ksim simple.c -o simple I should be able to simulate it using or1k-elf-sim simple, right? | 17:48 |
| olofk | PaulfraOSAA: Never used or1k-elf-sim actually. Your friend here is or1ksim | 17:52 |
| olofk | ah wait.. that IS or1k-elf-sim | 17:52 |
| PaulfraOSAA | yes... | 17:55 |
| PaulfraOSAA | The problem is I keep getting ERR: 8-bit program load out of memory area: ${count++} | 17:55 |
| olofk | Yeah, that's probably because of the stupid default settings. Are you using a config file? | 17:56 |
| olofk | or1k-elf-sim -f <config file> <elf> | 17:56 |
| olofk | There is a reasonable default file in the linux tree for example | 17:56 |
| PaulfraOSAA | Yes, but it should be using the default config file right? And that should be the -mboard=or1ksim one, or am I mistaken? | 17:56 |
| olofk | No, that should be the correct mboard parameter. I think that it's default though so you can skip it for or1ksim | 17:57 |
| PaulfraOSAA | Well, apparently I can't ;) | 17:58 |
| olofk | But what does your or1ksim config file look like? Could you paste it? | 17:58 |
| PaulfraOSAA | otoh, I can't find any config files at all | 17:58 |
| olofk | I'll give you one | 17:58 |
| PaulfraOSAA | tnx | 17:59 |
| olofk | http://git.openrisc.net/cgit.cgi/jonas/linux/plain/arch/openrisc/or1ksim.cfg | 17:59 |
| PaulfraOSAA | oh, why didn't i figure _that_ one out myself XD | 18:00 |
| olofk | PaulfraOSAA: Have you considered joining us at orconf in Munich btw? | 18:02 |
| PaulfraOSAA | OK, that really hit the spot, now I just need to figure out how to generate one for the lx9_microboard | 18:02 |
| PaulfraOSAA | My gf went to Munich for the geocaching event, the travel time seems... prohibitive | 18:03 |
| PaulfraOSAA | btw I'm just learning, maybe a developer conference is a bit over the top right now :) | 18:03 |
| olofk | PaulfraOSAA: Yeah, haven't checked the travel time. Thought it would be a breeze from København. | 18:04 |
| olofk | But we usually run a workshop which has been a quite popular way to get people up to speed with the tools | 18:04 |
| PaulfraOSAA | Even more from Århus (where I'm situated), but still. | 18:05 |
| olofk | But to answer your previous question. You could probably use the board file for ordb2a for example | 18:05 |
| olofk | aha | 18:05 |
| olofk | The file mostly specifies which uart driver to use for stdio, and the hw base address for it | 18:06 |
| PaulfraOSAA | I started reading up on makefiles today, it reminded me of a JFK quote, that also comes in handy here: "We choose to do this, not because it is easy; but because it is hard" | 18:06 |
| olofk | :) | 18:06 |
| olofk | make love not war | 18:06 |
| olofk | My first attempt at doing what later became FuseSoC was completely based on makefiles. I gave up after about a year and redid it from scratch | 18:07 |
| olofk | stekern: Have you tested the improved writer in hw? | 18:11 |
| PaulfraOSAA | It seems a workable simulation file is also available in or1ksim source folder :) | 18:17 |
| olofk | Ah yes. Didn't think of that :) | 18:19 |
| PaulfraOSAA | It seems it shoud be possible to get most of those values from the configuration used by fusesoc, shouldn't it be a part of the build process? (He said expecting to get told that it is open source and he should go do it) | 18:21 |
| olofk | No, you're right. Just hasn't been done yet | 18:22 |
| olofk | Device tree generation is another thing that could be done with that | 18:23 |
| olofk | But then it needs to be more expressive, and I don't really want to implement a new complicated format. Might do it the other way around instead and use device trees for input | 18:24 |
| stekern | olofk: no, not yet | 18:28 |
| stekern | I can do a build now | 18:28 |
| stekern | or did you mean my changes? if so, yes | 18:29 |
| olofk | Cool. I meant your changes | 18:29 |
| olofk | Updating the testbench to match your main.c behaviour | 18:30 |
| olofk | What would be really cool is if I could use that directly | 18:30 |
| olofk | Like embedding or1ksim in the simulation | 18:31 |
| olofk | Maybe I should do a PhD. They seem to have time to do all kinds of shit | 18:32 |
| * olofk misses memory allocation from VHDL right now | 18:34 | |
| olofk | Added basic IRQ support in the tb now. Works fine | 18:39 |
| olofk | stekern: Pushed now. Could you just take a quick look at the test_main task in the tb and see if that's how it's supposed to be used | 18:49 |
| PaulfraOSAA | If I were to simulate my own peripheral, I would do something like the generic section and just look at what adresses got written to? | 18:49 |
| olofk | PaulfraOSAA: In or1ksim? | 18:50 |
| PaulfraOSAA | Yes | 18:50 |
| olofk | I haven't done that, so I'm unsure how to use it | 18:50 |
| PaulfraOSAA | Ok, I guess I'll find out when the time comes then | 18:50 |
| olofk | One problem would be how to respond to reads of course | 18:50 |
| olofk | I would start with doing pure RTL simulations in icarus or modelsim. We have BFMs to simulate wishbone transfers | 18:52 |
| olofk | Which happens to be exactly what I've been using in the new wb_stremer testbench | 18:52 |
| stekern | olofk: looks right to me | 18:58 |
| stekern | you should change REG_ENABLE to REG_CSR or something though | 18:58 |
| olofk | stekern: Control Status Register? | 19:00 |
| stekern | yes | 19:05 |
| olofk | makes sense | 19:05 |
| stekern | I realised you might want to have an interrupt-enable bit in there too | 19:05 |
| olofk | True | 19:06 |
| stekern | if the irq sink is unable to do masking itself | 19:06 |
| olofk | You can still use polling then, right? | 19:06 |
| stekern | yes, you can still use that with the irq enabled but masked out in the (or1k) PIC too | 19:07 |
| olofk | Options are great, except for when you want to add tests for them :) | 19:08 |
| stekern | either by polling the irq bit or the busy bit | 19:08 |
| olofk | So, I'm thinking about pushing a mor1kx-2.2.core to orpsoc-cores. Any reasons not to? | 19:09 |
| olofk | mor1kx tracking master will still be there | 19:09 |
| stekern | no, I think that makes sense | 19:10 |
| olofk | I think that most systems except for mor1kx-generic could depend on that as well | 19:10 |
| stekern | I agree | 19:11 |
| olofk | Should we enable FEATURE_ROR in mor1kx-generic? | 19:14 |
| stekern | sure, we can do that | 19:30 |
| stekern | I think as much as possible should be enabled in mor1kx-generic | 19:31 |
| olofk | Me too | 19:31 |
| PaulfraOSAA | What does the m stand for? more or minimal? | 19:31 |
| olofk | I'm running through all the or1k-tests with mor1kx-generic in icarus now | 19:31 |
| stekern | PaulfraOSAA: it's supposed to be pronounced moron-ekx | 19:33 |
| PaulfraOSAA | o.. k... | 19:34 |
| stekern | without the m, that coincident wouldn't be fun ;) | 19:34 |
| olofk | Named after it's authors :) | 19:34 |
| stekern | more seriously, I think it was meant to mean modular | 19:34 |
| stekern | but more and minimal fits as well | 19:35 |
| olofk | juliusb is terrible with coming up names :) | 19:35 |
| PaulfraOSAA | Ok, then the ROR should be an installable module ;) | 19:35 |
| stekern | it's completely cloud-based | 19:35 |
| PaulfraOSAA | olofk: Is it by design that your lx9_tb.v contains just about nothing? | 19:36 |
| stekern | olofk's idea | 19:36 |
| olofk | PaulfraOSAA: Most test cases we run are just elf files | 19:36 |
| olofk | So test benches mostly contain BFM models for the external peripherals and a way to load an elf file | 19:37 |
| olofk | In the lx9 case I think it's only a RAM model | 19:37 |
| olofk | stekern: The following testcases appeared to get stuck with mor1kx-generic. alignillegalinsn, intmulticycle, inttickloop, intloop, intsyscall, tickrfforward | 19:38 |
| PaulfraOSAA | ok, I'm looking into what it would take to add uart, just as an exercise. And I just stumbled upon it. | 19:38 |
| stekern | olofk: yes, but we don't have the int generator in mor1kx-generic, do we? | 19:39 |
| olofk | Yeah, I suspect that's the case for the int* test cases at least | 19:39 |
| stekern | alignillegalinsn... hmm... let me check that one | 19:40 |
| stekern | oh... I think I need/want to finish _florent_'s patches before I test that | 19:41 |
| olofk | Yeah, that's probably more important | 19:42 |
| stekern | cool, seems like you are now able to invite people to github teams you are a member of without intervention from an owner | 19:45 |
| olofk | That's handy for projects where team leaders just disappear | 19:46 |
| stekern | or maybe even members can just invite other people | 19:46 |
| olofk | hmm.. doess gcc optimize pure asm code? | 19:46 |
| stekern | yes and no | 19:46 |
| olofk | The trace log (and objdump) shows an l.sfne instruction, but that's nowhere in the asm code | 19:47 |
| olofk | ahh.. I missed some #include's | 19:48 |
| stekern | aha, you mean an .S file? | 19:48 |
| stekern | then only no | 19:48 |
| olofk | hmm.. trace looks very weird | 19:54 |
| stekern | olofk: alignillegalinsn makes assumptions about dbus error exceptions that's not valid | 19:55 |
| olofk | either mor1kx executes the same instruction twice, or the monitor gets confused somewhere | 19:55 |
| stekern | the monitor definetely get confused... it needs some rework | 19:55 |
| olofk | Internal pipeline changes? | 19:55 |
| olofk | ...that causes confusion | 19:56 |
| stekern | I think I never got it fully working with mor1kx of late | 19:56 |
| stekern | err cappuccino of late I mean | 19:57 |
| olofk | It's a really handy tool, but I understand that it's a bit messy to sync it to the RTL | 19:57 |
| stekern | of late == after I changed juliusb's initial 4 stage implementation | 19:57 |
| olofk | aha | 19:58 |
| olofk | That's like sometime in the early lateies | 19:58 |
| stekern | iow, I never got it fully working with cappuccino, because it expects that everything is done by the end of execute stage | 19:58 |
| stekern | but it probably have became even worse with the branch prediction | 19:59 |
| stekern | but as long as you now that it will give duplicate instructions here and there and that the load/store results are mostly bogus, it's still useful | 20:00 |
| stekern | s/now/know | 20:00 |
| stekern | the monitor should really just bring all info it needs all the way up to write-back and then dump the info from there | 20:02 |
| stekern | olofk: I'm waiting for someone to find the current situation not good enough that will fix it *hint, hint* | 20:04 |
| stekern | =P | 20:05 |
| olofk | :) | 20:06 |
| olofk | Duplicate instructions are fine, but what's up with this? | 20:06 |
| olofk | S 00000200: 14000000 l.nop 0x0000 flag: 1 | 20:06 |
| olofk | 14000000 isn't a nop, right? | 20:06 |
| stekern | it's a nop, but an internal one | 20:06 |
| olofk | A secret extra fast nop perhaps? :) | 20:07 |
| olofk | It's still not what's supposed to be at 0x200 though | 20:07 |
| stekern | it's what get's pushed into the pipeline when a bubble is created | 20:08 |
| olofk | aha | 20:08 |
| stekern | -'s | 20:08 |
| stekern | so it's just exposing about too much about its internal state there | 20:08 |
| stekern | a little to much... | 20:09 |
| stekern | too | 20:09 |
| olofk | :) | 20:09 |
| stekern | why is linkedin suggesting that I should join the "Textile, Apparel, Footwear & Fashion" group? | 20:10 |
| olofk | Well, I guess someone should burst that bubble because that's all I get on the last 1400 lines of the trace log until I aborted the test manually | 20:11 |
| PaulfraOSAA | stekern: Theyv'e been looking at your google history ;) | 20:11 |
| olofk | I looked up what google thinks I'm interested in. Apparently I'm a big fashionista | 20:11 |
| stekern | then the million dollar question is, who's been using google on my computer then? =P | 20:12 |
| * olofk steps slowly away from or1k-alignillegalinsn | 20:12 | |
| olofk | stekern: You got designer in your title. I got that as well and keep getting all kinds of unrelated suggestions | 20:13 |
| stekern | I will just assume that my wife is to blame here (she blames me for everything else, so it's just fair) | 20:13 |
| PaulfraOSAA | Ok, late. Hopefully I'll be able to look further into adding peripherals during the weekend. | 20:14 |
| olofk | PaulfraOSAA: You know where to find us | 20:14 |
| PaulfraOSAA | Will documenting it on our hackerspace's wikipage be good, or is there some better place to throw it up? (as long as it's not the opencores website, that looks as if stuff is really thrown up) | 20:15 |
| olofk | PaulfraOSAA: That's fine. The OpenCores wiki is where we keep stuff like this, but I understand why you don't want to use it | 20:22 |
| olofk | Just send us a link and we'll add it to the relevant places | 20:23 |
| olofk | Like on my awesome blog (olofkindgren.blogspot.com) | 20:23 |
| olofk | poke53282: Next ID Software challenge! Commander Keen just got open sourced https://github.com/keendreams/keen | 20:24 |
| olofk | Oh, and I read this earlier today. Makes our doom port look a bit bleak http://www.bbc.com/news/technology-29203776 | 20:25 |
| poke53282 | Yes, I read this news too. But well. To run it on such a printer is more easy than on OpenRISC. | 20:26 |
| poke53282 | Here it took 15 years of combined effort. | 20:27 |
| poke53282 | Commander Keen uses assembler. At least it looks like. | 20:27 |
| poke53282 | Do you want to port it? | 20:27 |
| olofk | From x86 assembler? No fucking way! | 20:27 |
| poke53282 | The x86 instruction set is not so bad. Just an April fool that become serious. And the developers still laugh about us. | 20:30 |
| olofk | :) | 20:30 |
| poke53282 | But hey, the whole instruction sets fits in 4kb of C source. | 20:32 |
| poke53282 | I can't find the data. | 20:35 |
| poke53282 | for this guess. | 20:35 |
| poke53282 | Let me guess. This is not open source | 20:35 |
| olofk | I should dig through my floppy archive | 20:35 |
| poke53282 | No, the problem that I can't publish this if we manage make it work. | 20:36 |
| poke53282 | http://store.steampowered.com/app/9180/ | 20:40 |
| stekern | poke53282: isn't the data here? https://github.com/keendreams/keen/tree/master/static | 20:42 |
| poke53282 | the sizes if the files are around 1Kb. | 20:43 |
| olofk | The readme file is a bit confusing | 20:43 |
| olofk | Is the stuff in static just a subset of the data files? | 20:44 |
| olofk | That's it for tonight | 20:46 |
| olofk | poke53282: Any news about your potential appearance at orconf? | 20:46 |
| poke53282 | Soon. Would I get a slot for a presentation? | 20:47 |
| mor1kx | [mor1kx] skristiansson pushed 6 new commits to master: https://github.com/openrisc/mor1kx/compare/4f9d0803ee16...b516c6a04ed7 | 20:48 |
| mor1kx | mor1kx/master 23ef129 Florent Kermarrec: code clean up: remove trailing whitespaces | 20:48 |
| mor1kx | mor1kx/master 8df4ef3 Florent Kermarrec: code clean up: remove empty lines at end of files | 20:48 |
| mor1kx | mor1kx/master 51c986a Florent Kermarrec: mor1kx_execute_alu: remove unneeded resets on divider and multiplier | 20:48 |
| olofk | poke53282: Yes, we still got slots. Just let us know when you know | 20:48 |
| olofk | haha. I read a statement from the DooM printer guy. | 20:49 |
| olofk | Mr Jordon has no plans to fine tune the demonstration and do that optimisation or take on more work to get the game beyond its loading screen, given how much trouble it took to get it working at all. | 20:50 |
| olofk | "I'm so sick of it," he said. "I'm done." | 20:50 |
| olofk | I know the feeling :) | 20:50 |
| olofk | Now I'm done for tonight | 20:50 |
| poke53282 | good night | 20:57 |
| stekern | amazing, I've actually done everything I had planned doing tonight | 21:11 |
| poke53282 | great | 23:11 |
| --- Log closed Wed Sep 17 00:00:56 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!