| --- Log opened Thu Oct 17 00:00:43 2013 | ||
| hansfbaier | olofk: https://github.com/hansfbaier/orpsoc-cores/compare/openrisc:master...master | 02:44 |
|---|---|---|
| hansfbaier | olofk: I hope now it's in a sane state | 02:44 |
| hansfbaier | stekern: ^ | 02:44 |
| stekern | hansfbaier: you shouldn't incrementally apply corrections to something that hasn't been pulled yet | 03:03 |
| hansfbaier | stekern: I thought about it, too. The diff looks nice right now, but the log on openrisc might be cluttered. | 03:04 |
| hansfbaier | stekern: What would you recommend, remove the patch and add another one? I can't see an option to retract parts of a pull request. | 03:04 |
| stekern | and the reasoning for removing the #1 annotations in orpsocv2 is because they are ugly and unnecassary | 03:05 |
| stekern | you should close the pull request, fix things up and do a new pull request | 03:06 |
| hansfbaier | stekern: Ah I see. Thanks | 03:06 |
| hansfbaier | stekern: Yes they make things harder to read. | 03:07 |
| stekern | I would also use a seperate branch than your master, but that's entirely up to you | 03:07 |
| hansfbaier | stekern: What would the benefits be? | 03:12 |
| hansfbaier | stekern: If I understand linus correctly he said the moment I clone I git repo, I am already on my own branch | 03:12 |
| hansfbaier | stekern: I am looking hard, but can't find how to cancel a pull request.... weird | 03:13 |
| hansfbaier | stekern: I'll try google | 03:16 |
| hansfbaier | stekern: Would 32'hfffffff8 be the right match mask for SPI, with the old location on 32'hb0000000 ? | 03:18 |
| stekern | yes, but you might want to keep your own (public) history seperate from your pull requests | 03:19 |
| stekern | (look in my orpsoc-cores master for example) | 03:19 |
| stekern | if you don't, fine ;) | 03:20 |
| hansfbaier | stekern: Weird, no matter how hard I look, I cant find that button: https://help.github.com/articles/closing-a-pull-request | 03:20 |
| stekern | hansfbaier: on the bottom of the page, under the comment field | 03:22 |
| stekern | oops I accidently pressed it | 03:23 |
| hansfbaier | stekern: Ahh, ok fine. | 03:23 |
| hansfbaier | stekern: Wondered why it was fone | 03:23 |
| hansfbaier | gone | 03:23 |
| hansfbaier | stekern: What would I want to do now? Remove the file, readd it, then only submit that latter patch? | 03:24 |
| stekern | git rebase -i | 03:26 |
| hansfbaier | stekern: thanks | 03:28 |
| hansfbaier | stekern: So if I understand correctly your branch for-openrisc contains the pull requests? | 03:34 |
| hansfbaier | stekern: So if I create a branch for-openrisc too, then I could rebase the changes from my master into that branch? | 03:35 |
| poke53281 | stekern: I have summarized a little bit my findings in QEMU and send to the mailing list. Let's see what Jia Liu will say. | 03:59 |
| stekern | hansfbaier: correct | 04:07 |
| stekern | poke53281: excellent! | 04:08 |
| stekern | I'll go read it right away ;9 | 04:08 |
| stekern | poke53281: good summary, I think it doesn't sound like your proposed changes will break the spec by far | 04:19 |
| stekern | what do you mean with "delayed instructions" in this context though, is that some qemu thing or are you speaking about the branch delay slot? | 04:20 |
| stekern | but anyways, I agree with the last sentence. qemu is an emulator, not a simulator, so it doesn't have to emulate the hardware perfectly. | 04:25 |
| poke53281 | I am talking about the branch delayed slot | 04:26 |
| poke53281 | The main violation is point no 1. But this gives also the most benefit. | 04:27 |
| stekern | ok, and the impossibility to get exceptions in them "by design", is that "by design" down to how qemu handles things? | 04:28 |
| poke53281 | Yes | 04:28 |
| poke53281 | by design is some QEMU thing | 04:28 |
| stekern | because tick timer and interrupt exceptions can happen all the time | 04:28 |
| stekern | ok, yeah, then I understand | 04:29 |
| poke53281 | Look at the 3 points how the tcg works. | 04:29 |
| poke53281 | It is never interrupted and there is always only one branch or jump in the end. | 04:29 |
| stekern | ah, right | 04:29 |
| stekern | and the delay slot is included in that, makes sense | 04:30 |
| poke53281 | yes | 04:30 |
| poke53281 | only in debug singleshot mode this is important. | 04:30 |
| stekern | yes, but it's ok to just not allow interrupt and tick timer exceptions in the delay slot even then | 04:31 |
| poke53281 | Yes | 04:31 |
| stekern | regarding the flags (1), would it be possible to just calculate them when there's a mfspr from SR? | 04:32 |
| stekern | or the special case with l.addc, that you already mentioned | 04:34 |
| poke53281 | Yes, but it must be in the same code fragment. | 04:34 |
| stekern | oh... | 04:34 |
| poke53281 | And here also the tcg from the i386 fails. If you keep the carry over a jump it is lost. | 04:34 |
| stekern | hmm | 04:34 |
| poke53281 | add followed by addc is fine | 04:35 |
| stekern | yes | 04:35 |
| poke53281 | add followed by branch followed by addc will probably not work. | 04:35 |
| poke53281 | I can send you 100MB debug output for openrisc and i386. Then you can see how everything works. | 04:36 |
| hansfbaier | stekern: How do you like this: https://github.com/hansfbaier/orpsoc-cores/compare/openrisc:master...for-openrisc | 04:36 |
| stekern | yes, I see. So, yeah, that would be the biggest "spec breaker" | 04:36 |
| poke53281 | But addc is never used in the toolchain. | 04:36 |
| stekern | poke53281: haha, no, I'm fine, I prefer to just pick the most important parts from your brain ;) | 04:36 |
| poke53281 | So at the moment we are talking about hand written assembler. | 04:36 |
| hansfbaier | stekern: Is it ok to do one pull request for the three commits, or one for each? | 04:37 |
| hansfbaier | like you did? | 04:37 |
| poke53281 | The other one is for example the exception overflow flag. At the moment it is checked dynamically every time. If I check it only one time for the whole block it should be fine. So if you execute the same code twice, one time with flag and one time without flag it will fail. | 04:39 |
| poke53281 | Even then it is possible that it will work. I could invalidate all compiled code if the flag is set. | 04:41 |
| stekern | hansfbaier: why are there pure whitespace changes in the same patch as functional changes? | 04:44 |
| stekern | ideally, it should be patch 1: whitespace cleanup, patch 2: remove #1 notion, patch 3: reverse reset logic, patch 4: add support for slave select, patch 5: other changes that I haven't spotted in the diff? | 04:46 |
| stekern | to answer your question, it's ok to do a pull request for the whole set of commits | 04:47 |
| * hansfbaier tired | 04:52 | |
| hansfbaier | stekern: I'll carry on tomorrow.... | 04:52 |
| hansfbaier | stekern: That means I have to redo everything I did today... | 04:55 |
| hansfbaier | stekern: Has some educational value though... | 04:55 |
| stekern | hansfbaier: sorry for being a picky ass ;) | 04:57 |
| hansfbaier | stekern: You are right, I should be done cleanly, if it is worth being done. I'm just a bit down now, after spending half my day on it, when I should have been feeding my family instead... | 04:59 |
| hansfbaier | But I'll get over it | 04:59 |
| hansfbaier | Have to learn to do it properly | 05:00 |
| hansfbaier | stekern: Shouldn't we try to upstream some of that? If I read correctly the reset logic on wishbone is sync active high, or am I mistaken? | 05:01 |
| hansfbaier | Also there are some minor issues, an unused reg, some bitrotten comments | 05:02 |
| stekern | yes, we should | 05:03 |
| stekern | that's why I think it's also important that we have good seperated commits, that will make it a lot more easier if the upstream author only agree with a subset of the changes | 05:06 |
| hansfbaier | ok | 05:06 |
| stekern | s/commits/patches | 05:06 |
| poke53281 | http://simulationcorner.net/Visits.png | 05:12 |
| poke53281 | Yes, I am proud. | 05:13 |
| stekern | hansfbaier: but that's the right spirit, I usually think that way too, if it feels like I wasted time on something, I evaluate what I've learned from it | 05:19 |
| stekern | poke53281: you should be | 05:29 |
| hansfbaier | stekern: Once again: https://github.com/hansfbaier/orpsoc-cores/compare/openrisc:master...for-openrisc | 05:39 |
| hansfbaier | stekern: I know the unused register patch contains whitespace as well, need fix? | 05:40 |
| stekern | hansfbaier: that looks great! | 05:42 |
| hansfbaier | stekern: OK, I'll create a push request then | 05:42 |
| stekern | and no, if you fix whitespace damage in the same line as you do the actual functional change, it's fine to just keep it in the same patch | 05:43 |
| hansfbaier | stekern: https://github.com/openrisc/orpsoc-cores/pull/21 | 05:46 |
| stekern | think about how you read the patches, you look at the changed lines and look for what is changed, if there are a lot of lines with *only* whitespace changes, a lot of time will be wasted trying to figure out what functional change that line has, when there is none | 05:46 |
| stekern | if there is an actual functional change, the time was not wasted | 05:46 |
| stekern | and when the whitespace-only changes are separate you can look at that patch with a different mindset | 05:48 |
| hansfbaier | stekern: Yes, redoing it was quicker than I had anticipated, I just gradually copied over the changes with meld (except WS and #1) | 05:48 |
| hansfbaier | stekern: Also I understood the code better when I realized the added address bit was actually necessary in order to access slave select over WB | 05:49 |
| hansfbaier | stekern: Do I need some kind of adapter in orpsocv3 to tie it in (like I see uart0 has a 32->8 bit adapter...). | 05:50 |
| hansfbaier | stekern: I have already created most of the interconnect and instantiation, but I'm not sure about the different bus sizes. | 05:50 |
| stekern | yes, you have to add the 8bit adapter for it | 05:51 |
| stekern | basically just copy the uart one and do a search-and-destroy^Wreplace on uart0 | 05:52 |
| stekern | I guess support for automatically adding that could be added to the wb_intercon_gen, but for now it has to be done manually | 05:53 |
| hansfbaier | stekern: Where is that wb_intercon_gen, in orpsoc? | 05:54 |
| stekern | in orpsoc-cores | 05:56 |
| stekern | didn't you use that for the interconnect? | 05:56 |
| stekern | https://github.com/openrisc/orpsoc-cores/blob/master/cores/wb_intercon/sw/wb_intercon_gen | 05:57 |
| stekern | and it use this: https://github.com/openrisc/orpsoc-cores/blob/master/systems/de0_nano/data/wb_intercon.conf | 05:58 |
| hansfbaier | stekern: No, manual | 06:05 |
| hansfbaier | stekern: I begin to understand... | 06:06 |
| hansfbaier | stekern: But the top file is still manual as it seems... | 06:07 |
| hansfbaier | stekern: Which irq should I assign to spi0? | 06:07 |
| olofk | stekern: Yes, I want a setup or prepare command too, perhaps even in two levels. One that just fetches the cores, and one that also writes all input files for the build tools and simulators. The last one is good if you want to use what's in build/<system> without using orpsoc | 06:09 |
| olofk | stekern: Haven't had time to turn on my computer yet, so I never got around to commit that. You can do that if you want. You have commit rights, don't you? | 06:09 |
| hansfbaier | stekern: the size parameter, is that in bytes, | 06:10 |
| hansfbaier | ? | 06:10 |
| olofk | stekern, hansfbaier : I don't have any preferences regarding diff styles. I generated mine with quilt, others with git. Just make sure they apply correctly | 06:11 |
| hansfbaier | olofk: Ah, didn't test that, good idea :) But they should | 06:12 |
| hansfbaier | stekern: As it looks with wb_interconn_gen `ifdef SPI0 isn't really an option anymore, is it? | 06:17 |
| stekern | hansfbaier: check in old orpsocv2 where spi0 irq were connected | 06:18 |
| stekern | I think it should be consistent between boards there | 06:18 |
| hansfbaier | stekern: Good idea, thanks | 06:19 |
| stekern | hansfbaier: I haven't considered that, but what's the showstopper for `ifdef SPI0? | 06:20 |
| hansfbaier | stekern: probably none, if the top isn't instantiated, the wb nets should be optimized away by the synthesizer/fitter | 06:20 |
| hansfbaier | let's see if it compiles | 06:21 |
| stekern | yes, you'll get a few dangling wires, which perhaps isn't all perfect, but it should 'do the job' still | 06:24 |
| olofk | I think that _franck_ kept som `ifdef $CORE in de1. That is totally ok. Just assign values to return data, ack, err and rty | 06:25 |
| olofk | Thanks for the pull requests. I'll take a look at them as soon as I can. Can't promise it will be today though :( | 06:25 |
| hansfbaier | olofk: y/w | 06:31 |
| hansfbaier | olofk: Just tested the patches. Apply well. | 06:42 |
| olofk | hansfbaier: Great. Keep the cores coming :) | 06:43 |
| hansfbaier | olofk: Grrr, but got a compile error in it. | 06:44 |
| olofk | I saw your questions about 8/32 bit too. There is a wb_data_resize.v in wb_intercon that you can use to connect 8 bit slaves. It will eventually be instantiated directly by wb_intercon_gen, but for now you have to add it manually | 06:44 |
| hansfbaier | olofk: missing semicolon ..... | 06:45 |
| hansfbaier | stekern: Have to redo the patches, don't I... | 06:46 |
| stekern | yeah... it's a bit annoying with the patches in patches, it's double work to do it | 06:56 |
| hansfbaier | olofk: Don't pull yet, have to redo it again... | 06:56 |
| stekern | if it's just a missing semicolon, I would just rebase the orpsoc-cores commits and manually edit the .patch file | 06:56 |
| hansfbaier | stekern: Yes I'll do | 06:56 |
| stekern | then force push to the branch where the pull request is | 06:57 |
| olofk | I don't want to carry a lot of patches in orpsoc either, but I think it's good to have support for that so patches don't get lost until they are upstreamed | 07:07 |
| olofk | The other alternative would of course be to pull from a forked repo | 07:07 |
| hansfbaier | Cool! Synthesis passes successfully for de0_nano with SPI | 07:35 |
| hansfbaier | Now the fitter is fitting... | 07:35 |
| hansfbaier | worked! | 07:39 |
| hansfbaier | stekern: Pushed it with a bit of force.... | 07:46 |
| hansfbaier | stekern: the pull request changed automatically, nice | 07:47 |
| hansfbaier | stekern, olofk: the wb_intercon_gen does it do only masks for power-of-two sized sizes? I used size=5 and it generated 0xf...fb which is kind of weird. I had anticipated 0xf...f8 | 07:58 |
| stekern | it generates the mask by ~(size-1), which is not correct for all input values, see the irc backlog for further info | 08:00 |
| stekern | ;) | 08:00 |
| hansfbaier | stekern: OK will fix to next power of two | 08:03 |
| hansfbaier | stekern: but won't generate since is messes up the order of blocks in the file making the diff ugly | 08:03 |
| stekern | ? | 08:05 |
| stekern | just reorder the slaves in the conf then? | 08:06 |
| mor1kx | [mor1kx] xfguo opened pull request #8: Older versions of icarus doesn't support always @* with empty sensitivity list. (master...master) https://github.com/openrisc/mor1kx/pull/8 | 08:32 |
| hansfbaier | olofk: stekern: The pull request got bigger | 08:33 |
| hansfbaier | https://github.com/openrisc/orpsoc-cores/pull/21 | 08:33 |
| hansfbaier | console [ttyS0] enabled, bootconsole disabled | 08:50 |
| hansfbaier | OpenCores Simple SPI controller (c) 2010 South Pole AB | 08:50 |
| hansfbaier | [...] | 08:51 |
| * hansfbaier calls it a day | 08:51 | |
| olofk | hansfbaier: Good work! Hope to have time to look at it soon | 08:53 |
| hansfbaier | olofk: I should have worked today actually, but I needed to get this out of my mind to be able to concentrate on my paid work again :) | 08:54 |
| olofk | You get paid for this work too. I can give you a 30% discount on any core on OpenCores | 08:55 |
| hansfbaier | olofk: :) | 08:57 |
| hansfbaier | olofk: Not shure how I'd test the SPI, maybe connect an Arduino | 08:57 |
| olofk | hansfbaier: You need my fancy SPI BFM that I wrote about in one of my blog posts | 09:01 |
| _franck_ | hansfbaier: you can test it by connecting it to the altera EPCS. You have an altera IP allows you to access the EPCS SPI pins | 09:01 |
| olofk | I think _franck_'s idea is better, since my BFM isn't implemented yet :) | 09:01 |
| olofk | Or get a bus pirate from dangerousprototypes.com | 09:01 |
| hansfbaier | olofk: I have a logic analyzer too | 09:02 |
| hansfbaier | _franck_: Ahhh, yes memory | 09:02 |
| hansfbaier | _franck_: good idea. I have a heap of AT24 here (50pcs) | 09:03 |
| olofk | hansfbaier: You're packing more components than the rest of the combined OpenRISC community :) | 09:04 |
| hansfbaier | It's only 20, sorry | 09:05 |
| hansfbaier | Arduino might be a nice idea, though, sketch that prints out SPI data on serial can be ready in 10 minutes | 09:05 |
| mor1kx | [mor1kx] skristiansson closed pull request #8: Older versions of icarus doesn't support always @* with empty sensitivity list. (master...master) https://github.com/openrisc/mor1kx/pull/8 | 09:17 |
| stekern | hansfbaier: connecting the EPCS is something we'll want to do eventually anyway | 09:22 |
| hansfbaier | stekern: I see. | 09:26 |
| stekern | http://git.openrisc.net/cgit.cgi/stefan/orpsoc/tree/boards/altera/de0_nano/syn/quartus/tcl/SPI0_pin_assignments.tcl | 09:29 |
| stekern | or the accelerometer | 09:29 |
| stekern | http://git.openrisc.net/cgit.cgi/stefan/orpsoc/tree/boards/altera/de0_nano/syn/quartus/tcl/SPI1_pin_assignments.tcl | 09:29 |
| hansfbaier | stekern: good idea | 09:30 |
| hansfbaier | stekern: the first one is already committed | 09:31 |
| hansfbaier | and in the pull request. | 09:31 |
| stekern | aha ;) | 09:31 |
| hansfbaier | stekern: didn't bother to look the pins up. Let me see | 09:31 |
| hansfbaier | stekern: is that the EPCS | 09:31 |
| hansfbaier | ? | 09:31 |
| stekern | yes | 09:31 |
| hansfbaier | stekern: Ah, the second the accel? | 09:32 |
| stekern | yes | 09:32 |
| rah | hansfbaier: on the sockit, would it be possible to access the HPS's DDR3 memory from the FPGA through a bus bridge? | 09:32 |
| hansfbaier | stekern: then the EPCS is already hooked up | 09:32 |
| hansfbaier | rah: Yes, both ways | 09:32 |
| rah | hmm | 09:32 |
| rah | cool | 09:32 |
| rah | hansfbaier: do you have VGA output working? | 09:34 |
| rah | </more-newbie-questions> | 09:34 |
| rah | :-) | 09:34 |
| hansfbaier | rah: Yes, both ways | 09:34 |
| hansfbaier | rah: from HPS and FPGA | 09:34 |
| rah | cool | 09:34 |
| rah | hansfbaier: what resolution? :-) | 09:34 |
| hansfbaier | rah: as stekern sai 800x600 | 09:35 |
| hansfbaier | s/sai/said/ | 09:35 |
| rah | oh :-/ | 09:35 |
| stekern | no, it's 640x480 | 09:35 |
| stekern | the pixel clock is currently hardcoded to 25.2 MHz | 09:36 |
| rah | I looked at the DAC datasheet and I saw mention of 1600x1200 | 09:36 |
| rah | oh | 09:36 |
| rah | can the pixel clock be changes? | 09:36 |
| rah | s/ges/ged/ | 09:36 |
| hansfbaier | stekern: set_global_assignment -name RESERVE_DATA1_AFTER_CONFIGURATION "USE AS REGULAR IO" | 09:36 |
| hansfbaier | stekern: what are those lines good for? I left them out in the commit | 09:36 |
| hansfbaier | rah: Very likely. Somebody has to do the work though | 09:37 |
| stekern | rah: yes, it can be changed, there are some problems with the bandwidth from the HPS DDR3 into VGA core currently though | 09:37 |
| stekern | so, when the HPS writes to intensively to the HPS DDR3, the screen flickers | 09:38 |
| hansfbaier | stekern: That wouldn't be a problem if accessed through the OpenRISC in the FPGA? | 09:38 |
| stekern | but the pll connected to the pixel clock is a static one, so changing the pixel clock means resynthesize the system atm | 09:39 |
| stekern | I'm going to change that to a reconfigurable pll | 09:39 |
| rah | hmm | 09:40 |
| stekern | hansfbaier: humm, how do you mean? the VGA core have it's own wb master interface | 09:40 |
| stekern | it's basically because the latency to start a burst is to large, and the VGA cores largest burstwidth is 8 | 09:41 |
| rah | well it sounds like it's primitive but usable, and could do with more work to get more functionality from it | 09:41 |
| stekern | so increasing that might completely remedy the problem | 09:42 |
| rah | I'm comparing it to the Cyclone V GX Start Kit which has an ADV7513 HDMI controller whose programming information is only available under NDA, and for which there seems to be no supporting code available in opencores | 09:42 |
| * rah gets the feeling it would not be a good idea to branch out on his own while having no experience whatsoever of FPGAs | 09:46 | |
| stekern | chances are that you don't need that to use it for your purposes | 09:47 |
| stekern | the information you get under NDA, I mean | 09:47 |
| rah | possibly | 09:47 |
| rah | but I would still need to put together (1) my own openrisc image including interfaces to the HDMI controller, and (2) my own X driver | 09:48 |
| hansfbaier | stekern: Do you have a dts entry for the EPCS? | 09:49 |
| stekern | (1) yes (2) no | 09:49 |
| rah | stekern: why not X driver? | 09:50 |
| rah | stekern: what X driver would I use? | 09:50 |
| stekern | hansfbaier: http://oompa.chokladfabriken.org/openrisc/de0_nano.dts | 09:50 |
| stekern | but as was discovered by knz, never de0_nano have epcs that are spansion chips, not st | 09:51 |
| stekern | so experiment with the compatible = "st,m25p64"; if that gives you troubles | 09:51 |
| stekern | rah: the fb driver | 09:52 |
| hansfbaier | stekern: Do you have a touch screen display hooked up to the de0_nano? | 09:52 |
| stekern | yes | 09:52 |
| hansfbaier | stekern: Is it similar to this one: http://www.wvshare.com/product/4.3inch-480x272-Touch-LCD-B.htm | 09:53 |
| hansfbaier | stekern: I have that. Could you hand me the code/stuff to get that working? | 09:53 |
| hansfbaier | stekern: cool | 09:53 |
| stekern | hmm, could be similar. but its 800x400 | 09:54 |
| stekern | the lcd I men | 09:54 |
| stekern | can't find what ts chip they use in yours | 09:55 |
| stekern | it was mostly a matter of connecting the gpio to an interrupt and enable the driver in linux + the dts stuff | 09:57 |
| stekern | check in orpsoc_top | 09:57 |
| stekern | ah... sorry, I haven't pushed that... | 09:57 |
| stekern | http://oompa.chokladfabriken.org/openrisc/orpsoc_top.v | 09:59 |
| hansfbaier | stekern: Driver is a Himax HX8257-A | 10:00 |
| stekern | ok, so it's not the same. ad7843 on my | 10:00 |
| hansfbaier | stekern: needs a driver in the linux kernel. huh? | 10:05 |
| hansfbaier | stekern: The EPCS where is it connected on your dts, spi0? | 10:05 |
| hansfbaier | that looks like a flash card | 10:05 |
| rah | stekern: ok, but then wouldn't I need to write an FB driver? | 10:07 |
| stekern | rah: you can use the one that I wrote | 10:09 |
| rah | stekern: ah :-) | 10:42 |
| rah | stekern: you have an FB driver that will drive an ADV7513 HDMI controller? | 10:43 |
| hansfbaier | olofk, stekern: Now SPI1 (the AD converter) is connected, too | 10:45 |
| stekern | rah: an fb driver for the vga/lcd core, yes | 10:58 |
| gautschi | q | 11:27 |
| hansfbaier | HAHAHA that's the sign I'm tired. I added the SPI1 connection to the AD converter too. But the serial just would be blank on barebox and linux, whereas memory tests and blinkys (barebone) worked. So I double checked the patches, and promptly discovered that I assigned the same memory to spi0 and spi1 (copy and paste error). After correcting the same errors persisted. I was dumbfounded, what was it? | 11:44 |
| hansfbaier | As it turned out the serial2usb of the de0-nano was disconnected (switched off) and an empty ft245 was on instead...... | 11:45 |
| hansfbaier | I discovered the good news after I saw the linux heartbeat LEDs blinking..... | 11:45 |
| rah | well, then I'd still need to integrate the HDMI DRM output into the FB driver | 11:46 |
| rah | regardless, (1) was enough to put me off :-) | 11:46 |
| * hansfbaier is longing for the moment, when I can send my first email that ends with: -- Sent from my FPGA | 11:47 | |
| rah | mmm | 11:49 |
| juliusb | that'd be very cool | 11:49 |
| rah | has anybody managed to achieve that? | 11:49 |
| * rah wants this as well | 11:49 | |
| ams | hansfbaier: port the CADR to an fpga, en run System 99 on it, connect via CHAOSnet and send email using bangs ??? win ? :-) | 11:51 |
| hansfbaier | ams: what is CADR? | 11:52 |
| hansfbaier | you confuse me... | 11:52 |
| ams | hansfbaier: it is a revised version of the CONS | 11:53 |
| ams | http://en.wikipedia.org/wiki/Lisp_machine | 11:53 |
| hansfbaier | ams: LISP.... | 11:53 |
| ams | :-) | 11:53 |
| hansfbaier | ams: why not haskell? | 11:53 |
| hansfbaier | way geekier than LISP | 11:53 |
| ams | http://www.unlambda.com/index.php?n=Main.Cadr | 11:54 |
| ams | hansfbaier: i disagree. | 11:54 |
| hansfbaier | ams: Does LISP have Monads? | 11:54 |
| ams | hansfbaier: sure | 11:54 |
| hansfbaier | ams: But LISP is not side effect free :-P | 11:55 |
| ams | hansfbaier: the question has RANDOM-LANGUAGE-TURING-COMPLETE-LANGUAGE feature FOO is quite pointless. | 11:55 |
| hansfbaier | ams: Not purely functional that is | 11:55 |
| ams | hansfbaier: it can be, quite easily. | 11:55 |
| ams | you are also implying, indirectly, that side effect free languages are somehow better in all cases. | 11:56 |
| rah | hansfbaier: I'm thinking about getting a sockit now, and if you have a sockit but can't send emails, I'm wondering: what is preventing you from doing so? | 11:56 |
| rah | what are the blocks? | 11:56 |
| hansfbaier | rah: well priorities :) | 11:57 |
| hansfbaier | rah: I want to write a network driver that connects the HPS and the FPGA Linux | 11:58 |
| hansfbaier | rah: copies packets over via memory | 11:58 |
| hansfbaier | rah: but before that I want to do that as a char device. | 11:58 |
| hansfbaier | rah: But today I decided to play with the de0_nano instead. | 11:58 |
| hansfbaier | rah: Still a lot to learn | 11:58 |
| rah | hansfbaier: ah yes, you mentioned that | 11:59 |
| hansfbaier | rah: If I have the netdev, just need to compile an email client like mailx and send the mail | 11:59 |
| rah | hansfbaier: have you bridged the ethernet PHY on the HPS? (or tried to?) | 11:59 |
| stekern | rah: hdmi drm? the chip you are speaking about have a "vga" interface by the looks | 11:59 |
| hansfbaier | rah: not tried, not interested ATM | 11:59 |
| ams | actually, i will pay anyone 1000 EUR if they get a symbolics 3600 on an fpga. | 12:00 |
| hansfbaier | rah: want to learn about driver development. IIRC stefan has used two new IP cores to connect the two systems using existing Linux drivers. | 12:00 |
| rah | stekern: there's a "DRM encoder slave" kernel driver from the manufacturer which will allow you to control the HDMI output | 12:02 |
| rah | stekern: http://wiki.analog.com/resources/tools-software/linux-drivers/drm/adv7511 | 12:03 |
| rah | (and audio) | 12:03 |
| rah | hansfbaier: I see | 12:03 |
| hansfbaier | rah: http://opencores.org/project,igor | 12:03 |
| hansfbaier | sorry | 12:03 |
| hansfbaier | ams: http://opencores.org/project,igor | 12:03 |
| hansfbaier | ams: http://www.aviduratas.de/lisp/lispmfpga/ | 12:05 |
| ams | hansfbaier: honestly i'm not to interested in `new' isa designs for lispm :-) | 12:07 |
| ams | mostly since they tend to revolve around `oh look ... we can do lispy stuff on a instruction level ... now we are done' ... | 12:08 |
| * hansfbaier is done for today | 12:08 | |
| ams | which is totally uninteresting, it has been done since the 1970's with a cpu doing gc on the chip. | 12:08 |
| hansfbaier | see you around | 12:09 |
| ams | ciao | 12:09 |
| stekern | rah: why on earth do you want to DRM encode yourfb output??? | 12:18 |
| _franck_ | HDCP decoding would be more useful | 12:19 |
| _franck_ | one more thing I always wanted to do... | 12:20 |
| rah | stekern: erm.. DRM -> Direct Rendering Manager, not DRM -> Digital Rights Management :-) | 12:20 |
| stekern | rah: heh, ok. either way, your explanation of what you need to do was incorrect. the chip has 3 interfaces, vga <- vga/lcd core (with no changes needed), i2c control interface <- i2c core (with no changes needed) and i2s audio <- I wrote a I2S core the day before yesterday | 13:08 |
| rah | stekern: how do you know no changes are needed over i2c? | 13:14 |
| rah | stekern: I presumed the chip would need to be configured first | 13:14 |
| stekern | I presume that's what the driver you linked to does (but I didn't check closer) | 13:15 |
| rah | it does use i2c, which according to the block diagram is connected to "registers and configuration logic" | 13:16 |
| rah | hang on now I'm confused | 13:32 |
| rah | you said "i2c control interface <- i2c core (with no changes needed)" | 13:32 |
| rah | stekern: did you mean no changes were needed to existing code, or no configuration changes were needed to the hardware to make it work? | 13:33 |
| stekern | I meant no changes at hardware level | 13:38 |
| rah | I see | 13:47 |
| stekern | but I agree with your main point, the cyclone v gts board is unchartered water, you'd be the first one with that board and on your own (at least until someone else comes along with that board) | 14:13 |
| stekern | if someone sposnored me with that board I'd be happy to do the work ;) | 14:14 |
| olofk | Time for weekend! | 14:20 |
| stekern | well, not completely on your own of course, we'd be here cheering and patting you on the back, and being picky asses about your patches ;) | 14:21 |
| gautschi | hi everyone | 14:28 |
| gautschi | julius: i have a few questions regarding the gcc regression tests | 14:29 |
| gautschi | I'm the one who was doing the modification on the or1200 which were presented by davide last week | 14:29 |
| rah | stekern: hah! :-) | 14:33 |
| olof | Crap! Turns out it's only thursday today :( | 16:51 |
| poke53281 | I got competition: http://copy.sh/v24/ | 22:23 |
| --- Log closed Fri Oct 18 00:00:44 2013 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!
