| andresjk | blueCmd, was that. thanks | 00:18 |
|---|---|---|
| andresjk | Right now, Im trying to write a simple driver to control a peripheral from linux. Im taking the UART16550 as the model or skeleton and I have instantiated another UART16550. Named UART16550_1. The RTL is done but Im pretty lost at how to access it within linux. | 00:25 |
| andresjk | I have tried to analyze the uart-echo.c and the uart driver that are in sw inside the orpsoc project | 00:27 |
| andresjk | any advices? | 00:27 |
| _franck_ | you need to write a device driver | 00:29 |
| _franck_ | or you can use mmap | 00:29 |
| _franck_ | http://www.armadeus.com/wiki/index.php?title=FPGA_register | 00:29 |
| andresjk | nice tutorial. thanks! | 00:30 |
| andresjk | _franck_, so you don't recommend to use the uart drives that are in the orpsocv2 project as a base point? | 00:32 |
| _franck_ | is there a linux uart driver ? I'm using this uart and it works with the linux 8250 driver | 00:34 |
| _franck_ | I don't know what you want to do with your custom RTL component but I guess you'll need a simple char driver | 00:35 |
| andresjk | yeah thats the first step. then I would use dma | 00:38 |
| andresjk | in the uart driver from orpsoc they use REG8 function | 00:39 |
| andresjk | I believe REG8/16/32 are another way to write | 00:43 |
| _franck_ | REG8 is just *((volatile unsigned char *)(add)) | 00:44 |
| _franck_ | like readb in the kernel | 00:45 |
| andresjk | oh ok | 00:46 |
| _franck_ | uart.c in sw/drivers is not a driver you can use in linux | 00:47 |
| _franck_ | it is more like a library with functions used in non linux context | 00:48 |
| andresjk | kinda like newlib? | 00:48 |
| _franck_ | yes | 00:48 |
| _franck_ | do you need to run linux ? if yes, you need a linux driver | 00:49 |
| andresjk | the one that uses linux is 8250.c, right? | 00:49 |
| _franck_ | or, at first use mmap | 00:49 |
| _franck_ | yes the linux driver for the 16550 is 8250.c | 00:49 |
| _franck_ | but don't waist your time trying to understand how this driver works, this is not what you want | 00:50 |
| andresjk | yeah, well my advisor told me to understand and use the uart as an skeleton for my custom RTL peripheral. So later I can just code the logic in verilog and have the driver to right into the internal registers of the peripheral | 00:54 |
| andresjk | you say that using mmap its easier? | 00:55 |
| _franck_ | you can use mmap to access your RTL from the user's mode. As for the RTL, you can start from the uart but I'm not sure it's the best thing. Why don't you start with a GPIO ? | 00:58 |
| _franck_ | https://github.com/Franck79/orpsocv2/blob/master/boards/altera/de1/rtl/verilog/gpio/gpio.v | 00:58 |
| andresjk | yeah, I guess I much easier. One 3 register. 2 for writing and one for reading. | 01:03 |
| andresjk | i think I will to that | 01:03 |
| andresjk | do basically each internal register has a address mapped in memory right? | 01:04 |
| _franck_ | yes | 01:04 |
| andresjk | Well, I will start writing my first user-space driver. Thanks a lot. I really really appreciate your help. you took away many of my doubts :) | 01:09 |
| _franck_ | you're welcome | 01:10 |
| _franck_ | bed time now | 01:10 |
| _franck_ | bye | 01:10 |
| jonibo | poke53281: the bugtracker is useless for Linux bugs... nobody checks it... report bugs to linux@lists.openrisc.net | 11:24 |
| jonibo | the bug tracker can be shut down for Linux, AFAIC | 11:25 |
| blueCmd | jonibo: I have two kernel patches, one for TLS and one to implement new atomic functions I need | 11:26 |
| blueCmd | jonibo: what should I do with them and how should they be packaged? | 11:26 |
| jonibo | mailing list | 11:27 |
| jonibo | use git send-email, preferably | 11:28 |
| jonibo | linux@lists.openrisc.net is the preferred list | 11:28 |
| blueCmd | not sure how to use that with gmail | 11:29 |
| jonibo | there's a good howto for that somewhere on the 'net | 11:30 |
| blueCmd | hah found it | 11:30 |
| jonibo | good | 11:30 |
| blueCmd | jonibo: do you want a changelog entry somewhere? | 11:31 |
| jonibo | no, no... just patches, please | 11:31 |
| jonibo | no changelogs | 11:31 |
| jonibo | that's what git's for | 11:31 |
| blueCmd | good | 11:32 |
| blueCmd | jonibo: first patch submitted, the other one will follow when I cleaned it up a bit | 11:39 |
| jonibo | ok | 11:40 |
| jonibo | will take a look when I get a spare moment | 11:40 |
| blueCmd | jonibo: no hurry | 11:41 |
| blueCmd | jonibo: if you have time I would love to have some input on this part: http://08f5a38754babbd2.paste.se/ | 11:41 |
| blueCmd | if you think it's worth doing some sort of call table or something, and if it is - where I would place it | 11:41 |
| jonibo | yeah, I figured that was what you were up to... can you send that as a patch to the mailing list, too, and we can discuss it via that forum? | 11:42 |
| blueCmd | sure | 11:42 |
| jonibo | can you really use l.sfeqi in the delay slot of a l.bf instruction? looks suspicious... | 11:44 |
| blueCmd | yep, we talked about that before | 11:46 |
| blueCmd | a couple of weeks ago | 11:46 |
| blueCmd | bf will use the flag set on entry | 11:46 |
| jonibo | ok, cool... that's good to know | 11:47 |
| jonibo | the kernel assembly notation is to prefix delay slot instructions by one space... for readability | 11:47 |
| jonibo | just for info | 11:48 |
| blueCmd | jonibo: yeah, I do that on the other places - I can add it there as well | 11:49 |
| blueCmd | or, I in the kernel I do - I've been sloppy with that in eglibc | 11:49 |
| jonibo | I think it's a nice convention... makes the code 10x easier to look at | 11:50 |
| blueCmd | hah, i've been sloppy - never added the UMAX and UMIN | 11:51 |
| blueCmd | jonibo: anyway, you have to messages for approval | 11:52 |
| jonibo | ok, thanks | 11:52 |
| Loke_ | hi | 13:09 |
| Loke_ | I'm currently working on a project using the openrisc release of opencores and I'm having an issue. I would apreciate it if someone were to help me | 13:11 |
| jeremybennett | Loke_: what help do you need | 13:11 |
| Loke_ | I'm trying to compile c++ code | 13:12 |
| Loke_ | but an error in the linker keeps appearing | 13:12 |
| Loke_ | in particular, "no memory region specified for loadable section" | 13:12 |
| jeremybennett | which toolchain are you using? | 13:13 |
| Loke_ | just changed the or1200-elf-gcc for or1200-elf-g++ | 13:13 |
| Loke_ | the rest is the default toolchain that you have in the Virtual Machine release | 13:14 |
| jeremybennett | I've never come across the or1200-elf toolchain. The only ones I know about are the or32-elf tool chain (the stable tool chain) and the or1k-elf tool chain (the development tool chain). | 13:18 |
| jeremybennett | I don't know who puts together the Virtual Machine release, or how hold it is. | 13:18 |
| jonibo | orsoc do and it's more than a year old... AFAIK | 13:19 |
| jonibo | didn't know they had switched the arch to or1200, though... | 13:19 |
| jonibo | LoneTech is probably the best person to ask | 13:20 |
| jeremybennett | I suggest you try the stable tool chain from SVN first. It's easy enough to build. If that works OK, then try the development tool chain from git. It should offer more performance, but it is not (yet) so robust. | 13:20 |
| jeremybennett | good idea of jonibo to ask LoneTech as well. | 13:20 |
| Loke_ | Okay, I will ask him and if not solution comes I will move to the stable tool chain. | 13:21 |
| Loke_ | Thanks a lot. | 13:21 |
| jeremybennett | Details on building the tool chains at http://opencores.org/or1k/OpenRISC_GNU_tool_chain#Installation_from_source | 13:22 |
| Loke_ | Thanks :) | 13:22 |
| blueCmd | long shot: any of you guys know any FPGA board with Fibre channel support? | 14:03 |
| blueCmd | I'm not 100% sure what is needed outside of the FPGA and what can be IPs | 14:03 |
| blueCmd | It might be that it's only the connection to SFP-cages that are needed | 14:13 |
| _franck_ | blueCmd: I would say you need a phy | 15:07 |
| blueCmd | _franck_: I tried to read up what constitutes as a PHY on FC but it seems to be the SFP essentialy | 15:09 |
| _franck_ | just opened up a phy datasheets and yes, it's SGMII | 15:11 |
| _franck_ | so yes, I guess all sfp as a phy inside | 15:12 |
| blueCmd | _franck_: so you say that SFP directly attached to the FPGA would work? | 15:13 |
| blueCmd | because then we have the same conclusion :P | 15:13 |
| blueCmd | which is nice | 15:13 |
| _franck_ | :) | 15:18 |
| _franck_ | yes | 15:18 |
| _franck_ | you can probably find an altera dev board with an SFP on it | 15:19 |
| _franck_ | and you'll have schematics | 15:19 |
| blueCmd | I'll need two, but I found some terasic ones and a couple of other parties | 15:22 |
| blueCmd | woo, TLS support committed fully | 17:05 |
| blueCmd | _franck_: i'm merging stuff from jonibo's gdb, do you know about the features/-files? I wonder why or32-cpu.xml (or or1k) does not exist - is it solved in some other nicer way? | 20:55 |
| jeremybennett | blueCmd: The old or32 GDB didn't use the XML features. It will be useful now we have variant architectures (delay/no-delay). | 21:09 |
| jeremybennett | Remember the target is really supposed to supply this information, although it is useful for the client to have a default verison. | 21:10 |
| blueCmd | jeremybennett: ok, so XML is the way to go? | 21:17 |
| blueCmd | does that have anything todo with CGEN? | 21:18 |
| blueCmd | the code in git uses CGEN AFAICS but the code i'm merging does not, i guess i want to use cgen? | 21:18 |
| _franck_ | yes we want to use CGEN and xml target descriptor | 22:01 |
| _franck_ | https://github.com/Franck79/or1k-src/commits/or1k | 22:01 |
| _franck_ | I haven't pushed my work to the openrisc repo | 22:01 |
| poke53281 | jonibo: Ok, I have send my first small patch to the mailing list. | 22:02 |
| _franck_ | the code in my repo uses tdesc | 22:02 |
| poke53281 | Let's hope I did it right. I am not really familiar with git | 22:03 |
| blueCmd | _franck_: cool will pull that | 22:03 |
| _franck_ | jeremybennett: has inferior function call ever worked in GDB 7.2 ? | 22:14 |
| _franck_ | yes it does work, even in GDB 7.5. | 22:22 |
| blueCmd | _franck_: what are you working at? | 22:24 |
| blueCmd | on* | 22:24 |
| _franck_ | trying to fix some FAIL in the gdb testsuite | 22:24 |
| _franck_ | and learning gdb internals at the same time :) | 22:25 |
| blueCmd | _franck_: cool, i'm debugging why i get a crash in gdbserver, the function i was in was called "inferior" something so I'm just checking :) | 22:26 |
| blueCmd | _franck_: IVe merged your work now, how do I create the xml files? | 23:27 |
| _franck_ | I'm getting it from the remote target (openocd). I made openocd auto generate it | 23:37 |
| _franck_ | I can give you this file | 23:38 |
| _franck_ | http://pastebin.com/zFynJ97k | 23:39 |
| _franck_ | this is the file I'm using | 23:39 |
| _franck_ | it is send by openocd via RSP protocol | 23:40 |
| blueCmd | _franck_: cool, thanks! | 23:41 |
| blueCmd | _franck_: undefined reference to `or1k32bf_exception', seen that before? | 23:42 |
| _franck_ | no | 23:43 |
| blueCmd | _franck_: npc / ppc - whats the diff? | 23:55 |
| _franck_ | next and previous program counter | 23:56 |
| _franck_ | the arch spec says "The Program Counter registers represent the address just executed and the address | 23:56 |
| _franck_ | instruction just to be executed." | 23:56 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!