| --- Log opened Wed Oct 16 00:00:41 2013 | ||
| poke53281 | stekern: Can you take a look at this patch for QEMU http://pastie.org/8405366 | 02:07 |
|---|---|---|
| poke53281 | It speeds up QEMU by a factor of two | 02:07 |
| stekern | poke53281: ah, makes sense | 03:42 |
| stekern | I can assume that happens a lot, copy one register to another | 03:43 |
| stekern | nice finding | 03:44 |
| poke53281 | http://pastie.org/8405496 | 03:44 |
| poke53281 | I have expanded the patch a little bit for movi instructions. | 03:44 |
| poke53281 | nbench is running at the moment | 03:44 |
| poke53281 | Let's see | 03:44 |
| poke53281 | If you are Ok with the patch I will send it to the mailing list | 03:45 |
| poke53281 | I get strange readings on the nbench results with the new patch right now. Maybe I went to far. Let's see. | 03:46 |
| stekern | I'm not the qemu maintainer, so you don't need me review your qemu patches before sending them ;) | 03:50 |
| poke53281 | Uhmm, the ASSIGNMENT is now 0.2 instead of 2.67 | 03:51 |
| stekern | but I think they make sense | 03:51 |
| poke53281 | Four eyes are better then two eyes. | 03:52 |
| stekern | true | 03:53 |
| stekern | is that odd linebreak after else and before if some qemu coding style thing? | 03:54 |
| poke53281 | no, this is poke53281 style :) | 03:54 |
| poke53281 | and it is not odd | 03:54 |
| stekern | hehe, ok, might wanna fix that before sending though | 03:55 |
| stekern | I've never seen it before ;) | 03:55 |
| stekern | I'm not so sure about the l.ori optimisation, might be possible that the ifs becomes more costly than the actual operation there | 03:56 |
| poke53281 | And now the ASSIGNMENT jumps to 2.46 after a second run. No change. What the hell is nbench doing here | 03:56 |
| poke53281 | It seems that not everything is translated. Only loops and so on. | 03:57 |
| poke53281 | So I am not sure. | 03:58 |
| poke53281 | I think the main profit you gain from the l.addi change. | 03:58 |
| stekern | yeah, I think so too | 03:58 |
| poke53281 | All my other changes seem to have almost no effect. | 03:59 |
| poke53281 | But I have also seen that i386 translates much more to machine code than openrisc. | 04:00 |
| poke53281 | stekern: Is it allowed to change r0 by software? | 04:26 |
| poke53281 | The specifications seems to say yes here. | 04:27 |
| poke53281 | So my first patch is fine. | 04:32 |
| hansfbaier | stekern: isn't r0 supposed to be always constant zero, or am I mixing it up with ARM.... | 04:51 |
| hansfbaier | sorccy, poke53281 ^ | 04:51 |
| hansfbaier | s/sorccy/sorry/ | 04:51 |
| stekern | poke53281: ah, you bring up the the good ol' r0 | 05:05 |
| stekern | we have discussed that a lot and I think the consensus have been (and what the spec now says) that it's implementation specific whether r0 is hardwired to 0 or implemented as a "normal" register | 05:07 |
| poke53281 | Can you interpret chapter 4.4 for me. For me it is definitely free. | 05:08 |
| stekern | writing to r0 is allowed in the sense that it should not have any side-effects | 05:09 |
| stekern | i.e. it should either write the value to r0 or it could be a nop | 05:09 |
| stekern | so qemu as an implementation is free to allow software to write values to r0 | 05:10 |
| poke53281 | specification says: "R0 should | 05:12 |
| poke53281 | always hold a zero value. It is the responsibility of software to initialize | 05:12 |
| poke53281 | it" | 05:12 |
| poke53281 | If this is not hardwired than I have two ways to get root rights as a user now. | 05:13 |
| stekern | possible, but that's an sw issue | 05:15 |
| poke53281 | After the initialization it is hardwired. Am I correct? | 05:16 |
| stekern | no | 05:16 |
| stekern | it can be hardwired or just a normal register | 05:16 |
| stekern | in mor1kx and or1200, it's just a normal register | 05:17 |
| poke53281 | Ok | 05:18 |
| hansfbaier | stekern: why so? Rationale? | 05:19 |
| poke53281 | Also in QEMU it is a normal register. In jor1k too. But most of the time because of performance reasons, | 05:19 |
| stekern | hansfbaier: because the registers are implemented as a ram, so giving r0 special treatment would just require extra logic | 05:19 |
| poke53281 | Neither the Linux kernel entry nor gcc set this value. The whole toolchain assumes that it is hardwired. | 05:20 |
| hansfbaier | stekern: no flipflops? | 05:20 |
| poke53281 | Also syscal | 05:20 |
| poke53281 | Also syscall does not set r0 | 05:20 |
| hansfbaier | what would happen if a user program modified it? Couldn't that upset everything? | 05:21 |
| poke53281 | YES | 05:21 |
| stekern | poke53281: gcc of course doesn't set it, it's the job of the startup code to do that, and newlib/libgloss do set it | 05:21 |
| poke53281 | And this very fast I suppose. | 05:21 |
| stekern | https://lkml.org/lkml/2012/3/5/438 | 05:22 |
| stekern | did that ever get applied (apart from the obvious delay-slot misunderstand change)? | 05:23 |
| stekern | so, yes, there might be bugs in the kernel that makes writing to r0 exploitable | 05:23 |
| poke53281 | This is the first time I am seeing this patch | 05:27 |
| poke53281 | This patch makes sense | 05:28 |
| stekern | there wasn't any follow-up on Jonas comments on it, I guess that's why it never got applied | 05:29 |
| hansfbaier | Let's hope the OpenRISC based satellite doesn't run Linux :) | 05:36 |
| hansfbaier | stekern: Can you give me the dts for your de0_nano kernel? | 05:38 |
| hansfbaier | stekern: If I compile my own based on jonas' master, I'll get a crash on boot | 05:39 |
| hansfbaier | stekern: But I still use the or32-linux toolchain for that | 05:39 |
| poke53281 | Well, it's not so bad. As long as they don't give user rights on this satellite to me nothing can happen ;) | 05:39 |
| hansfbaier | poke53281: Yes, but cosmic radiation possibly doesn't ask for user rights ... | 05:40 |
| poke53281 | Yes, there are nice stories about cosmic radiation and ECC memory. | 05:42 |
| poke53281 | Companies who have bought the same device one manufacturer and complain about, why their system show so much more corrected errors in their ECC log. | 05:43 |
| mor1kx | [mor1kx] skristiansson pushed 1 new commit to master: https://github.com/openrisc/mor1kx/commit/78b7a884c15f133b67fa962fd8fd5edb9f187b1a | 05:44 |
| mor1kx | mor1kx/master 78b7a88 Stefan Kristiansson: bus_if_avalon: remove vector size from OPTION_AVALON_BURST_LENGTH... | 05:44 |
| poke53281 | The reason is, that one company has its server farms a few hundred meters higher than the other one. | 05:44 |
| stekern | hansfbaier: it doesn't work with the orpsocv2-de0_nano dts, because orpsocv3-de0_nano doesn't have spi | 05:45 |
| stekern | nor i2c | 05:45 |
| stekern | yet | 05:45 |
| olofk | I see that the never ending r0 story is revived :) | 05:47 |
| stekern | hansfbaier: I don't see how cosmic radiation is related to the r0 exploitability though | 05:47 |
| stekern | olofk: I added i2c support to orpsoc-cores last night | 05:48 |
| stekern | and wrote a i2s core | 05:49 |
| hansfbaier | stekern: I use this: https://dl.dropboxusercontent.com/u/3377727/de0_nano.dts | 05:49 |
| hansfbaier | But still crashes... | 05:49 |
| stekern | ok, that should work | 05:49 |
| hansfbaier | stekern: OpenCores had an I2S controller that looked quite nice to me | 05:49 |
| olofk | stekern: Cool. I'll look for a pull request soon then | 05:49 |
| hansfbaier | stekern: But it might have been VHDL | 05:49 |
| stekern | hansfbaier: i2s is dead simple, it took me less than an hour to write it yesterday | 05:50 |
| hansfbaier | stekern: Yes, it's nice and tidy | 05:50 |
| olofk | I never truly understood why we couldn't just hardwire r0 to zero. The exploitability was exactly what I was worrying about. | 05:51 |
| hansfbaier | stekern: But with that dts, the kernel still crashes... | 05:51 |
| stekern | https://github.com/skristiansson/i2s/blob/master/rtl/verilog/i2s_tx.v | 05:53 |
| stekern | it became alot cleaner than the ugly implementation that I wrote 4 years ago | 05:54 |
| stekern | maybe one day I'll become a decent rtl hacker... | 05:54 |
| hansfbaier | stekern: Parallel only has one 'l' at the end | 05:58 |
| hansfbaier | http://www.dict.cc/?s=parallel | 05:58 |
| hansfbaier | Sorry, popped into my eye. Collateral damage from writing a lot of docs | 05:58 |
| stekern | yes, you're right, it's my Swedish origin that shines through there... | 06:00 |
| hansfbaier | stekern: A question: Why do you have three always blocks with the same sensitivity list? What is the difference to one block? | 06:00 |
| hansfbaier | Better readability? | 06:01 |
| stekern | yes | 06:04 |
| stekern | if you think about them as hw, they are three different "logic circuits" | 06:06 |
| stekern | a clocked counter with reset, gated flip-flops | 06:11 |
| stekern | you could of course still smack them in a big always block | 06:12 |
| stekern | matter of taste, I guess... | 06:13 |
| stekern | there's some difference in regard to event driven simulations when you read a signal from a different block, but I can't remember the details of that | 06:14 |
| olofk | Simulators like to have as few processes as possible | 06:15 |
| olofk | But changing what you did in i2s.v because of that would just be bike shedding at it's finest | 06:16 |
| hansfbaier | stekern: How would I debug this, any idea: http://pastie.org/8405706 | 06:27 |
| stekern | hansfbaier: oooh, sorry.... now I know... | 06:29 |
| stekern | I completely forgot about that | 06:29 |
| stekern | http://pastie.org/8405712 | 06:30 |
| hansfbaier | stekern: It works! Amazing. How did you find that out from the trace? | 06:35 |
| hansfbaier | bio: create slab <bio-0> at 0 | 06:35 |
| hansfbaier | XGpio: /gpio@91000000: registered | 06:35 |
| hansfbaier | Ah I see, that's just when the gpio was initialized. | 06:35 |
| stekern | olofk: we could hardwire r0, but it doesn't remove the problem in the kernel | 06:35 |
| stekern | hansfbaier: intuition | 06:36 |
| stekern | ;) | 06:36 |
| stekern | nah, I obviously had hit that problem myself earlier | 06:36 |
| stekern | but always when you see a bus error on some 0xbc000000 address, it's some peripheral access that have failed | 06:40 |
| hansfbaier | stekern: good to know, thanks. | 06:50 |
| Powermaniac | Howdy | 07:43 |
| Powermaniac | Interesting news, I visited UniSA today. And well they seem to think what you guys have done is impossible... | 07:43 |
| Powermaniac | In a sense that is what they said... | 07:43 |
| Powermaniac | More they said for one person to do what you have done would be impossible. | 07:44 |
| Powermaniac | But on a related note I was wondering how much has been implemented on the ORPSoCv3 as in how much in the way of peripheral devices running through it has it got working/running already? | 07:44 |
| Powermaniac | But yeah it was more they thought my idea, making an entirely open source computer, wasn't really possible | 07:52 |
| Powermaniac | Or well I just don't have enough time according to them to learn everything and get up to scratch before even going to uni. | 07:52 |
| stekern | well, we're not one person, and the openrisc project have been going on for over ten years | 07:53 |
| Powermaniac | Yeah I know the OpenCores/OpenRISC team isn't one person | 07:53 |
| Powermaniac | They seem to not be up to date with how much progress you guys have made | 07:53 |
| Powermaniac | Which I was surprised about | 07:53 |
| Powermaniac | But I didn't try and ram it home that you have basically done what I wish to already for me. | 07:53 |
| Powermaniac | Well not for me exactly , but you get what I mean | 07:54 |
| stekern | did they know about the project at all? | 07:58 |
| Powermaniac | Yeah one of the guys knew about the project | 07:58 |
| Powermaniac | But he said he knew about it from a fair while ago | 07:59 |
| Powermaniac | They seemed surprised that I had learnt so much since I first emailed them like 3 weeks back. All thanks to you guys | 08:03 |
| Powermaniac | Note both of them were professors at UniSA | 08:06 |
| hansfbaier | stekern: ping, does this arrive? | 08:39 |
| stekern | hansfbaier: pong | 08:41 |
| hansfbaier | stekern: Thanks, I get those annoying messages that I have been banned because my IP address is on dronebl.org | 08:42 |
| hansfbaier | stekern: Banned: Open proxy or TOR (auto-detected dnsbl.dronebl.org; hansfbaier!~jack) (2013/10/16 10.29) | 08:42 |
| hansfbaier | stekern: But obviously irc still works. Maybe got the wrong dynamic IP address | 08:42 |
| hansfbaier | stekern: anyway, orpsocv3 on de0_nano seems to be pretty anaemic still, no i2c/spi, etc, etc.... | 08:44 |
| hansfbaier | stekern: also, wouldn't it be a nice idea to put the serial on one of the top headers by default... I could do the changes and fork the repo if you like.... | 08:46 |
| stekern | the changes are already done in julius repo | 08:49 |
| stekern | what's wrong with the one in the bottom? | 08:50 |
| stekern | most breakoutboards seemed to use the top headers, that's why I choose that | 08:50 |
| hansfbaier | stekern: I can't put the nano flat on the table... | 08:50 |
| hansfbaier | stekern: I see. | 08:51 |
| hansfbaier | stekern: And I don't have a 13 pin header cable... | 08:51 |
| hansfbaier | stekern: What would you recommend, using julius' repo for de0_nano and yours for sockit? | 08:52 |
| stekern | no, use opencores/orpsoc-cores | 08:52 |
| stekern | err openrisc/orpsoc-cores | 08:52 |
| hansfbaier | https://github.com/openrisc/ | 08:52 |
| stekern | julius was for the workshop | 08:53 |
| hansfbaier | ok | 08:53 |
| stekern | and sockit should be added there as well | 08:54 |
| hansfbaier | stekern: So I could discontinue using your repo in the tutorial too? | 08:54 |
| hansfbaier | stekern: I can't see sockit in there, yet. | 08:54 |
| hansfbaier | so no. | 08:54 |
| stekern | not yet | 08:55 |
| hansfbaier | stekern: de0_nano has no spi/i2c there yet, too. | 08:57 |
| stekern | no | 08:57 |
| stekern | feel free to add them as an exercise | 08:57 |
| hansfbaier | stekern: Yes, I'd love to. | 08:58 |
| stekern | I'll send out the i2c.core addition right away to give you a bit of help with that ;) | 09:00 |
| hansfbaier | stekern: Where should I fetch the cores from, opencores directly, or are there more up to date versions somewhere on openrisc.net? | 09:00 |
| stekern | there are no cores on openrisc.net | 09:03 |
| hansfbaier | stekern: but in your github for example | 09:03 |
| stekern | the SPI core used in orpsocv2 was from opencores | 09:04 |
| stekern | but with a lot of changes | 09:04 |
| stekern | or some changes, I haven't checked how much | 09:04 |
| hansfbaier | stekern: What would be best there? Use opencores and supply patch? | 09:04 |
| hansfbaier | stekern: upstreaming? | 09:05 |
| stekern | so, what you need to do is do a diff between the SPI core from opencores and the one in orpsocv2 and generate patches for the differences (that makes sense) | 09:05 |
| hansfbaier | stekern: or directly use orpsocv2 as a repo. Would be kind-of-upgly for orpsoc3 to depend on v2... | 09:05 |
| hansfbaier | stekern: OK. | 09:05 |
| stekern | using orpsocv2 as a repo would be a nono ;) | 09:06 |
| stekern | you can look at the vga_lcd core for an example | 09:07 |
| hansfbaier | stekern: or jtag_tap.core? | 09:09 |
| hansfbaier | or uart 16550...? | 09:09 |
| hansfbaier | I'll use the uart | 09:09 |
| hansfbaier | stekern: OK got it. | 09:10 |
| stekern | sure... | 09:10 |
| stekern | personally, I prefer git formatted patches | 09:11 |
| stekern | but olofk seems to like diff style patches too | 09:11 |
| stekern | so I guess it's up to you to choose which style to choose | 09:12 |
| hansfbaier | stekern: Can I build a single core, or do I have to include it into a system first, before it checks the core out from svn? (The latter I suppose...) | 09:21 |
| stekern | depends | 09:22 |
| stekern | what do you mean by "build" | 09:22 |
| stekern | I don't think you can just fetch it, if that's what you mean | 09:23 |
| stekern | olofk, fill in... | 09:23 |
| hansfbaier | stekern: Ah, fetch is not yet in the command line description? | 09:24 |
| stekern | I don't know | 09:24 |
| stekern | use the source, warrior! | 09:24 |
| stekern | ;) | 09:24 |
| stekern | I would like to have a seperate prepare command | 09:25 |
| stekern | that populates the build/src directory | 09:26 |
| hansfbaier | stekern: Any rules for commit messages? | 09:29 |
| hansfbaier | stekern: make them look similar like the others, I suppose... | 09:29 |
| stekern | make them good ;) | 09:32 |
| stekern | olofk: didn't you apply this? https://github.com/skristiansson/orpsoc-cores/commit/3fd3faa9c74deeb378888a00edb10f37c626ce28 | 09:32 |
| stekern | hansfbaier: i2c: https://github.com/openrisc/orpsoc-cores/pull/19 | 09:37 |
| hansfbaier | stekern: Hey, I was about to do that. | 09:38 |
| hansfbaier | stekern: http://pastie.org/8405998 | 09:39 |
| stekern | 08:48 < stekern> olofk: I added i2c support to orpsoc-cores last night | 09:39 |
| hansfbaier | stekern: So I'll go straight to SPI? | 09:40 |
| hansfbaier | and forget about i2c? | 09:40 |
| stekern | 12:00 < stekern> I'll send out the i2c.core addition right away to give you a bit of help with that ;) | 09:40 |
| hansfbaier | stekern: why revision 74 instead of 76? | 09:40 |
| stekern | yes, hop-on SPI straight away | 09:40 |
| stekern | umm, typo perhaps? | 09:41 |
| stekern | lemme check | 09:41 |
| hansfbaier | stekern: 76 seems to be latest... | 09:42 |
| stekern | ah... I was in rtl/verilog when I checked the revision, 74 is the latest change there | 09:42 |
| stekern | so 74 or 76, doesn't matter | 09:43 |
| hansfbaier | stekern: should I base SPI on latest? | 09:43 |
| stekern | I suppose | 09:43 |
| hansfbaier | ok | 09:44 |
| hansfbaier | stekern: diff ok like this? http://pastie.org/8406027 | 09:54 |
| hansfbaier | stekern: I probably should remove the a/ b/ paths, right? | 09:55 |
| stekern | ask olofk, as I said *I* prefer git formatted patches | 09:55 |
| stekern | ...as in the vga_lcd core | 09:55 |
| hansfbaier | olofk: ^ | 09:56 |
| hansfbaier | stekern: Or I just commit and send him a pull request... | 09:56 |
| stekern | https://github.com/openrisc/orpsoc-cores/blob/master/cores/vga_lcd/patches/0002-autoresync-on-fifo-underruns.patch | 09:57 |
| stekern | because, there, the commit messages are preserved | 09:57 |
| hansfbaier | stekern: So I should try to get the orig commit from orpsocv2 instead of diffing myself. | 09:57 |
| stekern | that might be hard... but, if you can pinpoint, it probably doesn't hurt to make a comment about it in the commit message | 09:58 |
| hansfbaier | stekern: But the diffs look totally different than the diffs to current. | 09:59 |
| stekern | ?? | 10:00 |
| hansfbaier | stekern: http://pastie.org/8406043 | 10:01 |
| hansfbaier | stekern: You still leave me seriously confused as to where I should get the git diff. | 10:02 |
| hansfbaier | stekern: http://pastie.org/8406047 | 10:03 |
| stekern | yes, hence the "that might be hard...." | 10:03 |
| hansfbaier | stekern: maybe the diff from orpsocv2 was based on a different revision.... | 10:04 |
| hansfbaier | stekern: and the first diff looks much prettier | 10:04 |
| hansfbaier | so... | 10:04 |
| hansfbaier | I would tend to take the first one | 10:04 |
| hansfbaier | stekern: I got the second with git log -p *.v | 10:05 |
| hansfbaier | stekern: that should get me the history on those files | 10:05 |
| stekern | what I meant was that: break the diffs out like in the diff you pasted first, if you use git format patch to produce it, add a note in the commit message: "this was taken from a big code dump commit to orpsocv2" | 10:05 |
| stekern | or something like that | 10:05 |
| stekern | just to note where the change origined from | 10:05 |
| stekern | just my opinion | 10:06 |
| hansfbaier | stekern: Ah, I get it. | 10:06 |
| Powermaniac | Is the ORPSoCv3 also available in VHDL? | 10:10 |
| Powermaniac | As UniSA only teaches VHDL not Verilog... | 10:10 |
| hansfbaier | Powermaniac: No, you can't get good open source tools for VHDL. | 10:11 |
| Powermaniac | Ahh okay | 10:11 |
| Powermaniac | Verilog it is then... | 10:11 |
| hansfbaier | Powermaniac: So the open source scene seems to mainly zoom in to verilog | 10:11 |
| hansfbaier | Powermaniac: icarus verilog and verilator rule | 10:11 |
| Powermaniac | ! | 10:11 |
| hansfbaier | Powermaniac: icarus has recently been added support for synthesizable VHDL too | 10:12 |
| hansfbaier | Powermaniac: good news | 10:12 |
| Powermaniac | Maybe you might find this interesting, hansfbaier. I was told today by two professors that what I wish to do isn't really possible for one person...See they didn't seem to realise you guys have sort of done most the work for me | 10:12 |
| Powermaniac | The idea of making a fully open source computer | 10:12 |
| hansfbaier | stekern: Sorry to bother you again, the top file has been renamed in orpsoc, how would I handle that? | 10:12 |
| hansfbaier | Powermaniac: Tell the profs the open source community isn't one person and whether they heard of opencores.org | 10:13 |
| Powermaniac | hansfbaier: I've forgotten again, sorry. But how did you learn verilof? | 10:13 |
| Powermaniac | verilog* | 10:13 |
| hansfbaier | Powermaniac: different sources | 10:13 |
| Powermaniac | Oh okay | 10:14 |
| Powermaniac | Any of them in English? | 10:14 |
| stekern | hansfbaier: *shrug*, the same change was in i2c, I didn't bother to create a diff for that | 10:14 |
| Powermaniac | hansfbaier: Oh and I told them about opencores and openrisc. And one of them knew about it but from a fair while ago it seems and they didn't seem to realise how much you have already all done. | 10:15 |
| stekern | it's a bit ugly with the _top when instantiating the cores, but other than that, it does no harm. | 10:15 |
| Powermaniac | So can someone enlighten me on how much is actually implemented on the ORPSoCv3 to connect periphereals that are open source themselves and prat of OpenCores? | 10:16 |
| stekern | veriolofk | 10:16 |
| hansfbaier | Powermaniac: https://www.dropbox.com/sh/uzoicx1pel52b38/iIXS14pxSS | 10:16 |
| Powermaniac | hansfbaier: Oh thank you. | 10:17 |
| hansfbaier | Powermaniac: got those on the web | 10:17 |
| hansfbaier | google is your friend :) | 10:17 |
| hansfbaier | Powermaniac: the .core files in orpsoc-cores/cores | 10:18 |
| stekern | Powermaniac: VHDL and verilog isn't that different in the end, digital design is more about "thinking the right way" anyway, language choice is just a matter of syntax | 10:19 |
| Powermaniac | stekern: Oh okay | 10:19 |
| stekern | there's a few gotchas and things you can't do in VHDL and vice vers, but apart from that most constructs are directly translatable | 10:21 |
| stekern | especially on novice level | 10:21 |
| hansfbaier | stekern: So should I let the _top be, but How do I tell orpsoc if to rename? | 10:21 |
| Powermaniac | So is there a hdmi connection, ethernet (I assume there is ethernet because aren't you using ethernet with the ORPSoCv3 on one of your FPGA boards?), usb (Also asume it has this), all compatible and running on the ORPSoCv3> | 10:22 |
| stekern | hansfbaier: tell orpsoc what? | 10:22 |
| Powermaniac | you* being stekern* | 10:22 |
| hansfbaier | stekern: to rename the simple_spi_top.v -> simple_spi.v | 10:22 |
| Powermaniac | hansfbaier: Are these the cores you were talking about: https://github.com/openrisc/orpsoc-cores/tree/master/cores | 10:22 |
| hansfbaier | Powermaniac: yes | 10:23 |
| hansfbaier | There you find the reference where each one is from | 10:23 |
| stekern | hansfbaier: you either remove the _top or you don't | 10:24 |
| stekern | I don't understand the problem | 10:24 |
| hansfbaier | stekern: Like this maybe? http://pastie.org/8406086 | 10:27 |
| stekern | that looks ugly, what are you trying to show? | 10:28 |
| stekern | sorry for being dense... | 10:29 |
| hansfbaier | stekern: in the svn checkout the file is named simple_spi_top.v, in orpsocv2 it's named simple_spi.v | 10:30 |
| hansfbaier | stekern: Yes the diff looks ugly, but i didn't do it ..... 8-P | 10:30 |
| stekern | yes... | 10:30 |
| stekern | you don't need to make it *exactly* look like orpsocv2 | 10:31 |
| hansfbaier | stekern: Will orpsoc rename it after it is checked out, if the diff looks like this? | 10:31 |
| hansfbaier | stekern: So it's okay, if still named simple_spi_top.v ? | 10:31 |
| stekern | there might be stuff there that we *don't* want to move into orpsocv3 | 10:32 |
| stekern | I say it's ok if it's still named simple_spi_top.v | 10:32 |
| stekern | IMO, we should only create patches that are really needed | 10:33 |
| hansfbaier | stekern: But the diff looks bad in another way: It seems to throw away new / cleaner functionality | 10:33 |
| hansfbaier | stekern: Ok, just the orig, and patch if things blow up? Would be much cleaner | 10:33 |
| hansfbaier | stekern: I dont like the patch on _top | 10:33 |
| hansfbaier | stekern: and the #1 annotations don't hurt too, since they are just ignored by the synthesizer.... | 10:34 |
| Powermaniac | Well I'm need to disappear. So goodnight everyone! | 10:35 |
| hansfbaier | stekern: Should I fork orpsoc-cores and send pull requests? | 10:39 |
| hansfbaier | stekern: or just send patches? | 10:39 |
| stekern | I think olofk likes pull requests | 10:40 |
| hansfbaier | stekern: ok | 10:40 |
| nvmind | hello. | 10:41 |
| hansfbaier | nvmind: Please notify me when you are done with your thesis. I'm interested | 10:43 |
| hansfbaier | nvmind: Or if I can help | 10:43 |
| nvmind | :) | 10:47 |
| nvmind | btw I found out why I wasn't able to connect to the jtag on board :) | 10:48 |
| nvmind | I made another silly mistake | 10:48 |
| stekern | in hindsight most mistakes are silly ;) | 10:49 |
| nvmind | I was exposing a positive reset signal that was attached to a normally high button :) | 10:49 |
| hansfbaier | nvmind: You will get a very stable system.... :) | 10:51 |
| stekern | I wonder how many hours have been wasted on reset polarity problems... | 10:51 |
| nvmind | ahuauhah | 10:51 |
| nvmind | In my case? A couple of weeks | 10:51 |
| nvmind | but that give me the time to move to openocd | 10:52 |
| stekern | I've certainly have a fair amount of hours on that account as well | 10:52 |
| hansfbaier | stekern: https://github.com/openrisc/orpsoc-cores/pull/20 | 10:56 |
| hansfbaier | stekern: for a humble start | 10:56 |
| hansfbaier | olofk: ^ | 10:57 |
| hansfbaier | stekern: I'll care about diffs tomorrow. | 10:57 |
| hansfbaier | stekern: with a fresh mind. | 10:57 |
| stekern | fair enough ;) | 11:01 |
| _franck_ | nvmind: great to hear it works now | 11:45 |
| nvmind | _franck_: :) | 15:09 |
| rah | stekern: is the ethernet controller core in your atlys image "encumbered"? | 15:46 |
| rah | stekern: is it restricted by an NDA from Marvell? | 15:49 |
| juliusb | rah: what model is it? there's some *8811* one which always was under NDA, annoyingly | 16:05 |
| juliusb | 88E1111? | 16:06 |
| rah | 88E1111) | 16:08 |
| rah | yes | 16:08 |
| rah | s/)// | 16:08 |
| rah | juliusb: my question is about the core though | 16:08 |
| juliusb | oh you mean the ethernet MAC RTL? | 16:09 |
| rah | juliusb: I'm concerned about whether the core has been developed under NDA, which I presume would mean it could not be licensed freely | 16:09 |
| juliusb | is it an encrypted netlist or something? or encumbered because it's poorly written? | 16:09 |
| juliusb | oh, if it's the OpenCores one, then no, it's under the LGPL, so intended to be freely used and available | 16:09 |
| rah | juliusb: there's a misunderstanding | 16:10 |
| rah | juliusb: I'm asking what core is used | 16:10 |
| rah | juliusb: I don't know whether it's an OpenCores core, I'm asking whether it is | 16:11 |
| juliusb | highly likely it is | 16:45 |
| stekern | rah: the MAC core that is used is the ethmac core from opencores | 16:51 |
| stekern | you are speaking about the PHY, which is an external chip | 16:51 |
| rah | stekern: no, the MAC core | 16:52 |
| rah | stekern: from http://stromeko.net/FPGA/DevBoard2.html : | 16:53 |
| rah | "The tri-mode Ethernet physical requires the EDK, so you can't use it directly with WebPack. Additionally, Marvell in their infinite wisdom don't let you read their data sheet until you sign an NDA. There are various efforts underway to get ethernet working without using encumbered cores or datasheets, but so far I've not checked any of them." | 16:53 |
| stekern | the only thing that is under NDA is the datasheet for the marvell PHY | 16:54 |
| stekern | regardless of what you think you read out of that page | 16:55 |
| stekern | the "encumbered" ethernet MACs he is speaking about is Xilinx MAC core, which is not under NDA, but you need(ed) a ISE license to be able to use it | 16:59 |
| stekern | but, we are not using that, we are using the LGPL opencores MAC | 17:00 |
| rah | stekern: I'm glad to hear you're usnig an LGPL core | 19:03 |
| rah | stekern: my concern though was that the core in the image might have been non-free because the NDA prohibited distributing source for cores developed using the information that was disclosed in the datasheet | 19:05 |
| rah | s/usnig/using/ | 19:06 |
| ams | rah: an nda isn't a copyright license, if you violate the nda you violate the nda, not the copyright license. | 19:23 |
| ams | which is why it is perfecly legal for companies to develop GPL software, but prohibiting their employees from distributing the changes. | 19:25 |
| rah | ams: an nda is just an agreement, it can mean pretty much anything | 19:27 |
| ams | rah: no, not really. | 19:27 |
| rah | ams: and "pretty much anything" includes agreements not to freely license copyrighted works created using disclosed information | 19:27 |
| rah | lol | 19:28 |
| hansfbaier | stekern: I merged the changes from orpsocv2 into svn revision 10. Would you please review: https://github.com/hansfbaier/orpsoc-cores/commit/793c738057369736b1a29ae3e126bba2c51671ce | 19:28 |
| hansfbaier | stekern: first timit RTL hacking... | 19:28 |
| hansfbaier | stekern: I also wonder why it says if (~spe | rst_i) and not if (~spe | ~rst_i) in the code since rst_i is active low, but I didn't want to change the semantics of the old code if it works | 19:29 |
| stekern | rah: I guess it's time for some ethernet 101... An ethernet solution consists of a MAC and a PHY, those are connected via an MII interface. the MII interface consists of two parts, the actual data exchange and a management interface | 19:29 |
| stekern | both are standard protocols | 19:30 |
| rah | stekern: I know | 19:30 |
| hansfbaier | stekern: Note: git patch format :) | 19:30 |
| stekern | the management interface consist of a set of registers, which of some are standardized | 19:30 |
| stekern | the marvell NDA covers a set of registers not covered by the standard | 19:31 |
| stekern | the MAC doesn't need to know *anything* about the registers in the management interface, it just have to present a mean to access them | 19:32 |
| stekern | thus, a MAC implementation have nothing to do with the marvell NDA | 19:33 |
| rah | I see | 19:33 |
| rah | to what does the MAC present a means to access the registers, the driver? | 19:33 |
| stekern | yes | 19:34 |
| rah | I see | 19:34 |
| * hansfbaier -> bed | 19:34 | |
| rfajardo | hello there, have anyone seen this lately? | 20:21 |
| rfajardo | *** Missing UAPI file /Users/Raul/development/or1k/linux/include/uapi/linux/netfilter/xt_CONNMARK.h. Stop. | 20:21 |
| rfajardo | by installing the Linux headers? | 20:22 |
| rfajardo | It seems it wasn't there because my connection dropped when cloning… | 21:03 |
| --- Log closed Thu Oct 17 00:00:43 2013 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!