IRC logs for #openrisc Sunday, 2014-04-27

--- Log opened Sun Apr 27 00:00:23 2014
stekernblueCmd: hehe, "if", isn't a broken readdir a real problem? ;)05:14
stekernwtf... if I run 'make xmkmf' manually in xutils-dev it produces a non-empty file...06:05
stekern...there's alot of arch dependent stuff in xutils-dev07:15
stekernman, this is like gentoo relived, a little hack there and a little hack there and the packages start building ;)07:32
stekernblueCmd: I have hacked up my local xmkmf and related .cfg files so I've been able to build xaw3d, but the xdev-utils-dev package needs proper fixing, should I add an issue to your github page about it so it's not forgotten?07:42
stekernerr, xutils-dev I mean07:42
stekernblueCmd: when we are building packages, _FILEOFFSET_BITS is getting detected to 6408:03
stekernah, poking around wannabuild a bit more I see how nifty it is08:45
blueCmdstekern: (FILEOFFSET) really? how?10:53
blueCmdstekern: (xutils)yes, please do. RAWCPP didn't fix it?10:54
stekernblueCmd: (FILEOFFSET) dunno, just saw it swooshing by in the ./configure phase, will revisit that11:46
blueCmdcool, thanks11:47
stekern(xutils) I think the patch fixes the problem, but there's something else going on that makes xmkmf end up an empty file when it's built with dpkg-buildpackage11:48
stekernIf I go into the build-dir and do a 'rm xmkmf && make' it'll generate it correctly11:48
stekernthen there's some .cfg files that needs arch specific defines, but fixing them in the package clashes with some patches, so I just edited the installed files post-install11:49
stekernOr1kArchitecture in that11:55
stekernfor instance11:55
blueCmddoes it build without that?11:56
blueCmdrun-parts: failed to open directory /etc/apt/trusted.gpg.d: Value too large for defined data type12:04
stekernhaha, is it 'real' enough for you now, huh? =)12:06
blueCmdbah :P12:07
stekernblueCmd: yes, it builds without that, but the xmkmf generated Makefile lacks -D__or1k__ and has some variable name in it's place12:19
blueCmdstekern: right, good. the upstreaming of a new arch is the easy part12:25
stekernyay, gstreamer is done13:26
blueCmdstekern: woo :)14:26
blueCmdso, stekern - the boot rom generator.14:27
blueCmdI don't want to be forced to boot the CPU using OpenOCD14:28
blueCmdI found some nice stuff in the old irclogs14:48
stekernyeah, I'd just take the .S feom orpsocv2 and work from that15:26
blueCmdstekern: so. I modified the rom.v, but if I stop the CPU and do mdw 0xf000000 1000 there is nothing there16:59
blueCmdeverything is zero16:59
blueCmdhow do you guys generally do debugging on these things? I could create a testbench and load it up in modelsim, but if that was the case you do it I feel like it would be documented17:08
blueCmdI'm thinking that you're using this verilator thing, but I don't know anything about it.17:08
blueCmdolofk: "elf-loader: Unable to find a 'elf-loader.vpi' module on the search path.17:21
blueCmdjtag_vpi: Unable to find a 'jtag_vpi.vpi' module on the search path17:21
blueCmdI guess the cores 'elf-loader' and 'jtag_vpi' needs to be built somehow17:22
stekernyou "can't" read the ROM from gdb/openocd17:24
stekernit's only connected to the instruction bus17:24
blueCmdhahah. right17:25
stekernit's easy to change though17:25
blueCmdand now I know why the code doesn't work :)17:25
blueCmdi added some UART printing that reads a string and prints it17:25
stekernah, right17:25
blueCmdthat will work wooonderful if only the instruction bus is connected17:25
stekernthe cpus dbus should be connected to it17:26
stekernas in, it's not, but it should17:26
blueCmdwhat about master dbg?17:27
blueCmdwhat's that?17:27
stekernthat's the one you use when you use openocd17:27
blueCmdright, I want that one as well17:28
stekernhook it up17:30
stekerngraphicsmagick-1.3.18 done17:30
blueCmdcareful stekern, it's addicting17:31
stekernmy current goals are emacs23 and scummvm17:32
stekernI've got in a dependency loop between lwm2 and libcman-dev17:33
stekernfor scummvm17:33
blueCmdyes, those are very very very very very common17:33
blueCmdruby build-depends on....17:34
stekernand pkg-config depends on pkg-config17:34
blueCmdoh pkg-config is the bastard child17:34
blueCmdnobody likes it17:35
stekern..but everbody uses it17:35
blueCmd#debian-bootstrap would like to kill it with fire17:35
blueCmdstekern: well, using it is fine. compiling it is not :)17:35
blueCmdhm, still empty17:37
stekernyeah, it depends on glib-2.017:37
stekernwhich isn't the most trivial thing17:37
blueCmdso what I did: i added the rom to _d and dbg, ran wb_interconn_thing and rebuilt it17:37
blueCmdstekern: you don't say? :)17:37
blueCmdstekern: I think I spent 3+ days on getting glib-2.0 compiled17:38
stekernI'm not surprised, I spent some time on it when I tried to cross-compile irssi with uclibc17:38
stekerndefine 'empty'17:39
stekernah, zero17:39
blueCmdmdw 0xf0000000 100 shows all zeros17:40
stekernhow does that rom.v look like now then?17:40
blueCmd is the diff17:43
blueCmdbootrom.v is also uploaded there17:43
blueCmdI'm going to change the default value to aa55 or something and see if that shows up17:43
stekerndo that, but isn't it mapped to 0xf000010017:45
blueCmdyes, but i'm reading past that17:45
blueCmdnow it shows up17:47
blueCmdwell, something shows up - it's not the correct things17:47
stekerntry to reset the board, and only read 0xf000010017:47 rule out that the bus get's in a funny state when you are generating bus faults by reading out of bound addresses17:48
blueCmdmdw 0xf000010017:48
blueCmd0xf0000100: 0ffffff917:48
blueCmdthat's the same value I got when i said 'huh'17:49
blueCmdit's not what bootrom.v shows, but it's not 0 at least17:49
stekernshow the wb_intercon.conf too17:49
blueCmdyeah it's uploaded at the same url but wb_intercon.conf17:50
blueCmd < new output from openocd17:50
blueCmd64 : wb_dat_o <=  32'h0ffffff9;17:51
blueCmdyes, the 64 and lower is mapped17:51
stekernok, did you change the address length?17:52
blueCmdto 717:52
blueCmd0-128 is my thinking17:52
blueCmdor is every row 4 addrs?17:53
blueCmdthat would make sense wouldn't it17:53
blueCmdno, it's a 32 bit wide bus, should be fine17:54
blueCmdwb_m2s_rom0_adr[(rom0_aw + 2) - 1 : 2] - right17:55
stekernand you've changed rom0_aw?17:55
blueCmdyes, 7 as well17:55
blueCmdi'm not 100% sure about that 7 though17:56
blueCmdno, it should be 7 I think17:56
stekernyeah, that should be 128 words17:57
blueCmdbumping both to 8 for the hell of it17:59
stekern256 is nice round number18:00
blueCmdha, nope - still the same18:04
blueCmd0xf0000100 is mapped to 64->18:05
stekernoh... yeah, it's not going to work18:06
stekernyou'll have to waste the 64 first entries if you want a bootrom larger than 64 entries18:07
blueCmdah, because of the 0x100 start offset?18:08
blueCmdso why 64 and not 128?18:08
stekernbecause 0x100 is 64 words18:09
blueCmdwhy not 256_18:09
blueCmdyes, makes sense18:09
stekernso, create a bootrom that has the first 64 as zero, and map it to 0xf000010018:10
* blueCmd is on it!18:10
stekernmap it to 0xf0000000 I mean!18:11
stekernand then bonus score for doing address decoding in the bootrom to not waste those 64 words18:11
stekernblueCmd: your turn to help me:
blueCmdwhy? it's not using anything18:13
blueCmd/bin/chown: cannot access '/etc/dma/*': No such file or directory18:14
blueCmdis there something in /etc/dma/ ?18:14
blueCmdif yes: then this might be the readdir bug18:14
stekernread the pastie to the end ;)18:14
blueCmdsorry :D18:14
blueCmdyes, I have seen this before. usually I just did dpkg-reconfigure dash and it worked, but it might be readdir18:14
olofkblueCmd: My new wb_ram component supports preloading a verilog memory file, so we can have a preinitialized boot RAM. That should work for uboot.18:15
olofkIt has the added benefit that we can have a default boot loader and overwrite it with a debugger if we want18:16
stekernyeah, we should use that18:16
olofkUnfortunately it's not possible to use the output from or1k-elf-objcopy -O verilog directly, since that only supports byte memories18:16
olofkAnd it's not trivial to make XST understand that it should use a 32-bit wide memory, so it uses four 8-bit ones instead18:17
olofkBut for now I just delete the spaces between the data in the generated memory file to make it look like a 32-bit file18:18
olofkI will probably add a small python hack to do that instead until I figure out a better way18:18
blueCmdolofk: cool! how do I use it?18:18
olofkAdd a dependency on wb_ram in your .core18:21
blueCmdvery nice18:21
olofkoh... and add the memory file to your include_files in the [verilog] section18:21
olofkSo it gets copied to the build directory18:22
olofkFor reference, my led_blink.vh looks like this
blueCmdolofk: XST? isn't that a xilinx thing?18:25
stekernblueCmd: dpkg-reconfigure dash?18:25
blueCmdstekern: yes18:26
blueCmddon't ask me why it worked for me, but it did something18:26
olofkblueCmd: Yes18:26
blueCmdolofk: I'm using an Altera board, will that be a problem?18:26
olofkblueCmd: Hopefully not18:26
olofkThe goal is to write a generic verilog file that gets mapped efficiently to FPGA-specific resources18:27
olofkBut as it took some quirks to make XST recognize what I was trying to do, I can't guarantee that quartus understand it18:27
olofkoh, and my memory is mapped to address 0x0, so if you map it to 0x100 instead, you can probably decrease the size18:35
olofkDoes anyone know how large a uboot binary is btw?18:37
stekern-rwxrwxr-x 1 stefan stefan 190K Oct 25  2013 /home/stefan/openrisc/
stekernI removed the /etc/dma dir to see if that made a difference18:57
stekernnow it says: Not replacing deleted config file /etc/dma/dma.conf18:58
stekernhow could it replace something that doesn't exist...18:58
blueCmdyes, that's what it's saying :P19:02
stekernhow does it know that I deleted it?19:05
blueCmdit has indexes over all installed files19:11
stekernI think it watches over my shoulder19:14
stekernbut why does it matter if it's run from dpkg or manually?19:15
stekernthe chown I mean19:15
blueCmdI think that it's the glob evaluation19:25
blueCmdwhich depends on the shell19:25
stekernhmm, right19:30
stekernso is dpkg using some own shell?19:30
blueCmdI think it's using dash19:32
stekernok, yeah, if I do dash; chown root:mail /etc/dma/*19:36
stekernit goes: /bin/chown: cannot access '/etc/dma/*': No such file or directory19:36
blueCmdPlease debug that! :)19:37
stekernso, ls * fails too19:38
stekerneasily reproducable19:38
stekerncan you try that?19:38
blueCmdyep doesn't work for me either19:40
stekernalot of packages should update their config.guess and config.sub19:47
blueCmdyes, there is a list of those packages19:47
stekernok, should I add the ones I find to that list?19:47
blueCmdI'm having some trouble getting the bootrom doing what I want to do, and I'm not sure if it's hardware, fpga or software. running the bootrom in or1k would help, but AFAIK I need a linker script to make the ELF place stuff at 0xf0000100 - or am I wrong?20:59
stekernblueCmd: isn't it just an asm?21:05
stekernthat is selfcontained21:05
blueCmdsure, but is .org 0xf0000100 enough?21:06
stekerntry?21:06 0x100 wasn't, and or1ksim was executing 0x10021:06
blueCmdbut I'll give 0xf.. a got21:06
blueCmdheh. .org 0xf0000100 creates a 4G file21:08
blueCmdah, linker scripts wasn't that hard21:14
stekernthis temacs executable doesn't seem to work very well...21:17
blueCmdstekern: so. my uart code works in or1ksim. it blocks on the "waiting for UART" stage (spinlooping on an address until it's a certain value). I see that npc is stuck in the loop using openocd, but all regs (using "reg r29" for example) is zero21:54
blueCmdI think the wb_interconn maybe did the wrong thing. the diff there is massive for a small thing22:25
blueCmdhm yes, just running /home/bluecmd/work/orpsoc-cores/cores/wb_intercon/sw/wb_intercon_gen data/wb_intercon.conf rtl/verilog/wb_intercon.v22:33
blueCmdcreates a big diff, even for a non-modified wb_intercon.conf22:34
blueCmdsomething with resize22:34
blueCmdyep! generating a clean, generating a modified, diffing those and applying that diff on the interconnect worked just fine! woo! uart!! :D22:39
--- Log closed Mon Apr 28 00:00:15 2014

Generated by 2.15.2 by Marius Gedminas - find it at!