| --- Log opened Mon Sep 09 00:00:48 2013 | ||
| mor1kx | [mor1kx] skristiansson pushed 2 new commits to master: https://github.com/openrisc/mor1kx/compare/44940128a59f...46a23ff3a1ed | 03:33 |
|---|---|---|
| mor1kx | mor1kx/master 49eb6f1 Franck Jullien: cappuccino/fetch: initialize imem_err during reset... | 03:33 |
| mor1kx | mor1kx/master 46a23ff Stefan Kristiansson: icache: reorganize OPTION_ICACHE_WAYS == 2 guard... | 03:33 |
| mor1kx | [mor1kx] skristiansson pushed 1 new commit to master: https://github.com/openrisc/mor1kx/commit/3324116ca935e01dfabd63753e290e392528aa77 | 05:18 |
| mor1kx | mor1kx/master 3324116 Stefan Kristiansson: update version number to v2.0... | 05:18 |
| stekern | whois juliusb_ | 05:18 |
| stekern | oops | 05:18 |
| stekern | juliusb_: ^ that's in line with our discussion, right? | 05:19 |
| mor1kx | [mor1kx] skristiansson pushed 1 new commit to mor1kx_v1: https://github.com/openrisc/mor1kx/commit/1eb23f226b5705e3dcc00829a6e9f8703cc5c82b | 05:38 |
| mor1kx | mor1kx/mor1kx_v1 1eb23f2 Stefan Kristiansson: mor1kx v1.1 | 05:38 |
| stekern | juliusb_: ^ and that makes our release branch complient with the options we have discussed for that | 05:40 |
| stekern | _franck_: how do I set npc in the latest openocd? | 06:07 |
| stekern | set $pc = 0x100 | 06:13 |
| stekern | right? | 06:13 |
| stekern | but how can I get "raw" spr access? | 06:13 |
| stekern | I want to access sr too | 06:14 |
| stekern | single stepping doesn't work, at least not with mor1kx | 06:15 |
| stekern | but this whole soc is a bit unknown, so could be unrelated to changing openocd version | 06:15 |
| stekern | the old version doesn't work at all with sockit, so can't compare neither | 06:22 |
| _franck_ | stekern do you have the last gdb ? | 07:02 |
| _franck_ | maint print reggroups | 07:06 |
| _franck_ | shows you all registers groups | 07:06 |
| _franck_ | you can do "info registers timer" for example | 07:06 |
| _franck_ | then set $sr=0x... if you want to set sr | 07:07 |
| _franck_ | info register sr to see its content | 07:07 |
| _franck_ | or info register system | 07:07 |
| stekern | _franck_: thanks | 07:50 |
| olofk | Slow day today. I'm just merging pull requests and stuff... you know, the usual | 08:10 |
| _franck_ | :) | 08:10 |
| stekern | you really need to be following #openrisc pretty closely to get the fun in that sentence ;) | 08:26 |
| stekern | you nailed it btw | 08:28 |
| olofk | \o/ | 08:35 |
| -!- knz_ is now known as knz | 09:14 | |
| hansfbaier | stekern: Did you have something like this in mind: http://pastebin.com/cxx7PPHP | 09:58 |
| hansfbaier | for the enc28j60 interrupt | 09:58 |
| stekern | hansfbaier: yes, that looks like what I had in mind | 09:59 |
| hansfbaier | stekern: thanks | 09:59 |
| olofk | Now this is annyoing | 12:02 |
| olofk | github is trying to be clever with the archives | 12:03 |
| stekern | clever in what way? | 12:04 |
| olofk | You can download an archive of the tree at a certain commit from github.com/<user>/<repo>/archive/<version>.tar.gz | 12:06 |
| olofk | version can be sha, branch head or a tag | 12:06 |
| stekern | mhmmm | 12:07 |
| olofk | You get a tar.gz where the files are stored under the directory <repo>-<version> | 12:07 |
| olofk | But for the tags, the name of the archive is mor1kx-v1.0.tar.gz, but it's extracted under mor1kx-1.0 | 12:08 |
| olofk | So github throws away the 'v' in the pathname | 12:08 |
| olofk | Ugly workaround for now is to look at the first path element of some random file to determine where it will end up | 12:09 |
| stekern | hmm, actually, the filename is mor1kx-1.1.tar.gz too, if you download from the web interface | 12:10 |
| olofk | Any file in the archive, to be clearer | 12:10 |
| olofk | hmm.. interesting | 12:10 |
| olofk | Are the tags named v1.x, or just 1.x? | 12:11 |
| stekern | still.. wouldn't it be better to just use the git tree? | 12:11 |
| stekern | than downloading tar.gz | 12:11 |
| stekern | tags are named v1.x | 12:11 |
| olofk | Might be, but by doing it like this, I won't have a hard dependency on git | 12:12 |
| stekern | no, but you will have a hard dependency on tar and gzip | 12:12 |
| stekern | ;) | 12:12 |
| olofk | I see your point, but those are in python's core libs :) | 12:12 |
| stekern | you're going to have a git dependency anyway, you can't expect everything to be in github | 12:14 |
| stekern | also, from a caching point of view, it makes more sense to have the git repo in cache | 12:15 |
| olofk | Only if you have a clever cache mechanism | 12:15 |
| olofk | In order to decrease the amount of work on those parts, I decided to drop automatic updating for now | 12:16 |
| stekern | "automatic updating"? | 12:17 |
| olofk | Automatic as in detecting when the cached copy is outdated and needs to be updated | 12:17 |
| stekern | ah, ok | 12:18 |
| stekern | well, you don't have that now, but it's probably an aim for the future to have that | 12:18 |
| olofk | I have some ideas for how to improve the cache handling, but I think it's good enough for now | 12:19 |
| olofk | I can at least use tagged versions from github in the core files now | 12:20 |
| stekern | but I mean, with a git repo you could just do: if !coreincache: git clone; git checkout <tag/branch/sha> | 12:21 |
| stekern | maybe you want to throw in a fetch there too, but you get the point | 12:22 |
| stekern | this makes me realise that git submodules would be a royal pain to have in orpsoc-cores | 12:26 |
| stekern | you'd have to setup seperate git submodules in every system/<system-port-dir>/ | 12:27 |
| stekern | ...but actually, what I'm thinking about isn't even possible as it is now... | 12:28 |
| stekern | you can't have different versions of a core for different systems | 12:28 |
| stekern | that's not good | 12:28 |
| stekern | maybe it's not so much of a problem when I think about it a bit more, if you want some very special version of a core for a system, you can just do a seperate .core description for it in cores/ | 12:38 |
| _franck_ | or you can put the core files in your board directory | 12:39 |
| stekern | yes, but that falls in the "not good" category | 12:40 |
| olofk | Multiple versions of cores is planned too | 12:40 |
| stekern | ok, that sounds good | 12:40 |
| olofk | I'll probably go the gentoo way and have multiple <name>-<version>.core files, and let the core files themselves tell which patches they should use | 12:41 |
| olofk | And add more intelligence to the depend string. Like being able to set dependencies on >=mor1kx-1.1 | 12:42 |
| olofk | The best thing would be if I could actually steal some of the logic from portage. I think that is written i Python too | 12:42 |
| stekern | that sounds good too | 12:42 |
| olofk | I should probably write down all this stuff, especially if someone wants to help out | 12:44 |
| _franck_ | stekern: about the dpram in wb_sdram_ctrl, removing intended_device_family in the instantiation makes modelsim to choose the Stratix family and it now complains about clock_enable_output_a not being supported by Stratix family :( | 12:45 |
| _franck_ | stekern: what would you prefer ? | 12:45 |
| _franck_ | 1) remove clock_enable_output_a from dpram_altera.v | 12:46 |
| _franck_ | 2) add a parameter FAMILY to wb_sdram_ctrl | 12:46 |
| _franck_ | 3) add a new dpram_altera_cii.v file | 12:46 |
| stekern | hmm, we don't use the clock_enable_output_a, so removing that sounds like the logical step forward | 12:47 |
| _franck_ | agree | 12:48 |
| stekern | I have to admit that I didn't really use a lot of time on consider the options and settings in that dpram_altera.v file | 12:49 |
| stekern | I'm not sure why I even created it, the generic should work too | 12:51 |
| stekern | maybe just to make it easy for people to see where they should insert their technology dependent RAM if necessary | 12:52 |
| stekern | but if we can make that generic over altera devices, fine | 12:52 |
| _franck_ | GENERIC throws an error then Quartus tries to fit it (I didn't try to find out why...) | 12:55 |
| stekern | hmm, ok | 14:12 |
| stekern | on the bright side... | 14:12 |
| stekern | leds are blinking! | 14:12 |
| stekern | but accessing the vjtag messes up the arm processor | 14:24 |
| olofk | stekern, _franck_: My two favorite early adopters. I'm about to update the interface of wb_mux and wb_arbiter soon in orpsocv3 | 17:22 |
| olofk | stekern: Revenge! Feel the wrath in the pull request I just sent you! | 18:29 |
| stekern | olofk: I've got a busy day, but I managed to squeeze in the pull anyway | 19:24 |
| stekern | two general constructive comments, a more descriptive commit message on the testbench would have been nice and keeping the coding style across the project | 19:26 |
| stekern | apart from that nitpicking... | 19:26 |
| * stekern bows and say thanks! | 19:26 | |
| stekern | on to some ranting about qsys... | 19:27 |
| stekern | why on earth is it so slow on my (k)ubuntu machine? | 19:27 |
| stekern | has to be something with my java setup, it takes ~20 sec to change a value in one of the setting boxes | 19:28 |
| stekern | olofk: can I somehow reference my own files in the build/src/ directory? | 19:50 |
| stekern | and if not, can you point me to where I should start hacking to make it do that? | 19:51 |
| stekern | to explain a bit more what I'm doing, I will have qsys generate a set of .v files, I don't want them to end up in my orpsoc-cores directory, but in the build directory (and under src seems appropriate) | 19:53 |
| stekern | well, it's enough to add the .qip file | 19:55 |
| olofk | stekern: Regarding coding style, what did I miss? I'm using emacs with verilog-mode, but I might have forgotten to beautify | 20:00 |
| olofk | stekern: You want the qip file to end up in the build directory? | 20:01 |
| stekern | I used tabs only indentation (i.e. not verilog-mode default) | 20:02 |
| stekern | but it's no big deal, the testbench is standalone, I'd be more upset if it was a module in rtl/verilog/ ;) | 20:03 |
| olofk | :) | 20:03 |
| olofk | I need to understand a bit more about the qsys stuff. | 20:03 |
| olofk | Is the qip something similar to coregen, ie. you use the qip as an input file to generate the .v files? | 20:04 |
| stekern | I want all the qsys generated files ending up in the build directory, the .qip file should be added to the project file (.qpf) | 20:04 |
| olofk | You want the .v files generated on the fly then I guess? | 20:04 |
| stekern | no, the .qip (AFAIU) is just a description of what files qsys generated | 20:04 |
| stekern | so if you change the qsys system, you don't need to add a lot of files to the project | 20:05 |
| stekern | but I guess build.py will be my friend here, right? | 20:05 |
| olofk | Yes | 20:05 |
| stekern | I need to add qsys support too | 20:06 |
| olofk | Yes | 20:06 |
| stekern | fortunately, you can drive the qsys generation from commandline | 20:06 |
| olofk | I'm not familiar with the Altera stuff on that level, but I recognized that I need to add explicit support for coregen, and I guess the same goes for qsys then | 20:06 |
| olofk | Can you describe the workflow with qsys? I assumes you have some description file (qpf?) that is used as input to some generator that spits out .v files. Is that correct? | 20:07 |
| stekern | you use the qsys gui (that I just cursed about being slow as hell) to describe you system, that will be saved into a .qsys file (that I will store in systems/sockit/data/) | 20:09 |
| olofk | Great | 20:09 |
| stekern | you then run the generator on that (in the gui, you press the "generate" button) | 20:09 |
| stekern | were you sleeping on the workshop? or did you spend all time rekompiling your kernel? ;) | 20:10 |
| olofk | Well, actually. That isn't too far from the truth | 20:10 |
| olofk | I also spent some time cursing that I had node locked the ARM stuff license to the tethered internet connection on my phone | 20:11 |
| olofk | Which occupied one of my two only USB ports, which prevented me from using the blaster and terminal at the same time | 20:12 |
| stekern | heh | 20:12 |
| olofk | It was a bit messy | 20:13 |
| olofk | Anyway. The generate part generates the verilog files then, right? | 20:13 |
| stekern | well, we only had boards for half the people, so we had to share | 20:13 |
| stekern | luckily the guy I was sharing with wasn't as messy as you, but others were, so we had time to finish of all assignments anyway ;) | 20:14 |
| stekern | yes, the generate part generates the verilog files, and a top module that I will instantiate in orpsoc_top | 20:14 |
| stekern | basically all I'm going to have in the qsys system is the hps | 20:15 |
| stekern | + an avalon bridge to the hps ddr3 | 20:15 |
| olofk | ok, so the qsys stuff will be a sub-component in orpsoc_top. That helps too | 20:15 |
| stekern | yes, I considered doing it the other way around, but I decided it'll be cleaner to have it as a sub-component | 20:16 |
| olofk | Step one *could* be to store the generated .v files in your sockit core | 20:17 |
| stekern | nonono, wroooong ;) | 20:17 |
| stekern | and ugly | 20:17 |
| olofk | Yes, definitely ugly, but an option | 20:17 |
| stekern | actually, if I just get the .qip file in the project file, it's not so much of a problem during development | 20:18 |
| stekern | I just have to run the qsys generation as a seperate step | 20:18 |
| olofk | What we _do_ want is to have a section in the .core file that tells which qsys file to use, and parses the qip file to see which additional files that should be referenced when you do the build/simulation | 20:19 |
| olofk | s/parses/parse | 20:19 |
| stekern | hmm, where do you need that information? | 20:19 |
| stekern | for simulation, perhaps, yes | 20:20 |
| olofk | Yes. For building you could reference the qip directly, right? | 20:20 |
| stekern | yes | 20:20 |
| stekern | qsys can generate testbenches too, but I'm not sure how deeply you will be able to simulate this system | 20:22 |
| olofk | Is it feasible to run simulations on that system? | 20:22 |
| olofk | Otherwise I would say that we start out with the easy way and concentrate on getting it right for the bitstream generation | 20:22 |
| stekern | the ddr3 is connected to a hardcore memory controller in the hps, I'm not sure if you can simulate that | 20:23 |
| stekern | (and even if you can, you'll need the hps to set it up) | 20:23 |
| olofk | Is HPS the TLA for the ARM SoC? | 20:24 |
| stekern | yes ;) | 20:24 |
| olofk | Stupid Textile Labour Association! | 20:24 |
| stekern | Hard Processor System | 20:24 |
| olofk | aha | 20:24 |
| olofk | I would have guess High Performace or something Paralell | 20:25 |
| stekern | this will be quite different from the other orpsocs we have | 20:25 |
| olofk | Yes, so it would be nice to support it without adding too much specialized logic in orpsoc | 20:26 |
| olofk | But qsys can be used for other things too, right? | 20:26 |
| stekern | since the fpga isn't really connected to anything interesting (apart from the vga port and ac97) on the board, there will be connections into the hps instead | 20:26 |
| stekern | yes, you can build complete socs with qsys, point and clicky style | 20:27 |
| olofk | This is basically the opposite from your idea of a qsys mor1kx wrapper, right? | 20:27 |
| stekern | so, essentially orpsocv3 could be considered a start to a qsys (or a backend if you will) | 20:28 |
| olofk | hmm... explain | 20:29 |
| stekern | or, what I'm trying to say, there are similarities | 20:29 |
| stekern | my "qsys mor1kx wrapper" was a qsys core description file for mor1kx | 20:30 |
| olofk | I thought so | 20:31 |
| stekern | pretty much the same as the .core file in orpsocv3 | 20:31 |
| olofk | Being able to generate qsys core descriptions directly from orpsoc is another thing that I plan to support somewhere in the distant future | 20:32 |
| stekern | in qsys you pick the cores in the gui (as you do in the .system file) | 20:32 |
| olofk | Or at least export them, so the build/src directory can be picked up in qsys or Xilinx XPS | 20:32 |
| stekern | then you point and click how the cores are connected (including bus interfaces) | 20:33 |
| olofk | I guess it's quite equivalent to XPS | 20:33 |
| stekern | and then when you click "generate" it copies all the verilog files from the core description files into a single directory | 20:34 |
| olofk | Regarding build.py... yes, that's where the logic should go, _but_, that file is a mess and should be converted to a sub package in orpsoc | 20:34 |
| stekern | and it autogenerates the bus connections and a top file | 20:34 |
| stekern | so, isn't that quite similar to what orpsocv3 does? | 20:35 |
| stekern | except the top file autogeneration | 20:35 |
| olofk | Yep, but without top-level generation and a fancy GUI :) | 20:35 |
| olofk | And it probably works too :( | 20:36 |
| stekern | well, I rather use emacs than the fancy gui that takes 20 sec for each input box to update... | 20:36 |
| olofk | So, there are two qsys-related things that could be supported in orpsoc. | 20:36 |
| stekern | there are like 40 parameters in the DDR3 settings... | 20:37 |
| olofk | 1. Run the generate command on a qsys file to generate the verilog files in the build directory | 20:37 |
| stekern | yup, that should be easy | 20:37 |
| olofk | 2. Create qsys files from .core files (and probably some more info) to make it possible to use the orpsoc-cores in a qsys workflow | 20:38 |
| olofk | Number 2 will have to wait | 20:38 |
| stekern | yes, and that's kind of out of the scope of the project | 20:38 |
| stekern | but a cool feature, I admit | 20:39 |
| stekern | because the qsys component I made for mor1kx have already bitrotted.. | 20:39 |
| olofk | Can you pastie it? Would be interesting to see what it looks like | 20:39 |
| olofk | Do you ever reference more than 1 qsys file? | 20:40 |
| olofk | Doesn't matter really | 20:40 |
| stekern | http://oompa.chokladfabriken.org/openrisc/mor1kx_hw.tcl | 20:41 |
| olofk | I say that we add a [qsys] section to the .core file and an option that tells where to find the .qsys file. Would that be enough? | 20:41 |
| olofk | Those changes should go in orpsoc/core.py | 20:43 |
| stekern | hmm, are the files in data hardcoded somewhere? | 20:43 |
| olofk | ? | 20:43 |
| stekern | nm, no they are in the .system file | 20:44 |
| stekern | wouldn't it make more sense to have a qsys_file(s) in the .system file? | 20:45 |
| olofk | Not if we want to generate them for simulations as well | 20:45 |
| stekern | hmmm... but it's a very quartus specific thing | 20:46 |
| olofk | true | 20:46 |
| stekern | qsys can appearently generate testbenches as well | 20:47 |
| olofk | hmm.. | 20:48 |
| stekern | I'd say the most logical place from a user point of view would be under [quartus] as a qsys_file(s) option | 20:49 |
| olofk | Well, as you represent 50% of the user base, I say we go for that :) | 20:50 |
| stekern | 33.3333%, aren't you dogfooding? | 20:50 |
| olofk | No, I only use qsys | 20:51 |
| olofk | Can't stand all this command line crap | 20:51 |
| stekern | heh | 20:53 |
| stekern | since I raised the issue of coding style earlier, is there a preference in systems, or is that the decision of the system creator? | 20:58 |
| olofk | It would be great to unify that, but it seems that there aren't any prevalent coding styles in the verilog world | 20:58 |
| olofk | I prefer spaces, but in practice just go with whatever verilog-mode gives me | 21:00 |
| stekern | I copied _franck_'s de1 board, he disliked verilog-mode so much so he changed everything to tabs | 21:01 |
| olofk | I don't like it either. Everything looks like shit when I'm doing diffs | 21:01 |
| olofk | I get the feeling that it isn't very consistent between versions either | 21:02 |
| stekern | yeah, I noticed that too, it lines up multi-line statements different now than it did before | 21:02 |
| stekern | someone needs to do a modified config for it and distribute ;) | 21:03 |
| olofk | I gave up instead :) | 21:03 |
| stekern | yeah, me too... | 21:03 |
| stekern | maybe I just let verilog-mode have it's way with the sockit port too... | 21:06 |
| _franck_ | no ! please ! | 21:06 |
| stekern | _franck_: it's up to you to make the configuration to save the world then! | 21:07 |
| _franck_ | I don't use emacs :) | 21:07 |
| stekern | it's a noble quest | 21:07 |
| _franck_ | insted I would create a checkpatch.pl like for verilog/vhdl | 21:08 |
| _franck_ | so we can check every file, and if you have a coding style issue, you can't commit :) (like gerrit with openocd) | 21:09 |
| stekern | hmm, yes, but then the project maintainer have to dictate the coding style rules that should go into checkpatch.pl | 21:10 |
| _franck_ | we are in a democracy (most of us) so discussion is welcome when it's about coding style | 21:11 |
| stekern | true | 21:12 |
| _franck_ | quartus; | 21:12 |
| _franck_ | oups | 21:12 |
| olofk | _franck_: Aha! You have been exposed! I see that you are using quartus instead of orpsoc! | 21:13 |
| stekern | I'd like a v-set-style command, so I can swap between the evil verilog-mode and a sane configured verilog-mode | 21:13 |
| stekern | but my emacs-fu is restricted to copy paste what google gives me into the .emacs file | 21:14 |
| olofk | I haven't written a single line of lisp-like code in 12 years | 21:14 |
| _franck_ | olofk: I was about to say: quartus tells me he wont infer the ram but does not tell me why... | 21:16 |
| _franck_ | but yes, I have to admit I use quartus sometime :) | 21:16 |
| stekern | ok, _franck_ let me rephrase that, I let verilog-mode have it's way with the code I add *now* to sockit | 21:17 |
| stekern | that will leave it in such an ugly state when it's mixed with your tabs that I will have to do something about it before it's done ;) | 21:17 |
| stekern | btw: // *************** BUG OLOFK ************** <- what's that? | 21:18 |
| _franck_ | lol | 21:18 |
| olofk | :) | 21:19 |
| _franck_ | some thing I had to push | 21:19 |
| stekern | stop pushing buggy olofks around! | 21:19 |
| _franck_ | AFAIR address names on the line above this nice comment are not correct in the code I copied from (or1200-generic) | 21:20 |
| stekern | I can probably remove it from my sockit then ;) | 21:22 |
| _franck_ | or you can lease it so "olof will have his name" in sokit :) | 21:24 |
| _franck_ | s/lease/leave | 21:24 |
| olofk | :) | 21:29 |
| stekern | I got interrupted in my description of the setup of the sockit orpsocv3 port | 21:31 |
| stekern | so, I was saying that there are no interesting stuff connected to the fpga on the board, so ethernet and uart for instance will have to go through the arm system | 21:32 |
| stekern | I think it'd be cool to have the debug port hooked up straight to the arm system as well | 21:33 |
| olofk | Got to sleep now | 21:42 |
| olofk | Update your orpsocv3 and orpsoc-cores if you haven't already | 21:42 |
| _franck_ | ok, thanks, good night | 21:43 |
| juliusb_ | stekern: yep, I'm on board - .0 is dev branch, .(>0) is release | 22:16 |
| juliusb_ | looks great | 22:16 |
| juliusb_ | thanks a lot for organising this! | 22:16 |
| juliusb_ | i'm currently road tripping through the US - I bought a SIM card with data here but the reception is patchy so I may take time to respond to thing, sorry | 22:17 |
| juliusb_ | but i'm keeping an eye on the logs ;) | 22:18 |
| juliusb_ | you guys give us lurkers plenty to read of late | 22:18 |
| juliusb_ | and why am I my underscored version of myself? | 22:18 |
| -!- You're now known as juliusb | 22:18 | |
| --- Log closed Tue Sep 10 00:00:49 2013 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!