IRC logs for #openrisc Sunday, 2014-07-13

--- Log opened Sun Jul 13 00:00:17 2014
-!- ams` is now known as ams12:14
olofkblueCmd_, dalias : About gentoo and musl
olofkAnd thanks for the pull requests. I might have some time tonight or tomorrow to look at them14:10
blueCmd_I don't know if that is a regression / new thing, but you might want to look at why verilator thinks that's circular14:55
blueCmd_olofk: np!14:55
blueCmd_olofk: hopefully this will make it easier to use fusesoc/openrisc in designs that are already using avalon/axi14:59
olofkblueCmd_: Yes, this will do wonders to expand the ecosystem16:25
olofkAnd regarding the fusesoc/migen discussions from some time ago; I always intended FuseSoC to support migen for RTL generation16:26
blueCmd_I wonder why ethmac only wants to read 64 / 128 bytes of my packets..17:07
olofkblueCmd_: HW or sim+17:11
olofkIf it's hw you could record the traffic with wireshark and write a VPI module that pushes pcap files through the mac. (That's another one on my todo list :))17:12
blueCmd_olofk: hw17:18
blueCmd_olofk: I'm recording the wishbone bus, and I have the MAC in loopback mode and not showing any RX17:18
blueCmd_it works in the simulator (but then again I wrote the loopback implementation in or1ksim)17:18
blueCmd_olofk: (hw = verilator)17:23
blueCmd_ah. maybe I need to clock rx_clk_pad_i and tx_clk_pad_i even though it's in loopback17:42
blueCmd_that might be relevant. thank you shower idea!17:42
olofkAt least there's one good thing with showers ;)18:03
blueCmd_weeey, it worked \o/18:21
olofkBut how on earth could it read half of the packets when you didn't have clocks connected?18:22
blueCmd_olofk: the backfill logic of the TX FIFO seems to be clocked by the wishbone bus18:27
blueCmd_which makes sense, since it reads by using DMA18:27
blueCmd_and I guess 64 bytes is the depth of the FIFO, and with no TX clock it would just fill the fifo and stop18:28
blueCmd_what's up with seems down to me18:28
olofkThat seeems to be more and more common :(18:28
blueCmd_shame on me for not saving what I needed from there18:29
blueCmd_olofk: are you able to access ?18:29
blueCmd_or do you happen to have that file by any chance?18:32
olofkMight have, but I can't see which file you mean18:34
blueCmd_more specifically I want the connections for RMII hook-up of ethmac18:34
olofkAh ok18:36
olofkHere's the orpsocv2 port for ordb2a that is in the VirtualBox VM from ORSoC
olofkAnd the mii to rmii converter
olofkNow it's time to sleep. Didn't get much of that last night18:40
blueCmd_olofk: thanks a bunch! sleep tight18:40
ysionneauand suddenly, the verilog discussion ended up19:15
ysionneauI don't wonder why :)19:15
blueCmd_ysionneau: hm?19:25
ysionneauI guess some of the guys here are watching tv ;)19:25
ysionneau(world cup final)19:25
blueCmd_aha, I'm not :P19:26
blueCmd_hah, _franck_ - I was looking at MMC code in barebox and suddenly a wild "(C) Copyright 2011 - Franck JULLIEN <>" appears19:36
_franck_the world domination project has begun a long time ago ;)19:37
blueCmd__franck_: you don't happen to be fresh in how to set up MMC / SDcard in barebox?19:52
blueCmd_over SPI19:52
blueCmd_(doesn't need to be SPI, but I guess that is what opencores has best support for)19:52
blueCmd__franck_: that gets me to a login screen20:01
_franck_ah wait20:01
_franck_do you have an opencores SPi driver for barebox ?20:03
blueCmd_though I don't seem to have an oc_tiny_spi driver in my barebox20:03
_franck_but I hacked tiny SPI RTL a bit to add a chip select20:03
_franck_so I never upstreamed this driver20:04
blueCmd_aha ok20:04
blueCmd_too bad20:04
_franck_  <-- ugly20:05
_franck_seems like I didn't hack it after all, just use GPIO as chip select20:05
blueCmd_hah yes20:05
blueCmd_I get:20:17
blueCmd_BUG: failure at drivers/base/driver.c:232/register_driver()!20:17
blueCmd_which is: BUG_ON(!drv->bus);20:17
_franck_this code is 2 years old...barebox has moved forward20:18
_franck_this need to be rebased based on current spi drivers20:18
blueCmd_yeah, I fixed it20:19
blueCmd_do you want me to clean this up for you?20:20
blueCmd_I don't need CS so maybe I can make it work and be "nice enough" or something20:20
_franck_sure. I won't do it anyway.20:20
_franck_are you sure you don't need CS ?20:21
blueCmd_do I? I onlt have 1 device on every bus20:21
_franck_I think it needs to go active/incative to sync the SPI device20:21
blueCmd_pretty sure this was added to tiny SPI though20:22
_franck_if not, you can patch tiny spi in fusesoc and add a CS control bit20:23
_franck_and make it optional in the driver20:23
blueCmd_ah right, so linux does
_franck_barebox has a GPIO framework. However, you need a GPIO driver :) aahh ! it never stops :)20:25
blueCmd_might end up port SPI simple instead maybe20:31
_franck_I started to work on tiny_spi because it is already upstreamed in linux20:31
_franck_and simple_spi is unknown for barebox maintainers20:32
_franck_enough for tonight. Good luck with your SPI.20:33
blueCmd_thanks! I'll probably not persue this anymore right now20:33
blueCmd_ftr, I think simple SPI has _better_ support in linux currently20:34
blueCmd_or maybe it's not upstreamed20:35
blueCmd_jeremy_bennett: those are the GCC authors as far as I can tell21:27
blueCmd_the people I'm worried about being unable to reach are marked with a *21:27
blueCmd_overall I'm optimistic though21:28
--- Log closed Mon Jul 14 00:00:18 2014

Generated by 2.15.2 by Marius Gedminas - find it at!