| --- Log opened Wed Mar 12 00:00:17 2014 | ||
| olofk | Should we get the little-endian version of the tools upstream as well? Haven't really figured out which state they are in | 07:03 |
|---|---|---|
| stekern | me neither | 07:16 |
| stekern | there's those 4.5.1 patches floating around from that forum guy | 07:16 |
| olofk | ...which might be a good reason to wait a bit :) | 07:16 |
| olofk | Yes, I was reminded about those when I saw another forum post today | 07:16 |
| stekern | personally, I'm completely uninterested in little endian versions of or1k | 07:17 |
| olofk | I'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 AXI | 07:18 |
| stekern | imo, it would have been better if the architecture wouldn't have left that open and just state it's be | 07:18 |
| olofk | Yeah, openness is nice, but there's just too many stupid things you can change in or1k | 07:19 |
| stekern | there's no big problems involved with using a BE cpu one a "LE bus" | 07:20 |
| stekern | s/one/on | 07:20 |
| olofk | They don't fint? | 07:20 |
| olofk | s/fint/fit | 07:21 |
| stekern | ? | 07:21 |
| olofk | I just wondered if the one problem was that you get bytes in the wrong order :) | 07:21 |
| stekern | you mean, the endian si too big? | 07:21 |
| stekern | s/si/is | 07:21 |
| stekern | can't fit it in the smaller endian | 07:21 |
| olofk | :) | 07:21 |
| stekern | how hard is it to swap byte order in rtl, if that's an issue? | 07:22 |
| olofk | Perhaps you can take two little endians and plug into one big endian, assuming that they are roughly double the size | 07:22 |
| stekern | one reason is if you have crappy code that assumes LE and you want to swap to a BE cpu | 07:23 |
| olofk | stekern: We had that problem at work where we wanted to change endianness on a stupid crappy proprietary soft CPU. We ended up keeping the endianness | 07:24 |
| olofk | There was just too much code to analyze for subtle breakages | 07:25 |
| stekern | crappy code ;) | 07:38 |
| stekern | as I said | 07:38 |
| stekern | but it's the only valid reason to want to have a LE version | 07: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 |
| _franck_web_ | http://juliusbaxter.net/openrisc-irc/%23openrisc.2014-03-11.log.html | 16:09 |
| olofk | Oh. I missed that one. Must have been a netsplit or something | 16:10 |
| olofk | Yes, 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 step | 16:11 |
| olofk | I actually wanted to have each $SIMULATORSection in Â$SIMULATOR.py, but weird stuff started to happen with the dependencies then, and I didn't want to figure out what went wrong | 16:12 |
| olofk | Also, I want to deprecated the verilog section | 16:13 |
| _franck_web_ | where would you put verilog files then ? | 16:16 |
| olofk | My 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 section | 16:18 |
| olofk | But after I wrote that, I'm not sure anymore | 16:18 |
| olofk | The problem I'm trying to solve is when you have simulator-specific HDL code that can be both verilg and VHDL | 16:20 |
| _franck_web_ | yes, I think we need verilog *and* vhdl sections | 16:21 |
| olofk | Yeah, I'm starting to lean toward that also | 16:39 |
| olofk | If we need some simulator-specific workarounds, that can be solved with `ifdef in the code. | 16:40 |
| olofk | I 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 code | 16:44 |
| blueCmd | olofk: I've got my DE0 nano board now. prepare yourself for a lot of pull requests when I unleash myself upon ye code | 17:35 |
| stekern | Arr, 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 |
| stekern | I just want to access the wishbone over jtag | 17:59 |
| _franck_ | stekern: yes you can, like here: https://github.com/fjullien/jtag_vpi/blob/master/bench/jtag_vpi_tb.v | 18:00 |
| blueCmd | stekern: did you see Nick's response on binutils? | 18:01 |
| stekern | blueCmd: umm, no, was I cc'ed? | 18:01 |
| blueCmd | stekern: nah, but it was sent to the lists | 18:02 |
| stekern | _franck_: ah, I have to tie ack to 1 and present zero data and then it will just work(tm) | 18:02 |
| stekern | ? | 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 |
| stekern | nice! | 18:03 |
| blueCmd | I requested a clarification on the copyright things | 18:03 |
| _franck_ | stekern: I can't remember if it needs to hack the openocd cfg a little bit | 18:03 |
| stekern | _franck_: ok, I get back to you on that when/if I run into problems then ;) | 18:04 |
| olofk | blueCmd: That was shockingly little resistance | 19:23 |
| blueCmd | olofk: it's not merged yet, but yes | 19:24 |
| olofk | Almost sounds like all the other arch maintainers are sloppy and lazy bastards :) | 19:24 |
| olofk | The 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 |
| blueCmd | stekern: 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:0eh7RUFI8EGuoWcM04xDRr | 20:45 |
| blueCmd | blah | 20:45 |
| blueCmd | did "halt; load_image ...; reset" where ... is the vmlinux from http://opencores.org/or1k/ORCONF2013_Workshop_ORPSoC_On_DE0_Nano | 20:45 |
| blueCmd | I 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 part | 20:46 |
| blueCmd | olofk: stekern: https://www.fsf.org/licensing/assigning.html apparently there is a feedback process in the assign@gnu.org thing | 20:52 |
| blueCmd | stekern: switched rx/tx on uart and it booots! :D | 20:53 |
| olofk | blueCmd: Awesome! You're on a roll today :) | 20:55 |
| blueCmd | :D | 20:56 |
| blueCmd | olofk: might be my uart, but I find that loading the image with openocd, terminating openocd and sending the sof file again boots (and outputs) linux | 21:04 |
| blueCmd | if I don't do the last sof programming nothing is shown from the serial port | 21:04 |
| _franck_ | the reset from openocd is not clean, need to be checked/fixed | 21:05 |
| blueCmd | ah | 21:05 |
| olofk | blueCmd: You're holding it wrong | 21:05 |
| blueCmd | olofk: hah | 21:05 |
| -!- LoneTech_ is now known as LoneTech | 21:15 | |
| blueCmd | so. are we trying to merge the mailinglists? | 21:36 |
| joaocfernandes | hi | 21:55 |
| _franck_ | hi | 21:56 |
| joaocfernandes | _franck_, are you franck jullien ? | 21:57 |
| _franck_ | I am | 21:57 |
| joaocfernandes | great, do you mind if i ask you some simple questions? i have been writing some small additions for verilator.py | 21:58 |
| _franck_ | ok | 21:59 |
| joaocfernandes | thanks, 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 file | 22:03 |
| _franck_ | wait I have an exmaple | 22:03 |
| _franck_ | elf-loader.core will have a section like this: | 22:04 |
| _franck_ | [verilator] | 22:04 |
| _franck_ | src_files = or1k-elf-loader.c | 22:04 |
| _franck_ | include_files = or1k-elf-loader.h | 22:04 |
| _franck_ | libs = -lelf | 22:04 |
| joaocfernandes | ok now i get the idea, so but the elf-loader core will be compiled through verilator.py ? | 22:06 |
| _franck_ | yes. But for now [verilator] section in cores (others than the system core) is not taken into account | 22:07 |
| _franck_ | but after that elf-loader.c will be automaticly added to verilator.src_files and compiled | 22:08 |
| _franck_ | the patch for this is on its way | 22:08 |
| joaocfernandes | ok, thank you very much franck | 22:12 |
| _franck_ | you're welcome | 22:12 |
| _franck_ | that will be something like this: http://pastie.org/private/pimcxrrdpid8lenbf3ovja | 22:12 |
| blueCmd | olofk: stekern: woo, running glibc zsh on hardware! it's much much muuuch faster than in a simulator | 22:49 |
| blueCmd | i'm totally going to add support for embedding firmware in the EPCS64 jic file | 23:45 |
| blueCmd | to fusesoc | 23:45 |
| --- Log closed Thu Mar 13 00:00:18 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!