| --- Log opened Tue Mar 25 00:00:35 2014 | ||
| stekern | _franck__: what ddr controller are you using? and what and how are you connecting to it other than the vga_lcd controller | 04:32 |
|---|---|---|
| stekern | but, yes, it's bandwidth hungry. it puts some demands on the controller. | 04:37 |
| stekern | that's actually the reason why I initially wrote the wb_sdram_ctrl, the versatile sdram controller wasn't fast enough for the vga_lcd | 04:38 |
| stekern | blueCmd: I got the mail from fsf now | 06:05 |
| _franck__ | stekern: I used your wb_sdram_ctrl arbiter/cache and wrapped the altera ddr2 controller behind it | 07:04 |
| _franck__ | https://github.com/fjullien/orpsoc-cores/blob/neek/systems/neek/rtl/verilog/wb_altera_ddr_ctrl/rtl/verilog/ddr_ctrl_wrapper.v | 07:04 |
| _franck__ | plus some hacks here in there to make it works | 07:05 |
| _franck__ | the problem is the configured burst size on the ddr controller size I know ask for 8 bytes at a time but it should be much more to be efficient | 07:06 |
| _franck__ | s/size/side | 07:06 |
| stekern | ah, yes... I know, I have the same problem on the sockit board | 07:10 |
| stekern | ...and I've also noticed that it works better with or1200 than with mor1kx... simply because or1200 is so slow, so there's more bw over for the vga controller | 07:12 |
| stekern | so a smarter arbiter would be needed too | 07:13 |
| _franck__ | there is 1MB of SSRAM on the board. I think I'll put the frame buffer here (need to go down to 16bpp to fit in) | 07:16 |
| stekern | yes, that's ideal | 07:18 |
| stekern | the only problem with that is, I don't think the Linux driver can handle the case where the fb is at some predefined address | 07:19 |
| stekern | that's easily hackable though | 07:19 |
| _franck__ | ah ok, I need to check | 07:20 |
| stekern | has anyone been using ksz8041nl(i) phys? | 07:26 |
| stekern | I'm having endless problems with them... | 07:28 |
| stekern | _franck__: but even with the SSRAM, you're not free from problems, you'll still have the cpu writing to the fb | 07:31 |
| stekern | other data and instructions are of course removed from the equation | 07:32 |
| blueCmd | stekern: excellent! | 08:40 |
| stekern | is it "normal" that auto-mdi/mdix can get confused and take around ~1 minute to figure things out | 11:09 |
| venom00ut | hi, I'm using gdb from trunk, I load an executable with debug symbols but when I try to give `list main` I get an empty response | 11:48 |
| stekern | venom00ut: or32-gdb or or1k-gdb? | 12:04 |
| venom00ut | stekern, or1k-elf-gdb, anyways the debug information are missing in the binary itself for some reason, it's a probably a fault of clang, I'll investigate that better | 12:06 |
| stekern | ah, ok, you should have mentioned that you are using clang/llvm | 12:07 |
| stekern | debug info is indeed a missing feature there | 12:07 |
| venom00ut | yep, I realised later they were actually missing in the binary | 12:09 |
| olofk | blueCmd: Jesus christ. You were not kidding when you said that https://wiki.debian.org/FPGA is bad | 13:17 |
| olofk | stekern: Just read about using -- to delimit what arguments the parser eats. That's great. Didn't know | 13:30 |
| stekern | I found out by accident, just tried it out of habit | 13:37 |
| blueCmd | olofk: haha, no - it's horrible | 13:54 |
| jungma | when I convert the elf generated by or1k-elf-gcc with or1k-elf-objcopy -O binary a.out a.bin I get big endian, but for my purpose i need little endian, how can I change that? | 14:04 |
| olofk | jungma: Aha! You're one of those little endians! | 14:06 |
| olofk | jungma: Out of curiousity. Why do you need little endian? | 14:07 |
| olofk | blueCmd: What backends does beep support? | 14:10 |
| jungma | olofk: I want to put it in a TLM memory in Synopsys' Platform Architect and it seems that the endianess is wrong | 14:20 |
| jungma | but maybe I'm just confused :D | 14:25 |
| olofk | jungma: Don't think I have any useful input there unfortunately | 14:26 |
| olofk | We had a discussion about a week ago and wondered why people were asking for little endian versions of OpenRISC, so I just had to ask :) | 14:27 |
| jungma | okay | 14:29 |
| jungma | olofk: I think that the byte order is wrong | 14:29 |
| jungma | when I disassemble the code i get: | 14:30 |
| jungma | 100: 18 00 00 00 l.movhi r0,0x0 | 14:30 |
| jungma | but at my TLM transactor I receive 0x18 | 14:30 |
| jungma | by the way, are some of you guys at DATE14? :) | 14:31 |
| blueCmd | olofk: I don't know, it appears to be writing some things to the TTY FD using ioctl | 14:35 |
| blueCmd | so it's a kernel driver for the PC speaker I'd guess | 14:35 |
| blueCmd | you could probably GPIO it | 14:35 |
| olofk | jungma: Hadn't seen date before. Looks like an interesting conference | 14:48 |
| _franck_web_ | I have a problem with github access with fusesoc. I don't know if the problem is coming from my python installation or from my local network | 14:51 |
| _franck_web_ | this is what I have: http://picpaste.com/pics/azeed-bWtAvr0B.1395759016.png | 14:51 |
| _franck_web_ | I can get the file with wget but getting it with urllib.urlretrieve gives me a "bad request" | 14:52 |
| jungma | olofk: yap, it's a must be at our chair :D | 14:54 |
| olofk | _franck_web_: I remember someone at orconf who had problems with https accesses with his python installation | 15:20 |
| olofk | Could that be the problem? | 15:21 |
| _franck_web_ | may be. I did try this: http://paltman.com/2007/11/15/getting-ssl-support-in-python-251/ | 15:21 |
| olofk | gtg | 15:21 |
| _franck_web_ | but it didn't solve the problem | 15:21 |
| ulrichk | Is anyone here familiar with the pipeline implementation of the OR1200? | 15:28 |
| stekern | ulrichk: faintly, I know the mor1kx cappuccino one by heart rhough | 15:38 |
| stekern | though | 15:38 |
| blueCmd | stekern: pff, why? it's not like you wrote it or anything.. | 15:38 |
| ulrichk | I am trying to understand the pipe - on the website (http://opencores.org/or1k/OR1200_OpenRISC_Processor#Implementation_information), it says it has 5 stages. | 15:39 |
| ulrichk | In the verilog code, I can distinguish 4 stages (if, id, ex, wb)... | 15:39 |
| ulrichk | And then in fact, the register file write enable seems to go high in execute already, so I don't know what writeback really does. | 15:40 |
| ulrichk | So basically, 3 stages left... any idea would be helpful | 15:41 |
| stekern | ulrichk: afair, it's just 4 stages, so your observation there is correct | 15:46 |
| stekern | blueCmd: mostly, I shuffled around juliusb's code to my liking ;) | 15:57 |
| ulrichk | stekern: thanks, I will have a closer look on the regfile. Seems like the 1 cyc delay for reading is why we still need writeback as an extra stage. | 16:10 |
| Findeton | hi there | 21:44 |
| Findeton | why isn't the OpenRISC ASIC a kickstarter project? | 22:03 |
| Findeton | it would probably get funding in a week | 22:03 |
| blueCmd | Findeton: it was | 23:14 |
| blueCmd | http://dangerousprototypes.com/2013/01/18/openrisc-asic-chip-fundraiser/ | 23:14 |
| Findeton | yeah, that is crowdfunding | 23:15 |
| blueCmd | as opposed to kickstarter? | 23:16 |
| Findeton | I'm just saying it needs more publicity and getting it into kickstarter could make a difference | 23:16 |
| blueCmd | well, one could obviously try - but I think it's the wrong way around. publicity first and then ASICs | 23:16 |
| blueCmd | but I might be wrong | 23:16 |
| Findeton | what I don't know is the frequency the ASICs would run | 23:18 |
| Findeton | maybe 500Mhz? | 23:18 |
| Findeton | perhaps you can get near that with good fpgas, although that's more expensive per person if you already have ASICs | 23:19 |
| blueCmd | sure is | 23:20 |
| blueCmd | regarding the speed, that's just a question of money really | 23:24 |
| blueCmd | the smaller process you can afford, the higher speed sort of | 23:24 |
| --- Log closed Wed Mar 26 00:00:37 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!
