| --- Log opened Thu Sep 12 00:00:52 2013 | ||
| stekern | olofk: I think it's sufficient to have the m2s and s2m notion in wb_intercon and the top module. wb_mux, wb_arbiter et al can have standard spec names (with _o and _i on the ports) | 03:33 |
|---|---|---|
| stekern | this is what my wb_intercon looks like now: http://pastie.org/8318824 | 03:40 |
| stekern | _franck_: if you copied my .conf that I pasted, there is a bug in the ROM offset, it should be 0xf0000100 not 0xf0000000 | 05:57 |
| _franck_ | ok thanks | 06:51 |
| stekern | and my "hello world" works with what I pushed this morning to my github | 07:02 |
| stekern | so I think olofk's stuff are solid | 07:03 |
| jeremybennett | I see we now have 15 attendees signed up for ORCONF in Cambridge. | 07:30 |
| stekern | wow | 07:31 |
| jeremybennett | I think we'll get one or two people from outside the main group, which should be good for the project. Since its in the UK, we'll probably get some OSHUG members along. | 07:34 |
| jeremybennett | it's | 07:35 |
| olofk | Stop talking goddamnit! There's too many things to answer in the backlog :) | 07:50 |
| olofk | Ok then, let's begin | 07:50 |
| olofk | stekern: Getting a hand with the renaming on the top levels would be great. [ms]2[sm] is fine with me. I'll adjust my intercon generator accordingly and rename the ports in my wb_mux, wb_arbiter etc. to the wb spec names | 07:52 |
| olofk | I dropped the bytebus idea, because you could only access one peripheral at the time anyway, so it just felt like overhead to have chained muxes. You can still have them if you want though, but as you say. they assigned address space has to be 2^x (so 0x90000000-0xffffffff won't work) | 07:55 |
| olofk | and having a "fallback" address space is how it is intended to work. Just set the last slave to cover the whole mem range | 07:56 |
| olofk | _franck_: I'll push the intercon generator when I get to my computer. Then I'll do the renaming changes and after that I add support for wb_data_resize | 07:57 |
| olofk | And a instantiation skeleton is on the roadmap too | 07:57 |
| olofk | jeremybennett: Nice. Seems like the conference is growing | 07:59 |
| olofk | I have an idea of putting wb_intercon_gen.py in the wb_intercon core. Then I can add logic to ORPSoC at a later time that scans all cores and searches for generators (like plugins) that can be run with orpsoc gen wb_intercon <options> | 08:03 |
| olofk | Because I plan to do a generator for the boot rom too. Kind of what we have in orpsocv2 | 08:03 |
| olofk | Third-party cores with some kind of generator could probably be supported that way too | 08:05 |
| knz | 'morning | 08:05 |
| olofk | And people can use wb_intercon without having to use ORPSoC too | 08:05 |
| olofk | knz: Morning | 08:06 |
| knz | my tools install has eventually completed last night | 08:06 |
| knz | it lasted for a while | 08:06 |
| knz | stekern: http://opencores.org/or1k/FPGA_Development_Boards <- is the info at the bottom of the page still accurate? | 08:06 |
| knz | there's a command: "quartus_pgm --mode=jtag -o pi\;orpsoc.jic | 08:06 |
| knz | what does the "pi;" stand for? | 08:06 |
| stekern | olofk: great, I already started ;) | 08:21 |
| stekern | olofk: I did this in my local copy of wb_intercon_gen.py: http://oompa.chokladfabriken.org/openrisc/wb_intercon_gen.py | 08:22 |
| stekern | might save you some effort | 08:23 |
| stekern | and I already have renamed wb_mux wb_arbiter etc to wb_spec in my local repo, so I can send you a pull request with those today | 08:24 |
| stekern | (together with the rename across or1200-generic) | 08:24 |
| stekern | what's the plans for the 'generic' system, it seems to have bitrotted quite a bit, so I haven't bothered trying to apply the changes to that | 08:26 |
| stekern | knz: yes, that's probably pretty accurate | 08:30 |
| stekern | and I can't remember what the "pi" stood for, I would assume you'll find that in the quartus manual | 08:30 |
| stekern | quartus_pgm --help=o | 08:32 |
| stekern | will tell you | 08:32 |
| olofk | stekern: I have a few different ideas. The or1200-generic system (and mor1kx-generic that I have locally) will probably be moved directly into or1200/mor1kx together with a UART and RAM so simple test cases can be run on them directly. | 08:35 |
| olofk | The generic system might be an or1k-generic with more peripherals, like in orpsocv2, and with the possibility to choose between mor1kx and or1200 | 08:36 |
| olofk | But right now it's bitrotted so just let it be | 08:37 |
| olofk | Actually, I might throw it out altogether | 08:37 |
| stekern | I would ;) | 08:37 |
| stekern | and make or1200-generic go towards being or1k-generic | 08:37 |
| olofk | Yeah, or1200-generic is a lot better base to build upon | 08:38 |
| olofk | So or1k-generic will be a showcase of one of our two main or1k implementations together with some useful peripherals that could be used to build a real system | 08:39 |
| olofk | and if it's cleverly designed, it could probably serve as a sub component in some of the systems | 08:40 |
| stekern | that sounds good | 08:40 |
| knz | I concur | 08:44 |
| knz | :) | 08:44 |
| knz | stekern: FYI the archive at ftp://ocuser:[email protected]/orpsoc/images/orpsoc-de0-nano-50mhz.tar.gz is not compressed, ie the extension ".gz" is misleading | 08:45 |
| knz | besides since it only contains one file I don't see why you need tar at all | 08:46 |
| olofk | orpsocv3 systems will only be released as password protected rar archives | 08:48 |
| stekern | knz: discuss that with the me from 2? years ago ;) | 08:49 |
| knz | :) | 08:49 |
| knz | 2012 | 08:49 |
| stekern | ok, so 1 year | 08:49 |
| knz | well if you'd like me to test a newer jic, I wouldn't mind | 08:49 |
| stekern | I don't have one around right now, so you have to settle with the non-compressed tar for now ;) | 08:51 |
| knz | it's fine | 08:53 |
| knz | grmbl | 08:54 |
| knz | quartus now says "hardware cable not detected" | 08:54 |
| knz | but usb-devices shows my jtag blaster is online | 08:54 |
| olofk | knz: Permission problems? | 08:54 |
| knz | I run it as root | 08:55 |
| olofk | hmm.. | 08:56 |
| stekern | try killing jtagd | 08:58 |
| knz | not running | 08:59 |
| knz | jtagconfig says "No JTAG hardware available" | 08:59 |
| olofk | It's connected to the board properly? | 09:00 |
| knz | hum | 09:00 |
| knz | jtagconfig looks for a ~/.jtag.conf | 09:00 |
| knz | and fails because it can't open that | 09:00 |
| knz | what should I put in ehre? | 09:00 |
| olofk | touch ~/.jtag.conf ? | 09:00 |
| knz | nope | 09:01 |
| olofk | I set up some udev rules for it, but that shouldn't be necessary if you run as root, I guess | 09:02 |
| olofk | Or maybe they're needed to create the correct entries in /dev | 09:02 |
| stekern | I don't have a ~/.jtag.conf | 09:02 |
| knz | aha | 09:03 |
| stekern | not running? | 09:03 |
| knz | so what needs to be there in /dev? | 09:03 |
| stekern | try starting jtagd then | 09:03 |
| knz | it's started now | 09:03 |
| stekern | ok | 09:03 |
| knz | oh wait | 09:04 |
| knz | during the quartus install I only installed support for the cyclone 4 E board | 09:04 |
| knz | but I read in the manual that the jtag program chip is a max 2 | 09:04 |
| stekern | I have this: http://pastie.org/8319290 | 09:04 |
| stekern | that shouldn't matter, you are not *programming* the max 2 | 09:05 |
| knz | ok | 09:05 |
| olofk | Those rules shouldn't matter if you run as root | 09:05 |
| stekern | unless the jtagd runs as some user or something like that | 09:06 |
| stekern | I never fully understood how that system is put together | 09:06 |
| stekern | nor have I cared | 09:06 |
| knz | the annoying part is that when I strace the process it does not even check out the devices | 09:08 |
| knz | AH | 09:09 |
| knz | nailed it | 09:09 |
| knz | /proc/bus/usb/devices | 09:09 |
| knz | does not exist here | 09:10 |
| olofk | But it's in lsusb output? | 09:15 |
| knz | yes | 09:16 |
| knz | but I just straced the jtagd process | 09:16 |
| knz | that one fails after failing to open /proc/bus/usb/devices (for enumeration) | 09:16 |
| knz | which I understand, since usbdevfs is not mounted here | 09:16 |
| knz | now I'm trying to fix that | 09:16 |
| knz | grmbl | 09:18 |
| knz | ok so the situation is as follows: my linux is too recent for that stupid thing :) | 09:29 |
| _franck_ | does it help: http://www.alteraforum.com/forum/showthread.php?t=5893 ? | 09:34 |
| knz | it's interesting | 09:46 |
| knz | I will upgrade to quartus 11 | 09:46 |
| knz | now I use 10.x | 09:46 |
| knz | but I just solved my problem using this: www.alteraforum.com/forum/showthread.php?t=5893 | 09:46 |
| knz | my or1k is uploaded \o/ | 09:47 |
| knz | stekern: which pins did you connect the UART on? | 09:47 |
| stekern | knz: easiest way to find out is to check the pinmap files in 'tcl/UART0_pin_assignments.tcl' | 09:53 |
| stekern | olofk: (now read what you wrote about byte bus and address matching): yes, I'm all on-board on the MATCH_MASK and MATCH_ADDR now when I fully understand how it's intended to be used, it's excellent! | 10:33 |
| olofk | stekern: I will even add a fancy parser to wb_intercon_gen so that you can write size=8MB to get the correct masks. First steps towards usability :) | 10:52 |
| knz | stekern: you mentioned tcl files, which repo do I find this in? | 10:52 |
| stekern | http://git.openrisc.net/cgit.cgi/stefan/orpsoc/tree/boards/altera/de0_nano/syn/quartus/tcl/UART0_pin_assignments.tcl | 10:56 |
| stekern | olofk: heh, that's nice! I'm impressed how easy it was to use as is | 10:57 |
| knz | thx | 11:01 |
| knz | found it | 11:01 |
| stekern | I did something stupid when I tried to invoke it first, I tried to run it as './wb_intercon_gen.py', it went all crazy and started to create screenshots and complain that it can't find /var/mail/verilogwriter.py | 11:03 |
| stekern | what secret malware have you embedded in it? =) | 11:03 |
| olofk | Hmm.. that's strange. It should only try to acces /dev/nsa and /proc/prism | 11:05 |
| olofk | Looking at the pull request now. Did you try to run the wb_bfm and wb_intercon testbenches btw? | 11:06 |
| stekern | ah, right, damn. I forgot about that. I was suppose to ask you how to do that first | 11:06 |
| olofk | orpsoc sim wb_bfm | 11:07 |
| olofk | You can run it with --transactions=10 | 11:07 |
| olofk | If you have a slow computer | 11:07 |
| olofk | I usually run with --vcd --timeout=<number> when I debug. Can be good to know about those options | 11:08 |
| olofk | And similarily orpsoc sim wb_intercon | 11:08 |
| stekern | http://pastie.org/8319564 | 11:08 |
| olofk | Perfect | 11:08 |
| stekern | that passes too | 11:09 |
| olofk | Some indication of the progress is on my todo list | 11:09 |
| olofk | Especially when you run many transactions. It just sits there quietly | 11:09 |
| stekern | yeah, but those where quick enough | 11:09 |
| olofk | Then I pull your stuff | 11:09 |
| olofk | Thanks for the help | 11:09 |
| stekern | my pleasure | 11:09 |
| olofk | wb_intercon with 200000 transactions was not quick :) | 11:10 |
| olofk | sorry.. wb_sdram_ctrl I mean | 11:10 |
| stekern | =) | 11:10 |
| stekern | I believe I have to propagate the sdt=>dat rename there too btw | 11:10 |
| olofk | How the hell do I pull it? | 11:11 |
| olofk | I thought I could do it from the github gui | 11:11 |
| knz | yet another question: any hints about how to move the vmlinuz image to the de0 nano eeprom? | 11:11 |
| knz | and boot from there | 11:11 |
| olofk | Found it | 11:12 |
| stekern | yes, but rather just do: git pull https://github.com/skristiansson/orpsoc-cores for-openrisc | 11:12 |
| stekern | perhaps you don't have access to that where you sit though | 11:12 |
| olofk | Yeah, I don't have my workstation on ATM, but it worked fine through the GUI | 11:13 |
| stekern | but doing normal pulls avoid those ugly github merge commits | 11:13 |
| olofk | aha | 11:14 |
| stekern | a minor issue, but good to know if you don't want them | 11:14 |
| olofk | Apparently orpsoc-cores is 36.5% C code | 11:14 |
| stekern | hmm, where is that hidden? | 11:15 |
| olofk | https://github.com/openrisc/orpsoc-cores | 11:15 |
| stekern | I meant the C code =) | 11:15 |
| olofk | or1k-elf-loader is the only thing I could think of | 11:15 |
| olofk | And the verilator cpp code in or1200-generic | 11:16 |
| stekern | perhaps that's the malware that tries to send stuf | 11:16 |
| olofk | :) | 11:16 |
| stekern | yes, the verilator code of course | 11:16 |
| stekern | knz: you probably don't want it on the eeprom, but the spi flash | 11:17 |
| olofk | But that's not much at all | 11:17 |
| stekern | knz: http://pastie.org/7340535 and http://oompa.chokladfabriken.org/tmp/orpsoc.cof | 11:21 |
| stekern | I thought we had that on the wiki somewhere nowdays, but can't find it | 11:21 |
| knz | the guide at http://kevinmehall.net/openrisc/guide/ refers to git://openrisc.net/jonas/linux, is there an equivalent updated repo on github? | 11:46 |
| knz | ok who's the linux kernel expert here :) | 12:01 |
| hansfbaier | knz: I use the jonas too | 12:07 |
| hansfbaier | it seems to be quite up to date | 12:07 |
| knz | ok | 12:07 |
| hansfbaier | knz: What board do you have? | 12:07 |
| knz | de0 nano too | 12:07 |
| hansfbaier | knz: I don't ;) | 12:08 |
| knz | ah | 12:08 |
| knz | kevin mehall's guide uses it | 12:08 |
| hansfbaier | knz: Yes, its great | 12:08 |
| knz | but kevin's guide is outdated | 12:08 |
| hansfbaier | knz: I don't have it, hard to get in Indonesia | 12:08 |
| hansfbaier | knz: What was wrong? | 12:08 |
| knz | huh | 12:08 |
| knz | (about indonesia: I got mine from taiwan. you'd think it would be easier to ship from taiwan to indonesia than to europe) | 12:09 |
| knz | what's wrong is that it refers to kevin's automatic installation script | 12:09 |
| knz | which in turn refers to outdated versions of the binutils & gcc | 12:09 |
| knz | oh well | 12:10 |
| knz | maybenot actually | 12:10 |
| knz | are the github repos simply mirrors of the repos on git.openrisc.net? | 12:10 |
| hansfbaier | knz: I have this board: http://www.ebay.de/itm/EP4CE10-ALTERA-FPGA-Cyclone-IV-Evaluation-Board-3-2-Touch-LCD-18-Modules-/261187836950?pt=LH_DefaultDomain_0&hash=item3cd0021c16 | 12:11 |
| hansfbaier | knz: the binutils/gcc seem to work well here | 12:12 |
| knz | ok | 12:12 |
| knz | the guide also refers to the "or32" binutils | 12:12 |
| knz | but the newer version uses or1k | 12:12 |
| knz | also to compile linux I believe you have to specify ARCH to trigger cross-compile | 12:13 |
| knz | which the guide does not state | 12:13 |
| knz | all in all I would like to make a few changes in there to reflect things | 12:13 |
| hansfbaier | knz: did you set the environment variables using the script? | 12:14 |
| hansfbaier | that should work fine | 12:14 |
| knz | it "works" but is not consistent with the more recent instructions at: http://opencores.org/or1k/OpenRISC_GNU_tool_chain | 12:16 |
| knz | see the note on this latter page: | 12:16 |
| knz | Note: There is an ongoing transition away from the or32- prefix to or1k-. In practice this means that the stable toolchain uses the old CPU target or32 (e.g. or32-elf, or32-linux), while the new/developemnt toolchain uses or1k (eg. or1k-elf, or1k-linux). Please consider using the new or1k toolchain - especially if you're building straight from the development repos and don't have any issues with backwards compatibility. | 12:16 |
| knz | the guide from kevin has not transitioned yet | 12:16 |
| hansfbaier | knz: http://optimsoc.org/ | 12:29 |
| hansfbaier | knz: the vm image has a working or1k toolchain | 12:30 |
| hansfbaier | already neatly compiled | 12:30 |
| hansfbaier | knz: Yes I tried building or1k but wasn't a smooth experience | 12:31 |
| hansfbaier | so I copied the precompiled one from optimsoc | 12:31 |
| hansfbaier | the old toolchain is good for me too as long as it works | 12:31 |
| knz | building actually was fine | 12:35 |
| knz | I already use the tools in my lecture | 12:35 |
| knz | now my next step is producing an updated vmlinux binary | 12:35 |
| olofk | It would be awesome if you update the OpenCores wiki when you find errors in the instructions there | 12:42 |
| olofk | This isn't the first time someone has become confused with the rich offering of toolchains and build instructions :) | 12:43 |
| hansfbaier | knz: are you a professor? | 12:47 |
| olofk | ahh.. opTiMSoC apparently is a NoC system with OpenRISC | 12:47 |
| olofk | Looking forward to learn more about that at orconf2013 | 12:47 |
| hansfbaier | olofk: what does NoC mean? | 12:47 |
| olofk | hansfbaier: Network On Chip. It's a different strategy for connecting processors and peripherals compared to the usual memory map tree | 12:49 |
| olofk | The idea is basically that all cores are treated as an addressable node and you send messages between them, instead of reading and writing a register map | 12:49 |
| olofk | Sort of like DMA on crack :) | 12:50 |
| olofk | with a big disclaimer that I haven't really read enough on the topic, so I might be wrong on several parts, but this is my understanding of NoC | 12:52 |
| hansfbaier | olofk: good to know thanks | 12:56 |
| hansfbaier | olofk: nice toy anyway :) | 12:56 |
| knz | hansfbaier: depends what you call professor... but I teach at university and do research | 13:01 |
| knz | http://openrisc.net/toolchain-build.html <- this page ought to be removed entirely | 13:20 |
| knz | and replaced with a link to more recent documentation | 13:20 |
| olofk | Someone should notify Jonas so he can update that. I think he has been busy with other stuff lately | 13:34 |
| olofk | But it's not good that outdated instructions is the first thing you get when you search for OpenRISC stuff | 13:35 |
| knz | ok my notes so far: http://staff.science.uva.nl/~poss/intro-openrisc.html | 14:16 |
| knz | I will stop here for today | 14:16 |
| olofk | knz: That's a nice logbook. Things like this is useful for us to streamline the getting-started experience | 14:20 |
| --- Log closed Fri Sep 13 00:00:54 2013 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!