IRC logs for #openrisc Wednesday, 2014-03-12

--- Log opened Wed Mar 12 00:00:17 2014
olofkShould we get the little-endian version of the tools upstream as well? Haven't really figured out which state they are in07:03
stekernme neither07:16
stekernthere's those 4.5.1 patches floating around from that forum guy07:16
olofk...which might be a good reason to wait a bit :)07:16
olofkYes, I was reminded about those when I saw another forum post today07:16
stekernpersonally, I'm completely uninterested in little endian versions of or1k07:17
olofkI've seen people ask for it on a few occasions. My guess is that they want to use it with a LE bus such as AXI07:18
stekernimo, it would have been better if the architecture wouldn't have left that open and just state it's be07:18
olofkYeah, openness is nice, but there's just too many stupid things you can change in or1k07:19
stekernthere's no big problems involved with using a BE cpu one a "LE bus"07:20
olofkThey don't fint?07:20
olofkI just wondered if the one problem was that you get bytes in the wrong order :)07:21
stekernyou mean, the endian si too big?07:21
stekerncan't fit it in the smaller endian07:21
stekernhow hard is it to swap byte order in rtl, if that's an issue?07:22
olofkPerhaps you can take two little endians and plug into one big endian, assuming that they are roughly double the size07:22
stekernone reason is if you have crappy code that assumes LE and you want to swap to a BE cpu07:23
olofkstekern: We had that problem at work where we wanted to change endianness on a stupid crappy proprietary soft CPU. We ended up keeping the endianness07:24
olofkThere was just too much code to analyze for subtle breakages07:25
stekerncrappy code ;)07:38
stekernas I said07:38
stekernbut it's the only valid reason to want to have a LE version07:39
_franck_olofk_: did you see my message in the backlog ?12:00
olofk_franck_: Not sure. Do you mean the one about ghdl?15:58
olofkOh. I missed that one. Must have been a netsplit or something16:10
olofkYes, I think we can move most of them there as long as the file doesn't get too big. Taking care of the simulators was a first step16:11
olofkI actually wanted to have each $SIMULATORSection in Â$, but weird stuff started to happen with the dependencies then, and I didn't want to figure out what went wrong16:12
olofkAlso, I want to deprecated the verilog section16:13
_franck_web_where would you put verilog files then ?16:16
olofkMy idea was to have something like an option called verilog.src_files and put common RTL code in the [main] section and tool-specific files in each simulator's section16:18
olofkBut after I wrote that, I'm not sure anymore16:18
olofkThe problem I'm trying to solve is when you have simulator-specific HDL code that can be both verilg and VHDL16:20
_franck_web_yes, I think we need verilog *and* vhdl sections16:21
olofkYeah, I'm starting to lean toward that also16:39
olofkIf we need some simulator-specific workarounds, that can be solved with `ifdef in the code.16:40
olofkI think I'm too tired to explain properly, but to sum it up, yes, we should have both verilog and vhdl sections, and they should each have options for synthesizable code and testbench code16:44
blueCmdolofk: I've got my DE0 nano board now. prepare yourself for a lot of pull requests when I unleash myself upon ye code17:35
stekernArr, ye pull requests gunna be welcome!17:56
stekern_franck_: can I openocd to an adv debugsys that isn't connected to a cpu?17:58
stekernI just want to access the wishbone over jtag17:59
_franck_stekern: yes you can, like here:
blueCmdstekern: did you see Nick's response on binutils?18:01
stekernblueCmd: umm, no, was I cc'ed?18:01
blueCmdstekern: nah, but it was sent to the lists18:02
stekern_franck_: ah, I have to tie ack to 1 and present zero data and then it will just work(tm)18:02
blueCmd"Well this is a nice surprise.  The patches apply cleanly, build and test without problems and do not impact on any other target.  Thank you very much for putting so much effort into creating the patches.18:02
blueCmd"- as soon as those copyright assignments are in place I will be happy to accept the port into the sources."18:02
blueCmdI requested a clarification on the copyright things18:03
_franck_stekern: I can't remember if it needs to hack the openocd cfg a little bit18:03
stekern_franck_: ok, I get back to you on that when/if I run into problems then ;)18:04
olofkblueCmd: That was shockingly little resistance19:23
blueCmdolofk: it's not merged yet, but yes19:24
olofkAlmost sounds like all the other arch maintainers are sloppy and lazy bastards :)19:24
olofkThe linux port got a lot of praise as well IIRC. My guess is that the OpenRISC community consists of extremely talented and a bit anal hackers :)19:25
_franck_what could be the cause of a non returning call to schedule) in a Kernel device driver ?19:37
blueCmdstekern: so I got my de0 nano, changed the portmap file for my uart, synthed it and loaded the sof file, connected openocd, did "spotify:track:0eh7RUFI8EGuoWcM04xDRr20:45
blueCmddid "halt; load_image ...; reset" where ... is the vmlinux from
blueCmdI think my USB UART <-> TTL thing _might_ be 5V, but I want to make sure that I'm not missing anything before assuming it's the failing part20:46
blueCmdolofk: stekern: apparently there is a feedback process in the thing20:52
blueCmdstekern: switched rx/tx on uart and it booots! :D20:53
olofkblueCmd: Awesome! You're on a roll today :)20:55
blueCmdolofk: might be my uart, but I find that loading the image with openocd, terminating openocd and sending the sof file again boots (and outputs) linux21:04
blueCmdif I don't do the last sof programming nothing is shown from the serial port21:04
_franck_the reset from openocd is not clean, need to be checked/fixed21:05
olofkblueCmd: You're holding it wrong21:05
blueCmdolofk: hah21:05
-!- LoneTech_ is now known as LoneTech21:15
blueCmdso. are we trying to merge the mailinglists?21:36
joaocfernandes_franck_, are you franck jullien  ?21:57
_franck_I am21:57
joaocfernandesgreat, do you mind if i ask you some simple questions? i have been writing some small additions for verilator.py21:58
joaocfernandesthanks, on def _verilate , for the --LDFLAGS argument, we have now the self.libs where will the libs be provided? on the .core file?22:02
_franck_yes, in the .core file22:03
_franck_wait I have an exmaple22:03
_franck_elf-loader.core will have a section like this:22:04
_franck_src_files = or1k-elf-loader.c22:04
_franck_include_files = or1k-elf-loader.h22:04
_franck_libs = -lelf22:04
joaocfernandesok now i get the idea, so but the elf-loader core will be compiled through ?22:06
_franck_yes. But for now [verilator] section in cores (others than the system core) is not taken into account22:07
_franck_but after that elf-loader.c will be automaticly added to verilator.src_files and compiled22:08
_franck_the patch for this is on its way22:08
joaocfernandesok, thank you very much franck22:12
_franck_you're welcome22:12
_franck_that will be something like this:
blueCmdolofk: stekern: woo, running glibc zsh on hardware! it's much much muuuch faster than in a simulator22:49
blueCmdi'm totally going to add support for embedding firmware in the EPCS64 jic file23:45
blueCmdto fusesoc23:45
--- Log closed Thu Mar 13 00:00:18 2014

Generated by 2.15.2 by Marius Gedminas - find it at!