IRC logs for #openrisc Thursday, 2013-09-12

--- Log opened Thu Sep 12 00:00:52 2013
stekernolofk: 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
stekernthis is what my wb_intercon looks like now: http://pastie.org/831882403:40
stekern_franck_: if you copied my .conf that I pasted, there is a bug in the ROM offset, it should be 0xf0000100 not 0xf000000005:57
_franck_ok thanks06:51
stekernand my "hello world" works with what I pushed this morning to my github07:02
stekernso I think olofk's stuff are solid07:03
jeremybennettI see we now have 15 attendees signed up for ORCONF in Cambridge.07:30
stekernwow07:31
jeremybennettI 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
jeremybennettit's07:35
olofkStop talking goddamnit! There's too many things to answer in the backlog :)07:50
olofkOk then, let's begin07:50
olofkstekern: 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 names07:52
olofkI 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
olofkand having a "fallback" address space is how it is intended to work. Just set the last slave to cover the whole mem range07: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_resize07:57
olofkAnd a instantiation skeleton is on the roadmap too07:57
olofkjeremybennett: Nice. Seems like the conference is growing07:59
olofkI 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
olofkBecause I plan to do a generator for the boot rom too. Kind of what we have in orpsocv208:03
olofkThird-party cores with some kind of generator could probably be supported that way too08:05
knz'morning08:05
olofkAnd people can use wb_intercon without having to use ORPSoC too08:05
olofkknz: Morning08:06
knzmy tools install has eventually completed last night08:06
knzit lasted for a while08:06
knzstekern: http://opencores.org/or1k/FPGA_Development_Boards <- is the info at the bottom of the page still accurate?08:06
knzthere's a command: "quartus_pgm --mode=jtag -o pi\;orpsoc.jic08:06
knzwhat does the "pi;" stand for?08:06
stekernolofk: great, I already started ;)08:21
stekernolofk: I did this in my local copy of wb_intercon_gen.py: http://oompa.chokladfabriken.org/openrisc/wb_intercon_gen.py08:22
stekernmight save you some effort08:23
stekernand 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 today08:24
stekern(together with the rename across or1200-generic)08:24
stekernwhat'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 that08:26
stekernknz: yes, that's probably pretty accurate08:30
stekernand I can't remember what the "pi" stood for, I would assume you'll find that in the quartus manual08:30
stekernquartus_pgm --help=o08:32
stekernwill tell you08:32
olofkstekern: 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
olofkThe generic system might be an or1k-generic with more peripherals, like in orpsocv2, and with the possibility to choose between mor1kx and or120008:36
olofkBut right now it's bitrotted so just let it be08:37
olofkActually, I might throw it out altogether08:37
stekernI would ;)08:37
stekernand make or1200-generic go towards being or1k-generic08:37
olofkYeah, or1200-generic is a lot better base to build upon08:38
olofkSo 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 system08:39
olofkand if it's cleverly designed, it could probably serve as a sub component in some of the systems08:40
stekernthat sounds good08:40
knzI concur08:44
knz:)08:44
knzstekern: FYI the archive at ftp://ocuser:ocuser@openrisc.opencores.org/orpsoc/images/orpsoc-de0-nano-50mhz.tar.gz  is not compressed, ie the extension ".gz" is misleading08:45
knzbesides since it only contains one file I don't see why you need tar at all08:46
olofkorpsocv3 systems will only be released as password protected rar archives08:48
stekernknz: discuss that with the me from 2? years ago ;)08:49
knz:)08:49
knz201208:49
stekernok, so 1 year08:49
knzwell if you'd like me to test a newer jic, I wouldn't mind08:49
stekernI don't have one around right now, so you have to settle with the non-compressed tar for now ;)08:51
knzit's fine08:53
knzgrmbl08:54
knzquartus now says "hardware cable not detected"08:54
knzbut usb-devices shows my jtag blaster is online08:54
olofkknz: Permission problems?08:54
knzI run it as root08:55
olofkhmm..08:56
stekerntry killing jtagd08:58
knznot running08:59
knzjtagconfig says "No JTAG hardware available"08:59
olofkIt's connected to the board properly?09:00
knzhum09:00
knzjtagconfig looks for a ~/.jtag.conf09:00
knzand fails because it can't open that09:00
knzwhat should I put in ehre?09:00
olofktouch ~/.jtag.conf ?09:00
knznope09:01
olofkI set up some udev rules for it, but that shouldn't be necessary if you run as root, I guess09:02
olofkOr maybe they're needed to create the correct entries in /dev09:02
stekernI don't have a ~/.jtag.conf09:02
knzaha09:03
stekernnot running?09:03
knzso what needs to be there in /dev?09:03
stekerntry starting jtagd then09:03
knzit's started now09:03
stekernok09:03
knzoh wait09:04
knzduring the quartus install I only installed support for the cyclone 4 E board09:04
knzbut I read in the manual that the jtag program chip is a max 209:04
stekernI have this: http://pastie.org/831929009:04
stekernthat shouldn't matter, you are not *programming* the max 209:05
knzok09:05
olofkThose rules shouldn't matter if you run as root09:05
stekernunless the jtagd runs as some user or something like that09:06
stekernI never fully understood how that system is put together09:06
stekernnor have I cared09:06
knzthe annoying part is that when I strace the process it does not even check out the devices09:08
knzAH09:09
knznailed it09:09
knz/proc/bus/usb/devices09:09
knzdoes not exist here09:10
olofkBut it's in lsusb output?09:15
knzyes09:16
knzbut I just straced the jtagd process09:16
knzthat one fails after failing to open /proc/bus/usb/devices (for enumeration)09:16
knzwhich I understand, since usbdevfs is not mounted here09:16
knznow I'm trying to fix that09:16
knzgrmbl09:18
knzok 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
knzit's interesting09:46
knzI will upgrade to quartus 1109:46
knznow I use 10.x09:46
knzbut I just solved my problem using this: www.alteraforum.com/forum/showthread.php?t=589309:46
knzmy or1k is uploaded \o/09:47
knzstekern: which pins did you connect the UART on?09:47
stekernknz: easiest way to find out is to check the pinmap files in 'tcl/UART0_pin_assignments.tcl'09:53
stekernolofk: (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
olofkstekern: 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
knzstekern: you mentioned tcl files, which repo do I find this in?10:52
stekernhttp://git.openrisc.net/cgit.cgi/stefan/orpsoc/tree/boards/altera/de0_nano/syn/quartus/tcl/UART0_pin_assignments.tcl10:56
stekernolofk: heh, that's nice! I'm impressed how easy it was to use as is10:57
knzthx11:01
knzfound it11:01
stekernI 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.py11:03
stekernwhat secret malware have you embedded in it? =)11:03
olofkHmm.. that's strange. It should only try to acces /dev/nsa and /proc/prism11:05
olofkLooking at the pull request now. Did you try to run the wb_bfm and wb_intercon testbenches btw?11:06
stekernah, right, damn. I forgot about that. I was suppose to ask you how to do that first11:06
olofkorpsoc sim wb_bfm11:07
olofkYou can run it with --transactions=1011:07
olofkIf you have a slow computer11:07
olofkI usually run with --vcd --timeout=<number> when I debug. Can be good to know about those options11:08
olofkAnd similarily orpsoc sim wb_intercon11:08
stekernhttp://pastie.org/831956411:08
olofkPerfect11:08
stekernthat passes too11:09
olofkSome indication of the progress is on my todo list11:09
olofkEspecially when you run many transactions. It just sits there quietly11:09
stekernyeah, but those where quick enough11:09
olofkThen I pull your stuff11:09
olofkThanks for the help11:09
stekernmy pleasure11:09
olofkwb_intercon with 200000 transactions was not quick :)11:10
olofksorry.. wb_sdram_ctrl I mean11:10
stekern=)11:10
stekernI believe I have to propagate the sdt=>dat rename there too btw11:10
olofkHow the hell do I pull it?11:11
olofkI thought I could do it from the github gui11:11
knzyet another question: any hints about how to move the vmlinuz image to the de0 nano eeprom?11:11
knzand boot from there11:11
olofkFound it11:12
stekernyes, but rather just do:  git pull https://github.com/skristiansson/orpsoc-cores for-openrisc11:12
stekernperhaps you don't have access to that where you sit though11:12
olofkYeah, I don't have my workstation on ATM, but it worked fine through the GUI11:13
stekernbut doing normal pulls avoid those ugly github merge commits11:13
olofkaha11:14
stekerna minor issue, but good to know if you don't want them11:14
olofkApparently orpsoc-cores is 36.5% C code11:14
stekernhmm, where is that hidden?11:15
olofkhttps://github.com/openrisc/orpsoc-cores11:15
stekernI meant the C code =)11:15
olofkor1k-elf-loader is the only thing I could think of11:15
olofkAnd the verilator cpp code in or1200-generic11:16
stekernperhaps that's the malware that tries to send stuf11:16
olofk:)11:16
stekernyes, the verilator code of course11:16
stekernknz: you probably don't want it on the eeprom, but the spi flash11:17
olofkBut that's not much at all11:17
stekernknz: http://pastie.org/7340535 and http://oompa.chokladfabriken.org/tmp/orpsoc.cof11:21
stekernI thought we had that on the wiki somewhere nowdays, but can't find it11:21
knzthe guide at http://kevinmehall.net/openrisc/guide/ refers to  git://openrisc.net/jonas/linux, is there an equivalent updated repo on github?11:46
knzok who's the linux kernel expert here :)12:01
hansfbaierknz: I use the jonas too12:07
hansfbaierit seems to be quite up to date12:07
knzok12:07
hansfbaierknz: What board do you have?12:07
knzde0 nano too12:07
hansfbaierknz: I don't ;)12:08
knzah12:08
knzkevin mehall's guide uses it12:08
hansfbaierknz: Yes, its great12:08
knzbut kevin's guide is outdated12:08
hansfbaierknz: I don't have it, hard to get in Indonesia12:08
hansfbaierknz: What was wrong?12:08
knzhuh12: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
knzwhat's wrong is that it refers to kevin's automatic installation script12:09
knzwhich in turn refers to outdated versions of the binutils & gcc12:09
knzoh well12:10
knzmaybenot actually12:10
knzare the github repos simply mirrors of the repos on git.openrisc.net?12:10
hansfbaierknz: 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=item3cd0021c1612:11
hansfbaierknz: the binutils/gcc seem to work well here12:12
knzok12:12
knzthe guide also refers to the "or32" binutils12:12
knzbut the newer version uses or1k12:12
knzalso to compile linux I believe you have to specify ARCH to trigger cross-compile12:13
knzwhich the guide does not state12:13
knzall in all I would like to make a few changes in there to reflect things12:13
hansfbaierknz: did you set the environment variables using the script?12:14
hansfbaierthat should work fine12:14
knzit "works" but is not consistent with the more recent instructions at: http://opencores.org/or1k/OpenRISC_GNU_tool_chain12:16
knzsee the note on this latter page:12:16
knzNote: 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
knzthe guide from kevin has not transitioned yet12:16
hansfbaierknz: http://optimsoc.org/12:29
hansfbaierknz: the vm image has a working or1k toolchain12:30
hansfbaieralready neatly compiled12:30
hansfbaierknz: Yes I tried building or1k but wasn't a smooth experience12:31
hansfbaierso I copied the precompiled one from optimsoc12:31
hansfbaierthe old toolchain is good for me too as long as it works12:31
knzbuilding actually was fine12:35
knzI already use the tools in my lecture12:35
knznow my next step is producing an updated vmlinux binary12:35
olofkIt would be awesome if you update the OpenCores wiki when you find errors in the instructions there12:42
olofkThis isn't the first time someone has become confused with the rich offering of toolchains and build instructions :)12:43
hansfbaierknz: are you a professor?12:47
olofkahh.. opTiMSoC apparently is a NoC system with OpenRISC12:47
olofkLooking forward to learn more about that at orconf201312:47
hansfbaierolofk: what does NoC mean?12:47
olofkhansfbaier: Network On Chip. It's a different strategy for connecting processors and peripherals compared to the usual memory map tree12:49
olofkThe 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 map12:49
olofkSort of like DMA on crack :)12:50
olofkwith 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 NoC12:52
hansfbaierolofk: good to know thanks12:56
hansfbaierolofk: nice toy anyway :)12:56
knzhansfbaier: depends what you call professor... but I teach at university and do research13:01
knzhttp://openrisc.net/toolchain-build.html <- this page ought to be removed entirely13:20
knzand replaced with a link to more recent documentation13:20
olofkSomeone should notify Jonas so he can update that. I think he has been busy with other stuff lately13:34
olofkBut it's not good that outdated instructions is the first thing you get when you search for OpenRISC stuff13:35
knzok my notes so far: http://staff.science.uva.nl/~poss/intro-openrisc.html14:16
knzI will stop here for today14:16
olofkknz: That's a nice logbook. Things like this is useful for us to streamline the getting-started experience14: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!