| --- Log opened Sun Sep 15 00:00:57 2013 | ||
| poke53282 | olofk: swrast, but the llvmpipe sounds interesting. According to the web site you need an x86 compatible cpu. | 04:13 |
|---|---|---|
| _franck_ | stekern: sorry, I looked on the unified patch itself and there is no space there | 06:07 |
| stekern | are all avalon accesses registered? | 08:23 |
| stekern | It acks my reads on the same cycle as the read signal goes high, but the data is not right | 08:25 |
| LoneTech | I've forgotten how avalon-mm handshaking works, but I think it essentially does two streams. hang on a moment | 11:57 |
| stekern | ah, now I understand how it works... I'm only suppose to hold 'read' signal high when 'waitrequest' is asserted, even if 'readdatavalid' doesn't get asserted on the first clock cycle 'waitrequest' is deasserted | 11:57 |
| LoneTech | yep, readdatavalid marks when data appears | 11:57 |
| LoneTech | waitrequest means any access posted that cycle is not handled | 11:58 |
| stekern | because you can pipeline several reads until 'waitrequest' get asserted | 11:58 |
| stekern | yeah, I get it now | 11:58 |
| LoneTech | also, spec says there must be a cycle of latency from read to readdatavalid | 11:59 |
| LoneTech | (at least) | 12:00 |
| stekern | ok, but I'm looking at it from the master side, so it doesn't "concern" me (right now at least) | 12:07 |
| stekern | but thanks for the heads up on that | 12:08 |
| stekern | I will need to do avalon master to wb slave soon anyways | 12:08 |
| stekern | woho! LEDs are blinking =) | 12:48 |
| stekern | and hello world is working too | 12:50 |
| stekern | Linux crashes though... | 13:48 |
| stekern | at least there is some console output before that happens | 13:49 |
| olofk | _franck_: Great job with the url provider. I'll take a look at it tomorrow. Haven't had time this weekend | 21:48 |
| olofk | and yes, patches aren't available for local cores. Might be useful in some situations though | 21:49 |
| stekern | I'm feeling the scope creep coming on to me... it started out with a simple wb<->avalon bridge, now I'm considering big furry monsters... | 21:50 |
| _franck_ | can't we just ask github to send a pull request on a specific commit ? | 21:56 |
| _franck_ | look at the pull request I sent you stekern, I didn't want you to merge 4 commits.... | 21:57 |
| _franck_ | olofk: https://github.com/openrisc/orpsoc/blob/master/orpsoc/provider/github.py#L22 is that normal it doesn't return anything ? | 22:00 |
| stekern | what have you sent me? | 22:02 |
| stekern | but, no, you send a pull request for a branch. if you change that branch, you change what is going to be pulled too | 22:03 |
| stekern | that's normal, but with the github web interface it's confusing | 22:04 |
| _franck_ | so I should never commit to the master branch and use it as a base for new branches where I would cherry-pick what I want to send as a pull request | 22:10 |
| stekern | I usually have a for-<something> branch that represents 'upstream' where I cherry-pick commits ready for 'upstreaming' | 22:11 |
| _franck_ | ok | 22:12 |
| stekern | that way, you can do merges in your master branch (i.e. not rewriting history there), and always 'git pull -r' when you update the for- branch | 22:15 |
| --- Log closed Mon Sep 16 00:00:58 2013 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!