| --- Log opened Fri Jul 04 00:00:03 2014 | ||
| sb0 | stekern, so the exception vectors are very large (256 bytes), but still can't fit the _exception_handler that saves all registers? meh! | 08:07 |
|---|---|---|
| stekern | yes, it's just silly how the vectors are defined in or1k | 08:08 |
| stekern | it should just be 8bytes per vector | 08:08 |
| sb0 | so we use 32/256 bytes, and then add some jumps that slow things up a bit more and waste a bit of memory | 08:08 |
| stekern | jumps are 1-cycle instructions on mor1kx though | 08:10 |
| sb0 | also, we can get rid of most of the context save/restore for system calls, I guess? | 08:11 |
| stekern | system calls where? | 08:12 |
| stekern | I mean, what implementation of the system calls are you looking at? | 08:12 |
| sb0 | the bare-metal crt | 08:13 |
| sb0 | well I guess you just used the 'standard' exception handling code for the system call exception | 08:13 |
| stekern | ah, yes... | 08:13 |
| stekern | you can optmize that code *a lot*, I just threw together something that would work | 08:14 |
| stekern | sb0: btw: The purpose of IT Center mailbox is for sending mass-emails when needed. No-one actively reads this mailbox unless separately agreed. | 08:16 |
| stekern | Should you need helps with IT issues, please contact IBM Helpdesk, tel 41111, email #IBMHDFi | 08:16 |
| stekern | bah! | 08:16 |
| sb0 | ? | 08:16 |
| stekern | https://github.com/openrisc/mor1kx/commit/bae88d1bbc3f0dd12aacb9d119902b4a0c5a7e1b | 08:16 |
| stekern | I fat-fingered the copy-paste :/ | 08:16 |
| sb0 | ah, great. thanks a lot! | 08:16 |
| blueCmd | sb0: you now know the purpose of the IT Center mailbox though | 10:52 |
| blueCmd | and who to contact if you have IT issues | 10:52 |
| blueCmd | olofk: how do I format my .bin file to readmemh format? | 12:22 |
| sb0 | blueCmd, you should try migen. Memory(size, width, ..., init=python list with the init data) | 12:28 |
| sb0 | and converting a bin file to list in python is trivial | 12:29 |
| blueCmd | sb0: I've been thinking about trying it out, but I'm using a sh*tton of things from orpsoc-cores atm, and AFAIK fusesoc is the only software that does that | 12:34 |
| stekern | otoh, converting a bin to readmemh in python is also trivial | 12:34 |
| stekern | you can use srecord too | 12:34 |
| ysionneau | hum isn't there some objcopy verilog backend? | 12:35 |
| stekern | objcopy can output as well, but there was some problem that it only did byte arrays iirc | 12:35 |
| ysionneau | https://sourceware.org/ml/binutils/2009-04/msg00321.html | 12:35 |
| ysionneau | ok | 12:35 |
| blueCmd | sb0: https://github.com/m-labs/migen/blob/adda930c682a6b2e2bb4e8b8d6da0ab055755645/migen/fhdl/specials.py#L235 | 12:36 |
| blueCmd | have you thought about using a template engine or something? | 12:36 |
| sb0 | blueCmd, what orpsoc-cores features do you need? | 12:37 |
| sb0 | blueCmd, no, but that's something that could be explored | 12:37 |
| ysionneau | I used some makefile like that to generate the .vh file | 12:37 |
| ysionneau | https://github.com/fallen/lm32/blob/asid/test/unittests/Makefile#L112 | 12:38 |
| ysionneau | the .vh is then read using $readmemh() | 12:39 |
| blueCmd | sb0: I need uart, i2c, spi, ram_wb cores | 12:41 |
| blueCmd | ysionneau: cool! thanks | 12:41 |
| sb0 | misoc has uart and wishbone ram | 12:42 |
| sb0 | also, if that wishbone ram is for the bootloader (bios), you just have to use the IntegratedBIOS class and the bios gets built and loaded properly | 12:44 |
| sb0 | for both lm32 and or1k | 12:44 |
| stekern | sb0: reminds me, it would be fun to merge the Linux drivers for the misoc/milkymist into an openrisc tree | 12:45 |
| stekern | *cores | 12:45 |
| stekern | for what cores do you have drivers? | 12:45 |
| sb0 | there are no linux drivers for misoc atm... there are some for the legacy soc, which could be used as a base | 12:45 |
| sb0 | since the misoc cores aren't very different | 12:46 |
| stekern | was there any for the minimac? | 12:46 |
| sb0 | blueCmd, here are some example cores: https://github.com/m-labs/misoc/blob/master/misoclib/timer/__init__.py https://github.com/m-labs/misoc/blob/master/misoclib/uart/__init__.py | 12:47 |
| sb0 | should be easy to write spi/i2c ones *g* | 12:47 |
| sb0 | stekern, not sure, and minimac is being overhauled atm | 12:47 |
| sb0 | so I'd wait a bit before writing a driver for it | 12:47 |
| stekern | I think some guy had an unpublished driver for the old minimac | 12:48 |
| stekern | he added it to orpsoc-cores | 12:48 |
| sb0 | would be fun to have uart still | 12:48 |
| sb0 | and you can use ppp :) | 12:48 |
| ysionneau | that is so much easier to read in python | 12:48 |
| ysionneau | pfew | 12:48 |
| stekern | isn't there a driver for the uart? or is that different in misoc? | 12:49 |
| sb0 | it's different in misoc, but similar | 12:49 |
| sb0 | should be just a few lines to change in the old driver | 12:50 |
| sb0 | you need a timer driver too | 12:51 |
| stekern | ysionneau: to my untrained migen eye, I think it'd be easier to read in verilog ;) | 12:51 |
| sb0 | stekern, you have much more boilerplate though | 12:51 |
| stekern | that doesn't make it so though | 12:51 |
| sb0 | here's another core: https://github.com/m-labs/blinkie/blob/master/targets/blinkie.py#L10 | 12:51 |
| sb0 | (and how to put it into a soc) | 12:51 |
| stekern | I had the same feeling the first times I looked at verilog vs VHDL | 12:52 |
| ysionneau | stekern: for the timer example? | 12:54 |
| stekern | sb0: well, if I'm planning on using or1k, I've got the builtin timer that I can use in the meantime | 12:55 |
| sb0 | meh | 12:55 |
| stekern | the timer code in Linux (can be) pretty botched into the arch specific code too | 12:55 |
| sb0 | yeah, so easy, we should do the same for uart, framebuffer and disk io | 12:56 |
| sb0 | ;) | 12:56 |
| stekern | yup, no need to set-up io mappings ;) | 12:56 |
| blueCmd | sb0: i'll definitely have a look, but currently I'm just bootstrapping my design - I work by writing as little code as possible, and later replace parts that doesn't perform as I want it. at the second iteration I might use migen. I was thinking of using fusesoc but I'm not 100% sure it fits the bill | 12:57 |
| stekern | no, I agree, for my SMP stuff, it's just annoying that we have that builtin timer deeply assumed in the arch code | 12:57 |
| blueCmd | sb0: well, the UART you linked wors for very simple things, but I need it to be wishbone | 12:58 |
| stekern | ysionneau: for both | 12:58 |
| sb0 | blueCmd, why? | 12:58 |
| sb0 | note that this design is bus-independent | 12:58 |
| ysionneau | stekern: maybe I'm already used to migen, but I only attended one workshop and wrote very few lines of it :) | 12:58 |
| sb0 | there's later another "core" that collects all the CSRs and builds the bus-dependent interface | 12:59 |
| stekern | ysionneau: even a few lines is eternally more than I have done ;) | 12:59 |
| stekern | ysionneau: but a timer in verilog isn't very complex neither: https://github.com/skristiansson/orpsoc-cores/blob/multicore/cores/timer/rtl/verilog/timer.v | 13:00 |
| ysionneau | yes sure | 13:00 |
| stekern | admittedly, that's more simple than the migen example though | 13:01 |
| blueCmd | sb0: how would my software write to the UART? | 13:01 |
| sb0 | stekern, in migen that would be: self.tc = CSRStorage(32); self.sync += self.tc.storage.eq(self.tc.storage+1) | 13:02 |
| sb0 | still less than the verilog :p | 13:02 |
| sb0 | CSRStorage -> CSRStatus | 13:03 |
| stekern | if I want to use the wb lib? | 13:03 |
| sb0 | blueCmd, https://github.com/m-labs/misoc/blob/master/software/libbase/uart.c | 13:04 |
| ysionneau | blueCmd: CSRs end up memory mapped, so you can just access the CSR registers via their memory address | 13:04 |
| sb0 | stekern, csrgen.Bank (which is used in the base SoC classes) builds the actual bus interface, and connects the CSR member signals | 13:05 |
| stekern | but if I want to use wb without the CSR? | 13:06 |
| stekern | or is there always a wb<->csr converter generated? | 13:06 |
| sb0 | you can (write and) use another csrgen.Bank that generates wb directly | 13:07 |
| stekern | I'm thinking, if I want to make my core also usable outside a migen generated soc? | 13:07 |
| sb0 | the internal csr bus is entirely optional | 13:07 |
| sb0 | you can also use the csr bus in verilog, like the old soc does | 13:08 |
| ysionneau | for low throughput cores, isn't it more efficient to use wb<->wbToCsrBridge<->csr ? instead of having tons of wb devices which means tons of wires ? | 13:08 |
| sb0 | it's just wishbone without ack and other signals that are useless for csrs... | 13:08 |
| stekern | yes, but my point would be to "make a standalone core with wb interface" | 13:08 |
| sb0 | yeah, you can do that too | 13:08 |
| stekern | but I'll take a look myself and I bet I get my questions answered ;) | 13:09 |
| sb0 | just pass the wishbone ios to verilog.convert() | 13:09 |
| sb0 | actually, you could write a script that takes any misoc core that has csrs and exports it to verilog with a wishbone if | 13:09 |
| sb0 | that's not hard | 13:10 |
| stekern | ok, cool | 13:10 |
| sb0 | that being said, verilog sucks ass | 13:10 |
| stekern | sure, but it's widely used. | 13:11 |
| stekern | I mean, you can't expect people to go changing existing codebases to migen just to use one single core | 13:13 |
| stekern | (and obviously that's not the case, I'm just motivating my question) | 13:14 |
| blueCmd | ysionneau: I see. CSR is another bus then I guess? | 13:15 |
| sb0 | phew. such conservatism is responsible for a lot of technological mishaps. look at x86, thunderbolt, hdmi, cobol, and or1k NMI and exception vectors ;) | 13:17 |
| ysionneau | blueCmd: yep CSR is a bus for low throughput things like configuration registers for other cores, and it's connected to Wishbone by a bridge | 13:17 |
| sb0 | but well, yeah | 13:18 |
| blueCmd | sb0: I'm pretty excited about the prospect of having my design written in python instead of bulky verilog | 13:18 |
| sb0 | ooh, and FPGA "designs" committed with matlab/edk/labview. I cannot count how many labs have them, and are deeply unhappy with that. | 13:20 |
| blueCmd | ysionneau: your 'objdump' line didn't work that well for me :( | 13:22 |
| blueCmd | http://3f0460f99e390ff6.paste.se/ | 13:22 |
| _franck__ | at least when you code with verilog/VHDL you're not fear that the synthesizer has bug (unlike using mignen) | 13:22 |
| _franck__ | I mean migen is on top of that, so you have another layer which could have bugs | 13:23 |
| blueCmd | _franck__: what? I always fear that :P | 13:23 |
| ysionneau | blueCmd: what's in your paste? | 13:23 |
| sb0 | _franck_, obviously, you haven't tracked down ISE and Migen bugs yet ;) | 13:23 |
| blueCmd | ysionneau: output of hexdump -Cv bpi.bin | awk 'BEGIN { FS=" " } ; { for (i = 2 ; i < 18 ; i++) { printf "%s ",$$i } ; print " " }' > bin.hex | 13:23 |
| sb0 | migen is actually quite reliable now, and easy to debug in the rare cases when it does break (I've put some effort into a name-mangling algo that makes the generated verilog quite readable) | 13:25 |
| sb0 | I've never spent more than a couple hours on a migen bug. ISE bugs, however, cost me weeks or months sometimes. | 13:25 |
| sb0 | plus all the xilinx bureaucracy that needs to grind in order to get them fixed | 13:26 |
| sb0 | and the interesting tools you need at times, like freeze sprays when the timing analyzer is a bit off | 13:27 |
| sb0 | and yes, that happens. really, migen bugs are very tame in comparison. | 13:28 |
| ysionneau | blueCmd: I have the same issue here now ... weird | 13:28 |
| sb0 | _franck__, if you are worried about the extra layer, feel free to work on direct migen-to-netlist output | 13:30 |
| sb0 | after all, verilog needs to die | 13:30 |
| _franck__ | I'm not worry, I just won't use it :) | 13:31 |
| _franck__ | I'm fine with VHDL | 13:31 |
| _franck__ | it's not perfect but who can claim he is ! | 13:32 |
| blueCmd | ysionneau: s/$$i/$i/ | 13:32 |
| sb0 | _franck__, if everyone adopted your shitty attitude towards programming languages, we'd still be writing assembler on a VAX | 13:33 |
| ysionneau | blueCmd: yes I just found that | 13:33 |
| ysionneau | thanks :) | 13:33 |
| blueCmd | _franck__: hah, yeah - VHDL and Verilog is at the same stage as COBOL | 13:34 |
| ysionneau | blueCmd: you can get some crap at the end of the file though | 13:34 |
| blueCmd | if the tools to make code -> bitstream were open source we could invent something better | 13:35 |
| blueCmd | ysionneau: that's fine | 13:35 |
| ysionneau | if the size is not a multiple of 16 bytes | 13:35 |
| ysionneau | I wonder why I never had this issue during my tests ... maybe I was using a different awk :o | 13:35 |
| _franck__ | sb0: don't get mad | 13:36 |
| stekern | sb0: I get your point, but being conservative usually keeps users happy (you can't argue that X86 hasn't been quite a success despite its ugliness) | 13:47 |
| stekern | you have to go towards neatness step-by-step, so they don't notice ;) | 13:48 |
| sb0 | there are more arm processors than x86 ones now :) | 13:48 |
| sb0 | and I think this isn't due entirely to marketing or other questionable concepts - x86 processors, due to their bloat, are quite power-hungry and not good for embedded/laptops | 13:50 |
| stekern | yeah, I know | 13:55 |
| stekern | and it's good, more software is less cpu agnostic and is forced to be made more generic | 13:56 |
| sb0 | stekern, for function calls that are in other modules, I see that the compiler emits l.jal + a relocation. what happens then the callee is too far to fit in the l.jal immediate? | 14:51 |
| sb0 | *the address of the callee | 14:51 |
| stekern | things break | 15:10 |
| stekern | iirc | 15:10 |
| stekern | do you have a memory layout where that happens? | 15:10 |
| stekern | or was it just a theoretical question? | 15:12 |
| sb0 | it's a theoretical question | 15:19 |
| stekern | (hopefully) it will break already at link time, but the alternatives aren't all that tempting | 15:22 |
| stekern | since you need a register to do the l.jalr, you can't really solve it at link time | 15:23 |
| sb0 | how do other platforms solve this problem? | 15:24 |
| stekern | so you'd need to waste an instruction at all call sites to global places | 15:24 |
| stekern | I think most handles it the same way | 15:24 |
| stekern | microblaze has that 'imm' instruction | 15:25 |
| stekern | with that you can handle stuff like that at link time | 15:25 |
| stekern | for dynamically linked code, it's not so much of a problem neither, since calls will anyway go through the plt | 15:27 |
| blueCmd | ysionneau: if you ever want to replace your hexdump version (which didn't work that well for me in the end since i have 32 bit widths), I wrote some python scripts: https://github.com/bluecmd/mexiko/tree/master/src/utils | 16:02 |
| blueCmd | stekern! why can I have my ram_wb (size: 0x200_0000) at 0x8000_0000 and access it fine, but if I have it at 0xee00_0000 I get bus error? | 16:26 |
| blueCmd | In my head the decoding should be OK, but maybe ram_wb has a bug | 16:27 |
| stekern | it's not ok for the way ram_wb decodes things | 16:29 |
| stekern | the size is applied as a mask to the start address | 16:29 |
| blueCmd | yeah, and that should be fine - no? | 16:30 |
| stekern | ah, yes... I misread one 0 | 16:31 |
| blueCmd | select would be at 7'b111011, and the rest 25 bits would be addr | 16:31 |
| stekern | yes, | 16:32 |
| stekern | have you checked the generated .v? | 16:32 |
| blueCmd | yes | 16:32 |
| blueCmd | 32'hee000000, ... 32'hfe000000 | 16:32 |
| blueCmd | for ADDR and MASK | 16:33 |
| stekern | that should be fine then... what else do you on the bus? | 16:34 |
| blueCmd | http://e2a25701fd55f34f.paste.se/ | 16:35 |
| stekern | we should make wb_intercon print an ascii-chart over the memory map | 16:41 |
| blueCmd | I don't have a printer though | 16:42 |
| blueCmd | and it would be a lot of papers wasted | 16:42 |
| blueCmd | ;) | 16:42 |
| stekern | you have to get a sauna, then you can use it to start it | 16:42 |
| blueCmd | Simulation ended at PC 00000200 = 00000000 | 16:43 |
| blueCmd | what causes Bus errors on mor1kx? | 16:43 |
| stekern | ibus wb_err or dbus wb_err | 16:43 |
| blueCmd | so since I don't even touch _err that must come from the mux | 16:44 |
| blueCmd | wbm_err, which is set if !match | 16:45 |
| blueCmd | sounds reasonable | 16:45 |
| stekern | yeah, should be easy to debug from a waveform | 16:46 |
| blueCmd | pff, waveforms | 16:46 |
| blueCmd | I only have a terminal! | 16:46 |
| stekern | you need to get yourself a printer | 16:47 |
| blueCmd | clearly | 16:47 |
| blueCmd | (wb_addr & MATCH_MASK[idx*aw+:aw]) == MATCH_ADDR[idx*aw+:aw] | 16:48 |
| blueCmd | aw = 32, so for idx = 1 (which is my case): | 16:49 |
| blueCmd | 0xee000000 & MATCH_MASK[32+:32] == MATCH_ADDR[32+:32] | 16:50 |
| blueCmd | what is 32+:32 I wonder | 16:50 |
| blueCmd | a_vect[ 0 +: 8] // == a_vect[ 7 : 0] says Internet | 16:51 |
| blueCmd | or in our case: b_vect[ 0 +: 8] // == b_vect[0 : 7] I guess | 16:51 |
| blueCmd | it seems correct to me | 16:55 |
| ysionneau | blueCmd: ah great! thanks :) yes maybe mine only worked for 8 bits :x | 17:06 |
| blueCmd | f0000360, Slave select: 16 - ee000000 | 17:12 |
| blueCmd | 16 is not correct | 17:12 |
| blueCmd | or maybe it is hm | 17:14 |
| blueCmd | yes it is the ram that sets wb_s2m_bpi0_err - I was wrong before | 17:19 |
| blueCmd | must be blind | 17:19 |
| blueCmd | actually it says: " skip top nibble of address in case" | 17:25 |
| blueCmd | not "use only what we need" : | 17:25 |
| blueCmd | olofk: ! :P | 17:25 |
| blueCmd | olofk: stekern: https://github.com/openrisc/orpsoc-cores/pull/71 | 17:36 |
| stekern | ram_wb btw, aren't you using olofk's ram module? | 17:36 |
| blueCmd | I thought that was his model? | 17:36 |
| blueCmd | module* | 17:36 |
| stekern | I'm building fences, right now, will take a look later | 17:36 |
| stekern | -, | 17:36 |
| blueCmd | *augh* no, his is wb_ram | 17:36 |
| blueCmd | I actually was 'No, I'm going to use olofk's ram, not wb_ram' | 17:37 |
| blueCmd | then everything is forgiven | 17:38 |
| blueCmd | hm, wb_ram doesn't work for me - weird. doesn't seem to hold the data I write to it | 17:59 |
| stekern | forgiven? not so much? ;) | 18:47 |
| stekern | blueCmd: wb_ram is a write-only RAM | 19:29 |
| blueCmd | stekern: ohh.. | 19:44 |
| blueCmd | that doesn't make any sense | 19:44 |
| blueCmd | so I hope you're joking :P | 19:45 |
| stekern | of course I am =) | 19:47 |
| blueCmd | good! | 19:47 |
| * blueCmd is writing a wb_bpi for Xilinx high-speed configuration flash | 19:48 | |
| stekern | since sb0 started the big or1k quirks complaining bonanza, I'll add some gazoline to the fire: | 20:25 |
| stekern | why is the mnemonic for l.sw/l.sb/l.sh backwards? | 20:26 |
| stekern | I curse at that every time I write or1k asm | 20:28 |
| stekern | dalias: https://github.com/skristiansson/musl-or1k/commit/585a54189b34c8370ba231b05ec8412519c80249 | 20:42 |
| blueCmd | stekern: is it? | 21:01 |
| blueCmd | l.sb dest, src | 21:01 |
| stekern | it might seem right, but in my head it's backwards ;) | 21:14 |
| stekern | my subconsiousness always want to treat the loads and stores instructions the same | 21:17 |
| stekern | + that's the way around most other archs do it | 21:17 |
| blueCmd | not many hours left on my patience of using Vivado. I have already prepared to transition to Tcl instead of their monsterous project files | 21:44 |
| sb0 | yeah, don't use the ui | 21:59 |
| blueCmd | soo much better to tcl it :) | 22:22 |
| blueCmd | cannot believe I didn't do that from the start | 22:22 |
| stekern | hmm... odd, seems like our wchar_t end up as unsigned in the linux toolchain but signed in the elf toolchain | 22:48 |
| --- Log closed Sat Jul 05 00:00:05 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!