IRC logs for #openrisc Friday, 2014-07-04

--- Log opened Fri Jul 04 00:00:03 2014
sb0stekern, so the exception vectors are very large (256 bytes), but still can't fit the _exception_handler that saves all registers? meh!08:07
stekernyes, it's just silly how the vectors are defined in or1k08:08
stekernit should just be 8bytes per vector08:08
sb0so we use 32/256 bytes, and then add some jumps that slow things up a bit more and waste a bit of memory08:08
stekernjumps are 1-cycle instructions on mor1kx though08:10
sb0also, we can get rid of most of the context save/restore for system calls, I guess?08:11
stekernsystem calls where?08:12
stekernI mean, what implementation of the system calls are you looking at?08:12
sb0the bare-metal crt08:13
sb0well I guess you just used the 'standard' exception handling code for the system call exception08:13
stekernah, yes...08:13
stekernyou can optmize that code *a lot*, I just threw together something that would work08:14
stekernsb0: 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
stekernShould you need helps with IT issues, please contact IBM Helpdesk, tel 41111, email #IBMHDFi08:16
stekernI fat-fingered the copy-paste :/08:16
sb0ah, great. thanks a lot!08:16
blueCmdsb0: you now know the purpose of the IT Center mailbox though10:52
blueCmdand who to contact if you have IT issues10:52
blueCmdolofk: how do I format my .bin file to readmemh format?12:22
sb0blueCmd, you should try migen. Memory(size, width, ..., init=python list with the init data)12:28
sb0and converting a bin file to list in python is trivial12:29
blueCmdsb0: 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 that12:34
stekernotoh, converting a bin to readmemh in python is also trivial12:34
stekernyou can use srecord too12:34
ysionneauhum isn't there some objcopy verilog backend?12:35
stekernobjcopy can output as well, but there was some problem that it only did byte arrays iirc12:35
blueCmdhave you thought about using a template engine or something?12:36
sb0blueCmd, what orpsoc-cores features do you need?12:37
sb0blueCmd, no, but that's something that could be explored12:37
ysionneauI used some makefile like that to generate the .vh file12:37
ysionneauthe .vh is then read using $readmemh()12:39
blueCmdsb0: I need uart, i2c, spi, ram_wb cores12:41
blueCmdysionneau: cool! thanks12:41
sb0misoc has uart and wishbone ram12:42
sb0also, if that wishbone ram is for the bootloader (bios), you just have to use the IntegratedBIOS class and the bios gets built and loaded properly12:44
sb0for both lm32 and or1k12:44
stekernsb0: reminds me, it would be fun to merge the Linux drivers for the misoc/milkymist into an openrisc tree12:45
stekernfor what cores do you have drivers?12:45
sb0there are no linux drivers for misoc atm... there are some for the legacy soc, which could be used as a base12:45
sb0since the misoc cores aren't very different12:46
stekernwas there any for the minimac?12:46
sb0blueCmd, here are some example cores:
sb0should be easy to write spi/i2c ones *g*12:47
sb0stekern, not sure, and minimac is being overhauled atm12:47
sb0so I'd wait a bit before writing a driver for it12:47
stekernI think some guy had an unpublished driver for the old minimac12:48
stekernhe added it to orpsoc-cores12:48
sb0would be fun to have uart still12:48
sb0and you can use ppp :)12:48
ysionneauthat is so much easier to read in python12:48
stekernisn't there a driver for the uart? or is that different in misoc?12:49
sb0it's different in misoc, but similar12:49
sb0should be just a few lines to change in the old driver12:50
sb0you need a timer driver too12:51
stekernysionneau: to my untrained migen eye, I think it'd be easier to read in verilog ;)12:51
sb0stekern, you have much more boilerplate though12:51
stekernthat doesn't make it so though12:51
sb0here's another core:
sb0(and how to put it into a soc)12:51
stekernI had the same feeling the first times I looked at verilog vs VHDL12:52
ysionneaustekern: for the timer example?12:54
stekernsb0: well, if I'm planning on using or1k, I've got the builtin timer  that I can use in the meantime12:55
stekernthe timer code in Linux (can be) pretty botched into the arch specific code too12:55
sb0yeah, so easy, we should do the same for uart, framebuffer and disk io12:56
stekernyup, no need to set-up io mappings ;)12:56
blueCmdsb0: 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 bill12:57
stekernno, I agree, for my SMP stuff, it's just annoying that we have that builtin timer deeply assumed in the arch code12:57
blueCmdsb0: well, the UART you linked wors for very simple things, but I need it to be wishbone12:58
stekernysionneau: for both12:58
sb0blueCmd, why?12:58
sb0note that this design is bus-independent12:58
ysionneaustekern: maybe I'm already used to migen, but I only attended one workshop and wrote very few lines of it :)12:58
sb0there's later another "core" that collects all the CSRs and builds the bus-dependent interface12:59
stekernysionneau: even a few lines is eternally more than I have done ;)12:59
stekernysionneau: but a timer in verilog isn't very complex neither:
ysionneauyes sure13:00
stekernadmittedly, that's more simple than the migen example though13:01
blueCmdsb0: how would my software write to the UART?13:01
sb0stekern, in migen that would be: = CSRStorage(32); self.sync +=
sb0still less than the verilog :p13:02
sb0CSRStorage -> CSRStatus13:03
stekernif I want to use the wb lib?13:03
ysionneaublueCmd: CSRs end up memory mapped, so you can just access the CSR registers via their memory address13:04
sb0stekern, csrgen.Bank (which is used in the base SoC classes) builds the actual bus interface, and connects the CSR member signals13:05
stekernbut if I want to use wb without the CSR?13:06
stekernor is there always a wb<->csr converter generated?13:06
sb0you can (write and) use another csrgen.Bank that generates wb directly13:07
stekernI'm thinking, if I want to make my core also usable outside a migen generated soc?13:07
sb0the internal csr bus is entirely optional13:07
sb0you can also use the csr bus in verilog, like the old soc does13:08
ysionneaufor 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
sb0it's just wishbone without ack and other signals that are useless for csrs...13:08
stekernyes, but my point would be to "make a standalone core with wb interface"13:08
sb0yeah, you can do that too13:08
stekernbut I'll take a look myself and I bet I get my questions answered ;)13:09
sb0just pass the wishbone ios to verilog.convert()13:09
sb0actually, you could write a script that takes any misoc core that has csrs and exports it to verilog with a wishbone if13:09
sb0that's not hard13:10
stekernok, cool13:10
sb0that being said, verilog sucks ass13:10
stekernsure, but it's widely used.13:11
stekernI mean, you can't expect people to go changing existing codebases to migen just to use one single core13:13
stekern(and obviously that's not the case, I'm just motivating my question)13:14
blueCmdysionneau: I see. CSR is another bus then I guess?13:15
sb0phew. such conservatism is responsible for a lot of technological mishaps. look at x86, thunderbolt, hdmi, cobol, and or1k NMI and exception vectors ;)13:17
ysionneaublueCmd: yep CSR is a bus for low throughput things like configuration registers for other cores, and it's connected to Wishbone by a bridge13:17
sb0but well, yeah13:18
blueCmdsb0: I'm pretty excited about the prospect of having my design written in python instead of bulky verilog13:18
sb0ooh, and FPGA "designs" committed with matlab/edk/labview. I cannot count how many labs have them, and are deeply unhappy with that.13:20
blueCmdysionneau: your 'objdump' line didn't work that well for me :(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 bugs13:23
blueCmd_franck__: what? I always fear that :P13:23
ysionneaublueCmd: what's in your paste?13:23
sb0_franck_, obviously, you haven't tracked down ISE and Migen bugs yet ;)13:23
blueCmdysionneau: output of hexdump -Cv bpi.bin | awk 'BEGIN { FS=" " } ; { for (i = 2 ; i < 18 ; i++) { printf "%s ",$$i } ; print " " }' > bin.hex13:23
sb0migen 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
sb0I've never spent more than a couple hours on a migen bug. ISE bugs, however, cost me weeks or months sometimes.13:25
sb0plus all the xilinx bureaucracy that needs to grind in order to get them fixed13:26
sb0and the interesting tools you need at times, like freeze sprays when the timing analyzer is a bit off13:27
sb0and yes, that happens. really, migen bugs are very tame in comparison.13:28
ysionneaublueCmd: I have the same issue here now ... weird13:28
sb0_franck__, if you are worried about the extra layer, feel free to work on direct migen-to-netlist output13:30
sb0after all, verilog needs to die13:30
_franck__I'm not worry, I just won't use it :)13:31
_franck__I'm fine with VHDL13:31
_franck__it's not perfect but who can claim he is !13:32
blueCmdysionneau: s/$$i/$i/13:32
sb0_franck__, if everyone adopted your shitty attitude towards programming languages, we'd still be writing assembler on a VAX13:33
ysionneaublueCmd: yes I just found that13:33
ysionneauthanks :)13:33
blueCmd_franck__: hah, yeah - VHDL and Verilog is at the same stage as COBOL13:34
ysionneaublueCmd: you can get some crap at the end of the file though13:34
blueCmdif the tools to make code -> bitstream were open source we could invent something better13:35
blueCmdysionneau: that's fine13:35
ysionneauif the size is not a multiple of 16 bytes13:35
ysionneauI wonder why I never had this issue during my tests ... maybe I was using a different awk :o13:35
_franck__sb0: don't get mad13:36
stekernsb0: 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
stekernyou have to go towards neatness step-by-step, so they don't notice ;)13:48
sb0there are more arm processors than x86 ones now :)13:48
sb0and 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/laptops13:50
stekernyeah, I know13:55
stekernand it's good, more software is less cpu agnostic and is forced to be made more generic13:56
sb0stekern, 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 callee14:51
stekernthings break15:10
stekerndo you have a memory layout where that happens?15:10
stekernor was it just a theoretical question?15:12
sb0it's a theoretical question15:19
stekern(hopefully) it will break already at link time, but the alternatives aren't all that tempting15:22
stekernsince you need a register to do the l.jalr, you can't really solve it at link time15:23
sb0how do other platforms solve this problem?15:24
stekernso you'd need to waste an instruction at all call sites to global places15:24
stekernI think most handles it the same way15:24
stekernmicroblaze has that 'imm' instruction15:25
stekernwith that you can handle stuff like that at link time15:25
stekernfor dynamically linked code, it's not so much of a problem neither, since calls will anyway go through the plt15:27
blueCmdysionneau: 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:
blueCmdstekern! 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
blueCmdIn my head the decoding should be OK, but maybe ram_wb has a bug16:27
stekernit's not ok for the way ram_wb decodes things16:29
stekernthe size is applied as a mask to the start address16:29
blueCmdyeah, and that should be fine - no?16:30
stekernah, yes... I misread one 016:31
blueCmdselect would be at 7'b111011, and the rest 25 bits would be addr16:31
stekernhave you checked the generated .v?16:32
blueCmd32'hee000000, ... 32'hfe00000016:32
blueCmdfor ADDR and MASK16:33
stekernthat should be fine then... what else do you on the bus?16:34
stekernwe should make wb_intercon print an ascii-chart over the memory map16:41
blueCmdI don't have a printer though16:42
blueCmdand it would be a lot of papers wasted16:42
stekernyou have to get a sauna, then you can use it to start it16:42
blueCmdSimulation ended at PC 00000200 = 0000000016:43
blueCmdwhat causes Bus errors on mor1kx?16:43
stekernibus wb_err or dbus wb_err16:43
blueCmdso since I don't even touch _err that must come from the mux16:44
blueCmdwbm_err, which is set if !match16:45
blueCmdsounds reasonable16:45
stekernyeah, should be easy to debug from a waveform16:46
blueCmdpff, waveforms16:46
blueCmdI only have a terminal!16:46
stekernyou need to get yourself a printer16:47
blueCmd(wb_addr & MATCH_MASK[idx*aw+:aw]) == MATCH_ADDR[idx*aw+:aw]16:48
blueCmdaw = 32, so for idx = 1 (which is my case):16:49
blueCmd0xee000000 & MATCH_MASK[32+:32] == MATCH_ADDR[32+:32]16:50
blueCmdwhat is 32+:32 I wonder16:50
blueCmda_vect[ 0 +: 8] // == a_vect[ 7 : 0] says Internet16:51
blueCmdor in our case: b_vect[ 0 +: 8] // == b_vect[0 : 7] I guess16:51
blueCmdit seems correct to me16:55
ysionneaublueCmd: ah great! thanks :) yes maybe mine only worked for 8 bits :x17:06
blueCmdf0000360, Slave select: 16 - ee00000017:12
blueCmd16 is not correct17:12
blueCmdor maybe it is hm17:14
blueCmdyes it is the ram that sets wb_s2m_bpi0_err - I was wrong before17:19
blueCmdmust be blind17:19
blueCmdactually it says: " skip top nibble of address in case"17:25
blueCmdnot "use only what we need" :17:25
blueCmdolofk: ! :P17:25
blueCmdolofk: stekern:
stekernram_wb btw, aren't you using olofk's ram module?17:36
blueCmdI thought that was his model?17:36
stekernI'm building fences, right now, will take a look later17:36
blueCmd*augh* no, his is wb_ram17:36
blueCmdI actually was 'No, I'm going to use olofk's ram, not wb_ram'17:37
blueCmdthen everything is forgiven17:38
blueCmdhm, wb_ram doesn't work for me - weird. doesn't seem to hold the data I write to it17:59
stekernforgiven? not so much? ;)18:47
stekernblueCmd: wb_ram is a write-only RAM19:29
blueCmdstekern: ohh..19:44
blueCmdthat doesn't make any sense19:44
blueCmdso I hope you're joking :P19:45
stekernof course I am =)19:47
* blueCmd is writing a wb_bpi for Xilinx high-speed configuration flash19:48
stekernsince sb0 started the big or1k quirks complaining bonanza, I'll add some gazoline to the fire:20:25
stekernwhy is the mnemonic for l.sw/ backwards?20:26
stekernI curse at that every time I write or1k asm20:28
blueCmdstekern: is it?21:01 dest, src21:01
stekernit might seem right, but in my head it's backwards ;)21:14
stekernmy subconsiousness always want to treat the loads and stores instructions the same21:17
stekern+ that's the way around most other archs do it21:17
blueCmdnot many hours left on my patience of using Vivado. I have already prepared to transition to Tcl instead of their monsterous project files21:44
sb0yeah, don't use the ui21:59
blueCmdsoo much better to tcl it :)22:22
blueCmdcannot believe I didn't do that from the start22:22
stekernhmm... odd, seems like our wchar_t end up as unsigned in the linux toolchain but signed in the elf toolchain22:48
--- Log closed Sat Jul 05 00:00:05 2014

Generated by 2.15.2 by Marius Gedminas - find it at!