| --- Log opened Sun Apr 27 00:00:23 2014 | ||
| stekern | blueCmd: hehe, "if", isn't a broken readdir a real problem? ;) | 05:14 |
|---|---|---|
| stekern | wtf... 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-dev | 07:15 |
| stekern | man, this is like gentoo relived, a little hack there and a little hack there and the packages start building ;) | 07:32 |
| stekern | blueCmd: 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 |
| stekern | err, xutils-dev I mean | 07:42 |
| stekern | blueCmd: when we are building packages, _FILEOFFSET_BITS is getting detected to 64 | 08:03 |
| stekern | ah, poking around wannabuild a bit more I see how nifty it is | 08:45 |
| blueCmd | stekern: (FILEOFFSET) really? how? | 10:53 |
| blueCmd | stekern: (xutils)yes, please do. RAWCPP didn't fix it? | 10:54 |
| Findeton | yay | 11:02 |
| stekern | blueCmd: (FILEOFFSET) dunno, just saw it swooshing by in the ./configure phase, will revisit that | 11:46 |
| blueCmd | cool, thanks | 11: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-buildpackage | 11:48 |
| stekern | If I go into the build-dir and do a 'rm xmkmf && make' it'll generate it correctly | 11:48 |
| stekern | then 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-install | 11:49 |
| stekern | http://oompa.chokladfabriken.org/openrisc/hacks/linux.cf | 11:54 |
| stekern | Or1kArchitecture in that | 11:55 |
| stekern | for instance | 11:55 |
| blueCmd | ah | 11:55 |
| blueCmd | does it build without that? | 11:56 |
| blueCmd | run-parts: failed to open directory /etc/apt/trusted.gpg.d: Value too large for defined data type | 12:04 |
| blueCmd | :( | 12:04 |
| stekern | haha, is it 'real' enough for you now, huh? =) | 12:06 |
| blueCmd | bah :P | 12:07 |
| stekern | blueCmd: yes, it builds without that, but the xmkmf generated Makefile lacks -D__or1k__ and has some variable name in it's place | 12:19 |
| blueCmd | https://github.com/bluecmd/or1k-debian/issues/32 | 12:24 |
| blueCmd | stekern: right, good. the upstreaming of a new arch is the easy part | 12:25 |
| stekern | yay, gstreamer is done | 13:26 |
| blueCmd | stekern: woo :) | 14:26 |
| blueCmd | so, stekern - the boot rom generator. | 14:27 |
| blueCmd | I don't want to be forced to boot the CPU using OpenOCD | 14:28 |
| blueCmd | I found some nice stuff in the old irclogs | 14:48 |
| stekern | yeah, I'd just take the .S feom orpsocv2 and work from that | 15:26 |
| blueCmd | stekern: so. I modified the rom.v, but if I stop the CPU and do mdw 0xf000000 1000 there is nothing there | 16:59 |
| blueCmd | everything is zero | 16:59 |
| blueCmd | how 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 documented | 17:08 |
| blueCmd | I'm thinking that you're using this verilator thing, but I don't know anything about it. | 17:08 |
| blueCmd | olofk: "elf-loader: Unable to find a 'elf-loader.vpi' module on the search path. | 17:21 |
| blueCmd | jtag_vpi: Unable to find a 'jtag_vpi.vpi' module on the search path | 17:21 |
| blueCmd | I guess the cores 'elf-loader' and 'jtag_vpi' needs to be built somehow | 17:22 |
| stekern | you "can't" read the ROM from gdb/openocd | 17:24 |
| blueCmd | oh | 17:24 |
| stekern | it's only connected to the instruction bus | 17:24 |
| blueCmd | hahah. right | 17:25 |
| stekern | it's easy to change though | 17:25 |
| blueCmd | and now I know why the code doesn't work :) | 17:25 |
| blueCmd | i added some UART printing that reads a string and prints it | 17:25 |
| stekern | ah, right | 17:25 |
| blueCmd | that will work wooonderful if only the instruction bus is connected | 17:25 |
| stekern | the cpus dbus should be connected to it | 17:26 |
| stekern | as in, it's not, but it should | 17:26 |
| blueCmd | what about master dbg? | 17:27 |
| blueCmd | what's that? | 17:27 |
| stekern | that's the one you use when you use openocd | 17:27 |
| blueCmd | right, I want that one as well | 17:28 |
| stekern | hook it up | 17:30 |
| stekern | graphicsmagick-1.3.18 done | 17:30 |
| blueCmd | careful stekern, it's addicting | 17:31 |
| stekern | my current goals are emacs23 and scummvm | 17:32 |
| stekern | I've got in a dependency loop between lwm2 and libcman-dev | 17:33 |
| stekern | for scummvm | 17:33 |
| blueCmd | yes, those are very very very very very common | 17:33 |
| blueCmd | very | 17:34 |
| blueCmd | ruby build-depends on.... | 17:34 |
| blueCmd | ruby! | 17:34 |
| stekern | and pkg-config depends on pkg-config | 17:34 |
| blueCmd | oh pkg-config is the bastard child | 17:34 |
| blueCmd | nobody likes it | 17:35 |
| stekern | ..but everbody uses it | 17:35 |
| blueCmd | #debian-bootstrap would like to kill it with fire | 17:35 |
| blueCmd | stekern: well, using it is fine. compiling it is not :) | 17:35 |
| stekern | ;) | 17:36 |
| blueCmd | hm, still empty | 17:37 |
| stekern | yeah, it depends on glib-2.0 | 17:37 |
| stekern | which isn't the most trivial thing | 17:37 |
| blueCmd | so what I did: i added the rom to _d and dbg, ran wb_interconn_thing and rebuilt it | 17:37 |
| blueCmd | stekern: you don't say? :) | 17:37 |
| blueCmd | stekern: I think I spent 3+ days on getting glib-2.0 compiled | 17:38 |
| stekern | I'm not surprised, I spent some time on it when I tried to cross-compile irssi with uclibc | 17:38 |
| stekern | define 'empty' | 17:39 |
| stekern | ah, zero | 17:39 |
| blueCmd | mdw 0xf0000000 100 shows all zeros | 17:40 |
| stekern | how does that rom.v look like now then? | 17:40 |
| blueCmd | http://storage.googleapis.com/bluecmd-openrisc/rom.v | 17:41 |
| blueCmd | http://a746844a62d280b7.paste.se/ is the diff | 17:43 |
| blueCmd | bootrom.v is also uploaded there | 17:43 |
| blueCmd | I'm going to change the default value to aa55 or something and see if that shows up | 17:43 |
| stekern | do that, but isn't it mapped to 0xf0000100 | 17:45 |
| blueCmd | yes, but i'm reading past that | 17:45 |
| blueCmd | http://c9d2496aa134adaf.paste.se/ | 17:46 |
| blueCmd | huh | 17:46 |
| blueCmd | now it shows up | 17:47 |
| blueCmd | well, something shows up - it's not the correct things | 17:47 |
| stekern | try to reset the board, and only read 0xf0000100 | 17:47 |
| stekern | ...to rule out that the bus get's in a funny state when you are generating bus faults by reading out of bound addresses | 17:48 |
| blueCmd | mdw 0xf0000100 | 17:48 |
| blueCmd | 0xf0000100: 0ffffff9 | 17:48 |
| blueCmd | that's the same value I got when i said 'huh' | 17:49 |
| blueCmd | it's not what bootrom.v shows, but it's not 0 at least | 17:49 |
| stekern | show the wb_intercon.conf too | 17:49 |
| blueCmd | yeah it's uploaded at the same url but wb_intercon.conf | 17:50 |
| blueCmd | http://a6e0177c644ae6a8.paste.se/ < new output from openocd | 17:50 |
| blueCmd | ah | 17:51 |
| blueCmd | 64 : wb_dat_o <= 32'h0ffffff9; | 17:51 |
| blueCmd | yes, the 64 and lower is mapped | 17:51 |
| stekern | ok, did you change the address length? | 17:52 |
| blueCmd | yes | 17:52 |
| blueCmd | to 7 | 17:52 |
| blueCmd | 0-128 is my thinking | 17:52 |
| blueCmd | uhm | 17:53 |
| blueCmd | or is every row 4 addrs? | 17:53 |
| blueCmd | that would make sense wouldn't it | 17:53 |
| blueCmd | no, it's a 32 bit wide bus, should be fine | 17:54 |
| blueCmd | wb_m2s_rom0_adr[(rom0_aw + 2) - 1 : 2] - right | 17:55 |
| stekern | yes | 17:55 |
| stekern | and you've changed rom0_aw? | 17:55 |
| blueCmd | yes, 7 as well | 17:55 |
| blueCmd | i'm not 100% sure about that 7 though | 17:56 |
| blueCmd | no, it should be 7 I think | 17:56 |
| stekern | yeah, that should be 128 words | 17:57 |
| blueCmd | bumping both to 8 for the hell of it | 17:59 |
| stekern | 256 is nice round number | 18:00 |
| blueCmd | ha, nope - still the same | 18:04 |
| blueCmd | 0xf0000100 is mapped to 64-> | 18:05 |
| stekern | oh... yeah, it's not going to work | 18:06 |
| blueCmd | hm? | 18:06 |
| stekern | you'll have to waste the 64 first entries if you want a bootrom larger than 64 entries | 18:07 |
| blueCmd | ah, because of the 0x100 start offset? | 18:08 |
| stekern | yes | 18:08 |
| blueCmd | so why 64 and not 128? | 18:08 |
| stekern | ? | 18:08 |
| blueCmd | erhm | 18:08 |
| stekern | because 0x100 is 64 words | 18:09 |
| blueCmd | why not 256_ | 18:09 |
| blueCmd | ah | 18:09 |
| blueCmd | ofc | 18:09 |
| blueCmd | yes, makes sense | 18:09 |
| blueCmd | thanks! | 18:10 |
| stekern | so, create a bootrom that has the first 64 as zero, and map it to 0xf0000100 | 18:10 |
| * blueCmd is on it! | 18:10 | |
| stekern | map it to 0xf0000000 I mean! | 18:11 |
| stekern | and then bonus score for doing address decoding in the bootrom to not waste those 64 words | 18:11 |
| stekern | blueCmd: your turn to help me: http://pastie.org/9117698 | 18:13 |
| blueCmd | why? it's not using anything | 18:13 |
| blueCmd | /bin/chown: cannot access '/etc/dma/*': No such file or directory | 18:14 |
| blueCmd | is there something in /etc/dma/ ? | 18:14 |
| blueCmd | if yes: then this might be the readdir bug | 18:14 |
| stekern | read the pastie to the end ;) | 18:14 |
| blueCmd | right | 18:14 |
| blueCmd | sorry :D | 18:14 |
| blueCmd | yes, I have seen this before. usually I just did dpkg-reconfigure dash and it worked, but it might be readdir | 18:14 |
| olofk | blueCmd: 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 |
| olofk | It has the added benefit that we can have a default boot loader and overwrite it with a debugger if we want | 18:16 |
| stekern | yeah, we should use that | 18:16 |
| olofk | Unfortunately it's not possible to use the output from or1k-elf-objcopy -O verilog directly, since that only supports byte memories | 18:16 |
| olofk | And it's not trivial to make XST understand that it should use a 32-bit wide memory, so it uses four 8-bit ones instead | 18:17 |
| olofk | But for now I just delete the spaces between the data in the generated memory file to make it look like a 32-bit file | 18:18 |
| olofk | I will probably add a small python hack to do that instead until I figure out a better way | 18:18 |
| blueCmd | olofk: cool! how do I use it? | 18:18 |
| olofk | blueCmd: http://pastebin.com/n6P7EMq7 | 18:21 |
| olofk | Add a dependency on wb_ram in your .core | 18:21 |
| blueCmd | very nice | 18:21 |
| olofk | oh... and add the memory file to your include_files in the [verilog] section | 18:21 |
| olofk | So it gets copied to the build directory | 18:22 |
| olofk | For reference, my led_blink.vh looks like this http://0d587691aaa13fe1.paste.se/ | 18:23 |
| blueCmd | olofk: XST? isn't that a xilinx thing? | 18:25 |
| stekern | blueCmd: dpkg-reconfigure dash? | 18:25 |
| blueCmd | stekern: yes | 18:26 |
| blueCmd | don't ask me why it worked for me, but it did something | 18:26 |
| olofk | blueCmd: Yes | 18:26 |
| blueCmd | olofk: I'm using an Altera board, will that be a problem? | 18:26 |
| olofk | blueCmd: Hopefully not | 18:26 |
| olofk | The goal is to write a generic verilog file that gets mapped efficiently to FPGA-specific resources | 18:27 |
| olofk | But as it took some quirks to make XST recognize what I was trying to do, I can't guarantee that quartus understand it | 18:27 |
| olofk | oh, and my memory is mapped to address 0x0, so if you map it to 0x100 instead, you can probably decrease the size | 18:35 |
| olofk | Does anyone know how large a uboot binary is btw? | 18:37 |
| stekern | -rwxrwxr-x 1 stefan stefan 190K Oct 25 2013 /home/stefan/openrisc/openrisc.net/u-boot/u-boot.bin | 18:54 |
| stekern | I removed the /etc/dma dir to see if that made a difference | 18:57 |
| stekern | now it says: Not replacing deleted config file /etc/dma/dma.conf | 18:58 |
| stekern | how could it replace something that doesn't exist... | 18:58 |
| blueCmd | yes, that's what it's saying :P | 19:02 |
| stekern | mmm | 19:05 |
| stekern | how does it know that I deleted it? | 19:05 |
| blueCmd | it has indexes over all installed files | 19:11 |
| stekern | I think it watches over my shoulder | 19:14 |
| stekern | but why does it matter if it's run from dpkg or manually? | 19:15 |
| stekern | the chown I mean | 19:15 |
| blueCmd | I think that it's the glob evaluation | 19:25 |
| blueCmd | which depends on the shell | 19:25 |
| stekern | hmm, right | 19:30 |
| stekern | so is dpkg using some own shell? | 19:30 |
| blueCmd | I think it's using dash | 19:32 |
| stekern | ok, yeah, if I do dash; chown root:mail /etc/dma/* | 19:36 |
| stekern | it goes: /bin/chown: cannot access '/etc/dma/*': No such file or directory | 19:36 |
| blueCmd | Please debug that! :) | 19:37 |
| stekern | mmm | 19:37 |
| stekern | so, ls * fails too | 19:38 |
| stekern | easily reproducable | 19:38 |
| stekern | can you try that? | 19:38 |
| blueCmd | yep doesn't work for me either | 19:40 |
| stekern | alot of packages should update their config.guess and config.sub | 19:47 |
| blueCmd | yes, there is a list of those packages | 19:47 |
| stekern | ok, should I add the ones I find to that list? | 19:47 |
| blueCmd | stekern: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=autoreconf;users=debian-devel@lists.debian.org | 19:49 |
| blueCmd | I'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 |
| stekern | blueCmd: isn't it just an asm? | 21:05 |
| blueCmd | yes | 21:05 |
| stekern | that is selfcontained | 21:05 |
| blueCmd | sure, but is .org 0xf0000100 enough? | 21:06 |
| stekern | try? | 21:06 |
| blueCmd | .org 0x100 wasn't, and or1ksim was executing 0x100 | 21:06 |
| blueCmd | but I'll give 0xf.. a got | 21:06 |
| blueCmd | go* | 21:06 |
| blueCmd | heh. .org 0xf0000100 creates a 4G file | 21:08 |
| blueCmd | ah, linker scripts wasn't that hard | 21:14 |
| stekern | this temacs executable doesn't seem to work very well... | 21:17 |
| blueCmd | stekern: 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 zero | 21:54 |
| blueCmd | I think the wb_interconn maybe did the wrong thing. the diff there is massive for a small thing | 22:25 |
| blueCmd | hm yes, just running /home/bluecmd/work/orpsoc-cores/cores/wb_intercon/sw/wb_intercon_gen data/wb_intercon.conf rtl/verilog/wb_intercon.v | 22:33 |
| blueCmd | creates a big diff, even for a non-modified wb_intercon.conf | 22:34 |
| blueCmd | something with resize | 22:34 |
| blueCmd | yep! generating a clean, generating a modified, diffing those and applying that diff on the interconnect worked just fine! woo! uart!! :D | 22:39 |
| --- Log closed Mon Apr 28 00:00:15 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!