| GentlemanEnginee | Hello. | 04:44 |
|---|---|---|
| glowplug | Hello. =) | 04:53 |
| glowplug | I've made some progress today in my search for a cheap FPGA. | 04:59 |
| GentlemanEnginee | What manners of treasures have you located? | 05:01 |
| glowplug | I got some help with the LE requirement of ORPSoc. It is around 11k LE's in terms of Altera Cyclone III / IV / V. | 05:03 |
| GentlemanEnginee | Do you have any concept on what that would translate in terms of Xilinx offerings? | 05:04 |
| GentlemanEnginee | Also, do you have any inkling on how that figure was arrived upon? | 05:04 |
| GentlemanEnginee | Also, that would indicate that your 15k Altera Development Board should qualify. | 05:05 |
| glowplug | Stefan posted his synthesis report for the Altera Nano board. The 15k board would, unfortunately the $32 10k board will only work when ORPSoc slims down. | 05:06 |
| glowplug | Then I discovered something even more interesting. | 05:06 |
| GentlemanEnginee | The difference in cost was ~$15, if memory serves me... | 05:06 |
| GentlemanEnginee | What? | 05:06 |
| stekern | glowplug: there are several sdram controllers floating around, which are you referring to? | 05:07 |
| stekern | (I've written one of them) | 05:07 |
| GentlemanEnginee | ??? | 05:08 |
| glowplug | You wrote a memory controller. Haha | 05:08 |
| glowplug | You guys are seriously insane. O_O | 05:08 |
| glowplug | The controller implimented in ORPSoc is a synchronous SDRAM controller that interfaces with LVTTL correct? | 05:08 |
| stekern | writing a memory controller isn't actually that hard, making it fast however, is ;) | 05:09 |
| GentlemanEnginee | I can imagine the optimization techniques would be rather advanced... | 05:09 |
| stekern | I think I semisucceded to make mine pretty fast, but it's relatively big | 05:10 |
| GentlemanEnginee | How large? | 05:10 |
| glowplug | The reason I ask is that I have managed to track down a free software kicad schematic for a BGA Spartan-6 module board. It utilizes a single 512mb DDR chip which I assume interfaces with CMOS and not LVTTL. | 05:11 |
| glowplug | http://numato.cc/taxonomy/term/17 | 05:11 |
| glowplug | The cost to assemble such a board could easily be less than $30 with 15k LE's. | 05:12 |
| glowplug | And 512MB of DDR. | 05:12 |
| GentlemanEnginee | In what quantities? | 05:12 |
| glowplug | From what I understand only single 256MB LVTTL SDRAM modules are supported by the existing memory controller in ORPSoc? | 05:13 |
| stekern | GentlemanEnginee: my fitter report in quartus says 1.8k LE | 05:13 |
| glowplug | In a single quantity in terms of components (such as RAM chips and the FPGA itself). The board cost really depends. | 05:13 |
| GentlemanEnginee | Is that number included in the 11k estimate? | 05:13 |
| stekern | glowplug: the SDRAM controller I wrote only handles single rate sdrams | 05:14 |
| stekern | probably possible to extend it to handle ddr as well, but you might be better off using another | 05:14 |
| GentlemanEnginee | So, your cost estimate is for a single board. Price would fall with quantity. | 05:15 |
| glowplug | The 11k estimate is for the entire ORPSoc SoC minus ethernet if I remember. | 05:15 |
| GentlemanEnginee | Ah! | 05:15 |
| GentlemanEnginee | What is the Ethernet requirement? | 05:15 |
| glowplug | Unfortunately I can't easily determine cost in quantity because Digikey only gives single unit pricing. | 05:15 |
| GentlemanEnginee | Digikey is rarely the most cost effective supplier. | 05:16 |
| stekern | the milkymist project is however using DDR, and they have a memory controller you can "steal" | 05:16 |
| glowplug | I can say that it is fairly likely that at 1,000 units we could have ORPSoc boards for sub $20 each. Doesn't seem unrealistic. | 05:16 |
| stekern | https://github.com/milkymist | 05:16 |
| GentlemanEnginee | Newark does have both quantity pricing and paramatarized searching. | 05:16 |
| glowplug | I saw milkymist mentioned on the opencore site. I suppose it was a mailing list log? I think you might have posted actually. Haha | 05:17 |
| glowplug | At the link I posted if you dig in there is an SVN repo with a zip containing everything for the board. Schematic, layout, even component library and BoM. | 05:18 |
| stekern | I'm not involved in that project, more than an interested bystander | 05:18 |
| GentlemanEnginee | Is the milkymist a superset of ORPSoc? | 05:18 |
| stekern | no, it is a completely different project | 05:19 |
| glowplug | And even more than that, the board has an integrated PIC32 which can program the FPGA and perform other tasks. It is essentially a perfect platform. | 05:19 |
| GentlemanEnginee | Ah yes, the PIC. | 05:19 |
| GentlemanEnginee | I remember that from my undergrad days... | 05:19 |
| stekern | orpsoc (at least not with ethernet controller) will not fit on the XC6SLX9 | 05:20 |
| stekern | olofk tried and failed, but perhaps he didn't try hard enough though ;) | 05:20 |
| glowplug | You are correct. It has only 9k LE's available. | 05:20 |
| GentlemanEnginee | So, the Ethernet Controller is rather resource intensive? | 05:21 |
| glowplug | However there is a Spartan-6 chip with the exact same package that has 15k LE's and is only marginally more expensive. | 05:21 |
| glowplug | http://bit.ly/Wdb5xP | 05:21 |
| glowplug | The Numato board could be used with the slightly larger Spartan 6 chip and there would be plenty of space. | 05:21 |
| stekern | XC6LX16 will work | 05:21 |
| stekern | juliusb has this board: http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,400,897&Prod=NEXYS3 | 05:22 |
| glowplug | I found the chip again. Should have bookmarked it. | 05:23 |
| glowplug | http://www.digikey.com/product-detail/en/XC6SLX16-2CSG225C/122-1670-ND/2408280 | 05:23 |
| glowplug | That chip is a 225 BGA exactly the same as the Numato board. Except with 14579 LE's | 05:24 |
| stekern | woho! fetch bug is successfully squashed! | 05:24 |
| glowplug | Gentleman: You are right that Newark has volume pricing. Unfortunately they have double the per chip cost of Digikey. =( | 05:26 |
| glowplug | I think the only way to know how cheap these chips are available is to contact Xilinx directly. | 05:27 |
| glowplug | As you can see though. With a kicad board completely done and the XC6SLX16 available for $24 in single quantity. PIC32 is ~$4. 512MB DDR ~$4. The board cost is very low and features greatly exceeding existing boards. | 05:28 |
| glowplug | Most importantly (In my opinion) that the board itself is non-proprietary. | 05:29 |
| GentlemanEnginee | That is always a point in its favour... | 05:29 |
| stekern | what's the PIC32 for (sorry if it already has been mentioned and I missed it) | 05:30 |
| glowplug | I'm pretty sure that it can program the FPGA without the need for a blaster-like device. | 05:30 |
| stekern | glowplug: I agree, it's a plus if the layout is "open" | 05:30 |
| glowplug | As well as proving various peripherals without using LE's. | 05:31 |
| stekern | and a dirt cheap openrisc dev board would be very beneficial | 05:31 |
| GentlemanEnginee | I do like this concept. | 05:32 |
| glowplug | The DDR memory issue is the only major issue I see. | 05:32 |
| GentlemanEnginee | It would likely interest more students, and those living on modest means. | 05:32 |
| glowplug | That and the obvious problem of breaking $24 FPGA's because BGA is very difficult to assemble. | 05:32 |
| GentlemanEnginee | I have seen it done by very experienced engineers in their home. | 05:33 |
| GentlemanEnginee | However, I would not wish to attempt it... | 05:33 |
| GentlemanEnginee | One fellow was using a modified toaster oven his wife no longer wished. | 05:34 |
| stekern | me neither... | 05:34 |
| stekern | I've also heard pizza oven success stories | 05:34 |
| glowplug | The team that designed the board assembled many of them using the toaster oven method. It is possible. They did not disclose how many FPGA's were damaged in the process. | 05:34 |
| GentlemanEnginee | That was my thought. | 05:34 |
| GentlemanEnginee | This fellow had in excess of 90% success rate though... | 05:35 |
| GentlemanEnginee | However, I do doubt that his throughput was high. | 05:35 |
| glowplug | Breaking 1/10 boards doesn't sound too bad. That only adds $3 to the cost of an otherwise $30 board. | 05:36 |
| glowplug | I think more important than throughput (centralized production) is the idea of an individual assembling this board for $30 for their own use. | 05:36 |
| GentlemanEnginee | As I stated, I doubt many would be able to acheive his success rate. | 05:37 |
| glowplug | Although being 6-layer means that the boards themselves need to be ordered unfortunately. | 05:37 |
| stekern | yay, and now my "acutal" de0-nano linux image boots when loaded from spi-flash with u-boot | 05:37 |
| GentlemanEnginee | His position had him overseeing manufacturing of lines for over ten years. | 05:37 |
| stekern | *actual | 05:37 |
| stekern | that it has not done before | 05:37 |
| glowplug | Thats fantastic! U-Boot is a huge step forward. =) | 05:38 |
| GentlemanEnginee | U-Boot is a good step. | 05:38 |
| GentlemanEnginee | We use it at my firm. | 05:38 |
| stekern | oh, we've had u-boot working for more than a year already | 05:38 |
| glowplug | Now we boot Open-WRT on the ORPSoc. 8) | 05:38 |
| GentlemanEnginee | Three cheers for stekern! | 05:38 |
| glowplug | This is your first flash boot then? | 05:38 |
| stekern | openrisc support is even upstreamed | 05:38 |
| stekern | what I'm working on at the moment is adding MMUs to mor1kx (in order to use Linux, you need MMUs) | 05:40 |
| glowplug | I'm digging through the datasheets for the Numato board. It looks like the PIC32 gives us USB and ethernet peripherals. I would say that is a pretty good deal. =) | 05:40 |
| glowplug | Actually that was something I was going to ask you! I was surprised when you mentioned that mor1kx lacked MMU. I would be excited to build a mor1kx based SoC instead of ORPSoc. =) | 05:41 |
| GentlemanEnginee | I thought that Linux was already supported by this core. | 05:41 |
| stekern | and I just killed a bug I've been hunting for a couple of days, before that was fixed only a stripped down linux image I have would boot | 05:41 |
| glowplug | mor1kx is a new core with a fresh codebase that Stefan has been working on. | 05:42 |
| GentlemanEnginee | What is the difference between these two? | 05:42 |
| stekern | GentlemanEnginee: or1200 has MMUs, mor1kx hadn't until now | 05:42 |
| glowplug | And one other main dev I can't remember his name... | 05:42 |
| stekern | Julius | 05:42 |
| glowplug | Right! | 05:42 |
| glowplug | The main important difference is that mor1kx is written from scratch. Clean and modular instead of big and difficult to customize / read. | 05:43 |
| GentlemanEnginee | I see. | 05:43 |
| GentlemanEnginee | I assume the final goal will be less resource intensive, as well? | 05:43 |
| glowplug | And I think there are other implimentation differences but Stefan could tell you better than I can. | 05:43 |
| stekern | GentlemanEnginee: yes, and higher fmax | 05:44 |
| glowplug | As a result of the code cleanup I suspect it will use less LE's. Not really an important feature in regards to ASIC's. x86 chips waste tons of space and yet are very fast and power efficient. | 05:44 |
| stekern | we have already reached those goals to some extent | 05:45 |
| GentlemanEnginee | What are your expectations for fmax? | 05:45 |
| stekern | atm we can do ~80 MHz on cyclone IV | 05:45 |
| glowplug | I think it's more important that people can understand mor1kx so it can be improved and so bugs can be identified easily. Correct me if I'm wrong here. | 05:45 |
| stekern | 100+ MHz should "easily" be achievable imo | 05:46 |
| stekern | glowplug: yes, that's why I rather spend my time on mor1kx than or1200, it's more fun to hack on | 05:47 |
| glowplug | I think it was said that you have already achieved roughly Cortex M4 performance in an FPGA. Which (I guess) will translate into roughly cortex-a8 performance in an ASIC (whenever that will be). | 05:48 |
| stekern | juliusb did a pretty good job when he put it together, everything is easy to find and in logical places | 05:48 |
| stekern | that's not always the case in or1200 | 05:48 |
| GentlemanEnginee | Is there a bugzilla (or similar) page for mor1kx? | 05:49 |
| glowplug | I am an absolute beginner in Verilog and I have been poking through the mor1kx source. It certainly looks pretty. I wish I was in a position to contribute to it directly. =( | 05:49 |
| glowplug | There is a github repo! | 05:49 |
| glowplug | https://github.com/openrisc/mor1kx | 05:49 |
| stekern | but as I said, I'm not ruling out or1200, it's been around for a long time and has been used extensively, while mor1kx probably haven't seen much more hardware than whats on juliusbs and mine tables ;) | 05:50 |
| glowplug | Then I'm going to be a secret weapon then. Lets get mor1kx on thousands of $30 Numato boards. 8) | 05:51 |
| GentlemanEnginee | What is the difference between the openrisc/mor1kx & juliusbaxter/mor1kx hubs? Is the latter solely for the use of said account? | 05:52 |
| glowplug | The latter is an ORPSoc implimentation of mor1kx. | 05:53 |
| stekern | openrisc/mor1kx is the official one, juliusbaxter/mor1kx is his personal | 05:53 |
| GentlemanEnginee | Alright. | 05:53 |
| glowplug | It looks like he also has peripheral code in there also (for an SoC). | 05:54 |
| GentlemanEnginee | I am viewing the openrisc/mor1kx hub. | 05:54 |
| GentlemanEnginee | However, it does not appear to have any issues listed. | 05:54 |
| glowplug | Are there any known bugs Stefan? | 05:54 |
| GentlemanEnginee | How would one know what portions require rework. | 05:54 |
| glowplug | I think that is the great mystery of system design. Other than catastrophic bugs the only reworking really necessary is for it to be faster and have more features. Haha | 05:55 |
| stekern | GentlemanEnginee: test it and watch it turn into flames, then fix it ;) | 05:56 |
| GentlemanEnginee | I see... | 05:56 |
| glowplug | My current feature request would be to patch in a DDR controller to the mor1kx SoC. | 05:56 |
| stekern | more seriously, no, not any bugs that we know of, but most certainly there are bugs | 05:57 |
| GentlemanEnginee | So no suggestions for a starting point? | 05:57 |
| glowplug | Without that then if we do manage to assemble a $30 devboard it will be not very useful. | 05:57 |
| glowplug | Don't you guys use regression testing to verify functionality? Couldn't that be used to hunt for bugs? | 05:57 |
| glowplug | (Sorry if I say something extremely stupid. This is all really new to me). | 05:58 |
| stekern | glowplug: we're using ddr2 controllers on the atlys spartan 6 and ml501 virtex boards | 05:58 |
| stekern | glowplug: yes, there is a regression test suite | 05:58 |
| glowplug | Aren't those controllers IP from Xilinx and not free software? | 05:59 |
| stekern | that's what https://github.com/juliusbaxter/mor1kx-dev-env is for | 05:59 |
| stekern | yes they are | 05:59 |
| GentlemanEnginee | So, the testing occurs on the secondary hub, and is ported to the primary hub when it is deemed worthy? | 06:00 |
| stekern | no, mor1kx-dev-env is a seperate project from mor1kx, it doesn't contain mor1kx | 06:00 |
| stekern | then juliusb has his own mor1kx repo as well and so do I, we use those for work that is not ready to be pushed to the main repo | 06:01 |
| stekern | like, my MMU work atm | 06:01 |
| stekern | https://github.com/skristiansson/mor1kx | 06:01 |
| GentlemanEnginee | Alright. | 06:02 |
| glowplug | So there are three repos. The mor1kx core (cpu). The dev repo which contains lots of duplicated peripheral code (boards, lan, usb, sdram) and Julius's personal repo which also contains just the mor1kx core. | 06:02 |
| glowplug | Sorry. Four. Haha | 06:02 |
| GentlemanEnginee | Is there any manner of co-ordination between devs on this project? | 06:02 |
| stekern | yes, her on irc and on the mailing lists | 06:03 |
| stekern | +e | 06:03 |
| stekern | but for mor1kx, it's been just me and julius hacking on it so far | 06:03 |
| glowplug | So as I understand it. The mor1kx SoC repo contains Xilinx IP for a DDR memory controller? | 06:04 |
| GentlemanEnginee | Would you mind terribly if I poked at it with a sharp stick? | 06:04 |
| stekern | and my "job" has been maintaining the cappuccino incarnation of mor1kx (there are several pipeline implementations, each striving different goals in terms of size and speed) | 06:05 |
| stekern | glowplug: the mor1kx is basically orpsoc | 06:05 |
| stekern | *mor1kx SoC repo | 06:05 |
| stekern | with a few hacks applied upon it | 06:05 |
| stekern | its main purpose is a simulation environment and test-suite | 06:06 |
| glowplug | I'm not sure if I'm comfortable with using Xilinx IP. Haha | 06:06 |
| stekern | GentlemanEnginee: poke away! ;) | 06:06 |
| GentlemanEnginee | So, if I understand your statments, the goal of the mor1kx is to be a test environment that will allow for hacks &c to be developed such that they may be added to ORPSoc at a later date? | 06:08 |
| glowplug | mor1kx is a completely new CPU based on OR1k design. | 06:08 |
| glowplug | The mor1kx SoC repo is an ORPSoc fork with the mor1kx CPU instead of OR1200. | 06:09 |
| glowplug | The mor1kx SoC repo can be used for simulation and testing. | 06:09 |
| stekern | exactly what glowplug said | 06:09 |
| glowplug | And it also apparently contains Xilinx IP. >:( | 06:10 |
| stekern | well, yeah, since it's a fork of orpsoc and that's in orpsoc | 06:10 |
| glowplug | Here is an interesting fact. The PIC32 on the Numato board gets 1.5 MIPS per mhz. Almost exactly the same as the mor1kx. xD | 06:11 |
| stekern | I assume that's dmips | 06:11 |
| glowplug | Correct. | 06:11 |
| GentlemanEnginee | And that would make openrisc/mor1kx the hub for the mork1kx SoC, or for the mork1kx core itself? | 06:12 |
| glowplug | That isn't surprising at all though. PIC32's are RISC chips with a 5-stage pipeline. | 06:12 |
| glowplug | For the core itself. =) | 06:12 |
| stekern | GentlemanEnginee: the mor1kx core | 06:12 |
| stekern | glowplug: exactly, MIPS to be more precise | 06:12 |
| stekern | (mips as in the architecture) | 06:13 |
| glowplug | Yup I'm following! | 06:13 |
| glowplug | It would be interesting to peek into the PIC32. Too bad we cant. =( | 06:13 |
| GentlemanEnginee | Alright, perhaps I missed the hub for the mor1kx Soc, then. My humblest apologies... | 06:13 |
| glowplug | https://github.com/openrisc/mor1kx | 06:14 |
| glowplug | That repo is strictly the MIPS core. Can't do much with it without the SoC implimentation in the dev repo. | 06:15 |
| GentlemanEnginee | I must admit to being lost. Where is the dev repo for the SoC Implementation, then? | 06:16 |
| glowplug | https://github.com/juliusbaxter/mor1kx-dev-env | 06:17 |
| glowplug | You are right that this should probably all be in one repo (which is more conventional). | 06:17 |
| GentlemanEnginee | Aha! | 06:17 |
| GentlemanEnginee | Please forgive my obtuseness... | 06:17 |
| stekern | glowplug: correction, mor1kx is not MIPS, but OR1K ;) | 06:17 |
| glowplug | That's a good point. You guys are inventing architectures. =) | 06:18 |
| GentlemanEnginee | The advantage is that one may create one's own obscure nomenclature. | 06:19 |
| glowplug | Did you guys see what the completed Numato board looks like? It is very pretty. http://numato.com/blog/oct2012/images/quandary1.jpg | 06:19 |
| GentlemanEnginee | That is the sole reason for creating anything, isn't it? | 06:19 |
| glowplug | Absolutely! Like naming the cpu implimentations after caffiene beverages. HAha | 06:19 |
| glowplug | *Are there any plans for Monster and RedBull cores? | 06:20 |
| GentlemanEnginee | I once named different versions of a project after characters in Beowulf... | 06:20 |
| glowplug | https://github.com/juliusbaxter/mor1kx-dev-env/tree/master/boards/generic/mor1kx-espresso | 06:21 |
| glowplug | That is the Espresso that Stefan mentioned earlier. | 06:21 |
| GentlemanEnginee | I forsee mate, C. sinensis var. sinensis, & C. sinensis var. assamica... | 06:22 |
| glowplug | I've located the milkymist SoC git repo. Can't seem to locate the DDR controller yet. | 06:26 |
| glowplug | https://github.com/milkymist/milkymist-ng | 06:26 |
| glowplug | And I'm not quite sure this is. https://github.com/milkymist/milkymist/blob/master/boards/milkymist-one/rtl/ddram.v | 06:29 |
| GentlemanEnginee | Perhaps I will look at that once I have some concept of how the project is configured... | 06:34 |
| GentlemanEnginee | It will be akin to a child attempting to rebuild an internal combustion engine. | 06:35 |
| glowplug | That's how I feel too. Except instead of a child maybe more like a house fly. O.o | 06:36 |
| GentlemanEnginee | I wish that I had the ability to fly. It might make the process less difficult... | 06:37 |
| glowplug | It is encouraging that the Milkymist project also utilizes a Spartan-6. That should make using whatever code they have (wherever it is) for interfacing with a DDR chip at least possible. | 06:37 |
| GentlemanEnginee | One would hope... | 06:38 |
| glowplug | Here is a list of all the Milkymist repos. https://github.com/milkymist | 06:40 |
| glowplug | I went through some of them and can't seem to find what would be an entire DDR memory controller. I must be missing something. | 06:40 |
| glowplug | Unfortunately it's late here again and I'm heading off to bed. Talk to you guys tomorrow. 8) | 06:41 |
| GentlemanEnginee | Enjoy your rest. | 06:42 |
| stekern | juliusb: I know all about the new nice version registers etc, and that they probably should be used. But shouldn't we anyways provide some more useful information here: http://pastie.org/6487049 | 10:19 |
| stekern | I have no idea what number we should have there, but a zero seems "wrong" | 10:34 |
| stekern | anyways, this seems stable enough to start shuffle things over on openrisc/mor1kx | 11:17 |
| juliusb | stekern: sure - but that's something for the Linux kernel, no? | 12:10 |
| juliusb | we should look at adding a bunch of core config information to the implementation-specific regs | 12:10 |
| juliusb | like, basically a bit for every optional feature | 12:10 |
| juliusb | and nice work on the MMU progress, please do start shuffling | 12:11 |
| juliusb | I successfully ran the GCC regression C torture regression suite against both espresso and pronto yesterday | 12:11 |
| juliusb | I run it gainst the cycle-accurate models, so as cappuccino doesn't build yet, I haven't run it on it | 12:12 |
| juliusb | but - whatever, perhaps we should coem up with some final steps for some work on mor1kx before a first release | 12:12 |
| juliusb | basicaly I think just updating ISRs with implementation-specific bits, and some documentation | 12:13 |
| juliusb | oh, probably software breakpoints in cappuccino, too | 12:13 |
| juliusb | but I can look at that | 12:13 |
| stekern | juliusb: using the extended versioning info is something for the kernel yes, but my point was more, what does the zero in the "old" version register represent? | 12:25 |
| stekern | that was maybe apart of the VR2 et al discussion, refresh my memory if so | 12:26 |
| stekern | s/apart/part | 12:26 |
| juliusb | oh right | 12:28 |
| juliusb | it means your core is from teh stone ages :) | 12:28 |
| juliusb | from the "before time". | 12:28 |
| stekern | mor1kx is from teh stone ages??? =P | 12:29 |
| juliusb | :) | 12:29 |
| juliusb | so | 12:30 |
| juliusb | with the new arch spec and VR2, etc. we need to push some software updates for headers etc | 12:30 |
| juliusb | when you get the mor1kx updated, it might be worth updating the OR1200 to have some sensible values in its VR/VR2 | 12:30 |
| juliusb | also or1ksim | 12:30 |
| juliusb | and then update the kernel port to read those | 12:30 |
| stekern | sure, but wouldn't the sensible "default" value for VER in the "old" VR be 0x10? | 12:32 |
| stekern | and then have UVRP bit set to indicate that there's more information for enlightened software | 12:33 |
| stekern | my main concern here is: the value zero => looks like something is wrong ;) | 12:33 |
| stekern | I mean, even if that register is now deprecated, the arch spec has stated that values not between 0x10 and 0x19 are illegal | 12:35 |
| juliusb | sure | 12:35 |
| juliusb | http://opencores.org/or1k/OR1K:Community_portal#Updated_to_support_OR1K_1.0_versioning_system | 12:35 |
| juliusb | (we need a better organised TODO page) | 12:35 |
| juliusb | (I'll fix hat this weekend) | 12:35 |
| juliusb | but umm | 12:35 |
| juliusb | i dunno about the old version | 12:35 |
| juliusb | The correct thing to do is update everything | 12:36 |
| juliusb | mor1kx has the new versioning system - I'm not sure we need to think too much about what software (which doesn't spport the new system) reads | 12:36 |
| juliusb | or should we? | 12:36 |
| stekern | nah, the correct thing to do is to make stuff backwards compatible, then when you are sure everything has been updated then you can remove backwards compability | 12:37 |
| stekern | (answer to the "The correct thing...") | 12:38 |
| juliusb | ok cool | 12:38 |
| stekern | it's perhaps not a huge deal, linux doesn't seem to die if that is set to zero, nor does u-boot | 12:38 |
| stekern | they just print the zero | 12:39 |
| juliusb | It doesn't hurt to just add in values to the depreacted fields to old software reads something at least? | 12:39 |
| juliusb | the old versioning system was never really paid attention to, anyway | 12:39 |
| stekern | but I don't see setting the ver bitfield to 0x10 in mor1kx a problem neither | 12:40 |
| stekern | is there a openrisc implementation that use 0x10? | 12:44 |
| stekern | point being, by setting it to 0x10, we guard ourself against being incompatible with (old) software that possibly does some stubborn checking that that register is between 0x10 and 0x19 | 12:54 |
| stekern | if it checks for a particular version, we are probably not suitable anyway | 12:54 |
| stekern | + u-boot and linux printing doesn't look odd until they have been updated ;) | 12:55 |
| stekern | well, u-boot still prints it ugly, but I guess that's a bug... | 13:01 |
| stekern | ah, no, it doesn't I scrolled back to far in the terminal window | 13:03 |
| stekern | CPU: OpenRISC-1000 (rev 0) @ 50 MHz | 13:03 |
| stekern | vs | 13:04 |
| stekern | CPU: OpenRISC-000 (rev 0) @ 50 MHz | 13:04 |
| stekern | so, juliusb, should I push this? http://pastie.org/6488522 | 13:06 |
| juliusb | yeah why not? | 13:15 |
| juliusb | looks fine | 13:16 |
| mor1kx | [mor1kx] skristiansson pushed 1 new commit to master: https://github.com/openrisc/mor1kx/commit/edefb6ee9cd3d68cc161cf30013fdf43d6594d8d | 13:22 |
| mor1kx | mor1kx/master edefb6e Stefan Kristiansson: cfgrs: set VR VER to 0x10... | 13:22 |
| juliusb | excellent :) | 13:37 |
| juliusb | i like those announcements | 13:37 |
| juliusb | jeremybennett: how are signups for the chip hack looking? | 16:59 |
| jeremybennett | Half gone now. No school teachers signed up yet though :-( | 17:57 |
| jeremybennett | Just checked again - they are going fast. Only 12 places left. | 17:57 |
| juliusb | Oh, disappointing about the teachers. | 18:19 |
| juliusb | But good news that ti's popular. | 18:19 |
| glowplug | Good afternoon. =) | 18:43 |
| stekern | good evening | 18:45 |
| juliusb | this is intereting - these Andestech guys were mentioned on eetimes today, referred to as the "next ARM" and in Taiwan. Here's their ISA: http://www.andestech.com/en/products/AndeStar.htm | 18:51 |
| juliusb | very similar to what we're floating for OR2K | 18:51 |
| juliusb | it looks like they have multicore going, too, and implementations | 18:51 |
| juliusb | but it's interesting to know that these boys got a mention on eetimes | 18:52 |
| glowplug | Don't they mean "bit-endian" support? O.o | 18:52 |
| glowplug | I found another interesting board from Numato. Instead of a pic32 for peripherals it has a Cortex M3. | 18:57 |
| glowplug | http://numato.cc/taxonomy/term/9 | 18:57 |
| glowplug | Also I discovered this morning that the DDR controller in the Milkymist is infact Xilinx IP. | 18:58 |
| glowplug | "Spartan-6 FPGA DDR/DDR2 SDRAM PHY core from Xilinx and Northwest Logic." | 18:58 |
| glowplug | As far as I know there does not exist a "properly" licensed IP DDR controller. =( | 18:59 |
| juliusb | glowplug: bi-endian means you can be either big or little endian: http://en.wikipedia.org/wiki/Endianness | 19:00 |
| glowplug | I noticed that right after I typed it. Apparently bit-endianness only applies to every bit has it's own address. Learn something new every day. =) | 19:02 |
| glowplug | At any rate I still plan to assemble the Quandary board. I just wont be able to boot linux or do anything cool until there is a functional DDR controller. | 19:03 |
| juliusb | oh I didn't know that. ARM allows a bit-addressing mode called bitbanding I believe | 19:03 |
| juliusb | that would be a bit-endian region then I guess | 19:04 |
| glowplug | Seems like that kind of behavior is only useful to microcontrollers and not their big brothers. | 19:05 |
| glowplug | Right. Because the addresses are atomic. | 19:05 |
| glowplug | However I actually had no idea what it meant. I had just heard the term before and assumed the Chinese mistyped it. Haha | 19:06 |
| stekern | glowplug: the ddr controller in the "old" milkymist soc is gplv3 | 19:07 |
| glowplug | Wait. Really? Where the heck did they hide that thing? | 19:07 |
| stekern | i.e. the non -ng soc | 19:07 |
| glowplug | Didn't they have some serious problems with it? I suppose even if that was the case it could be a starting point. | 19:08 |
| glowplug | Your right! There is a datasheet for a 256mb DDR module in that repo. | 19:09 |
| stekern | no, it worked fine | 19:10 |
| glowplug | http://bit.ly/ZQaS3M | 19:10 |
| stekern | iirc even nasa is using it | 19:11 |
| glowplug | Are you joking? HAha | 19:11 |
| glowplug | One thing about the GPL however. There is a problem with GPL and hardware yes? | 19:11 |
| glowplug | How much of ORPSoc is already GPL? | 19:11 |
| glowplug | Ahh nevermind. Looks like it's all LGPL. =) | 19:18 |
| glowplug | It's interesting because Stallman himself actually supports weak GPL licensing (strangely) in cases where the proliferation of that software would do significantly more good overall. The example he uses is OGG vs MP3 where music players have proprietary software but should be using OGG regardless. | 19:20 |
| glowplug | I would say that OpenCores qualifies as something that wold do tremendous good if it was prolific. =) | 19:21 |
| stekern | you're using words that's not in my vocabulary, what does prolific mean? | 19:23 |
| glowplug | Distributed to many. Basically. =) | 19:23 |
| stekern | anyways, gpl isn't really suitable for hw, mor1kx for instance has a more permissive license | 19:24 |
| glowplug | I remember from the 2012 conference. =) | 19:24 |
| glowplug | Is the LGPL really sufficient though? I mean it does most of what your trying to achieve. | 19:25 |
| glowplug | At any rate it can mingle with any other license so thankfully license-perfection is not immediately necessary. | 19:26 |
| glowplug | It looks like 1gb ddr chips are $50 each. I might have to stick with the 512mb chip. O_O | 19:30 |
| glowplug | Is it planned for mor1kx to have a seperate MMU for instructions + data? | 20:33 |
| juliusb | glowplug: I believe that's the plan - it'll be the same as the OR1200 | 21:40 |
| juliusb | (which has IMMU, DMMU) | 21:40 |
| glowplug | Very cool! I am watching the OSHUG 17 presentation on YouTube right now. Don't know how I missed this video before. O.o | 21:43 |
| andresjk | do you guys had used wget from busybox 1.19 to download objects (programs) ? I want to speedup the software development rather than recompiling the vmlinux for a new soft | 21:46 |
| andresjk | any suggestion? | 21:46 |
| jeremybennett | I've used FTP in the past, and BusyBox also supports NFS version 3. | 21:47 |
| jeremybennett | I know lots of people use NFS for development | 21:47 |
| glowplug | Couldn't a local git repo work (assuming you could compile git in your environment). | 21:47 |
| andresjk | Yes, FTP without login works great, but It doesnt when trying the user, pass argument | 21:48 |
| andresjk | HTTP, only work for html, not for any other obj | 21:48 |
| andresjk | I will try NFS, never use it before | 21:49 |
| andresjk | thanks | 21:49 |
| andresjk | jeremybennett, would it be possible to have a working or32-linux-gcc and the libs in the embedded linux environment? | 21:51 |
| glowplug | Your embedded linux is running on the Atlys board or a sim at the moment? | 22:19 |
| andresjk | on a ML501 | 22:21 |
| glowplug | You have all of the awesome toys. O_O | 22:24 |
| glowplug | I wish I knew the answer to your question. There is very little information on or32 gcc online. =( | 22:25 |
| glowplug | I am curious about the answer as well though. I am interested mainly in linux development for the platform. Hopefully python. =) | 22:26 |
| andresjk | haha, actually is a borrowed toy, I wish it was mine lol. | 22:30 |
| andresjk | I want to test software faster. recompiling the kernel and testing it all over again takes time | 22:30 |
| glowplug | Is it not possible to cross-compile a module on your dev system then transfer it to the SoC and install it without building on the SoC? | 22:32 |
| andresjk | are you experienced in linux kernel? | 22:32 |
| andresjk | yes, actually thats what I have been trying with wget | 22:33 |
| glowplug | While normally I would say that I have "intermediate" experience. Given that everyone in this channel appears to be a super-genius I'm going to answer "beginner/novice". Haha | 22:33 |
| andresjk | haha | 22:33 |
| andresjk | then I have a question for you xD | 22:34 |
| glowplug | I can't imagine that NFS would work if wget does not. | 22:34 |
| andresjk | I got wget to work in anonymous ftp server, and http not really | 22:35 |
| andresjk | well.. | 22:35 |
| andresjk | how can I get the physical address of a given variable within the user-space? | 22:36 |
| andresjk | I don't want to mess with the kernel yet | 22:36 |
| glowplug | I'm pretty sure thats not possible with virtual memory. Someone correct me here if I'm wrong. | 22:37 |
| glowplug | You have a functional SSH server on your embedded linux? | 22:38 |
| andresjk | yeah, I thought so | 22:38 |
| andresjk | but maybe there is a kernel function that can get that info or another workaround | 22:40 |
| glowplug | You should try to mount a remote directory containing your compiled modules using SSHFS. | 22:40 |
| andresjk | I will give it a shot. ty | 22:44 |
| glowplug | No problem. Hopefully the ssh you have will allow that if so it would be extremely convenient. It's basically a dropbox directory. =) | 22:46 |
| _franck_ | andresjk: have you tried ftpget ? | 22:51 |
| andresjk | no, is it part of busybox? | 22:52 |
| _franck_ | yes | 22:52 |
| andresjk | cool. I will try it | 22:53 |
| andresjk | thanks | 22:53 |
| glowplug | That is probably the way to go. Apparently dropbear does not support sshfs. Openssh does but I'm not sure if that will compile in your environment. | 22:57 |
| glowplug | If however you can compile openssh you can do "sshfs user@hostip:/remotedir localmountdir" | 22:58 |
| glowplug | Then you will have a live remote mounted directory of your modules. | 22:58 |
| glowplug | That may be more convenient in the long run than ftpget. But ftpget is probably the easiest way. | 23:05 |
| _franck_ | nfs is also very conveniant. You just have to setup an nfs server on your host and tells the kernel where to find it | 23:06 |
| _franck_ | it will load its rootfs from there | 23:06 |
| glowplug | Good point. I don't think thats possible with sshfs (due to fuse). | 23:09 |
| glowplug | _franck_ do you have any insight into locating physical memory addresses for variables in user-space? | 23:10 |
| glowplug | I was under the assumption that wasn't possible in systems with virtual memory but I'm unsure. | 23:11 |
| _franck_ | there should be some way, but it's not straightforward | 23:14 |
| _franck_ | why do you want to do that ? | 23:15 |
| glowplug | andresjk asked earlier. I'm not sure what he's working on to be honest. Haha | 23:15 |
| andresjk | thanks for asking glowplug | 23:16 |
| _franck_ | because he doesn't "want to mess with the kernel yet" :) | 23:16 |
| glowplug | Oh that! Haha | 23:16 |
| andresjk | lol | 23:16 |
| andresjk | I want to test a master peripheral | 23:16 |
| andresjk | so I want to write some data somewhere in the memory | 23:16 |
| _franck_ | use mmap | 23:17 |
| glowplug | Can't DD write data to memory locations? | 23:17 |
| andresjk | I'm using mmap to write the data | 23:17 |
| andresjk | the registers | 23:17 |
| andresjk | but the master should be able to retrieve the data by its own | 23:18 |
| andresjk | knowing the addresses | 23:18 |
| andresjk | similar to the vga buffer descriptors | 23:18 |
| andresjk | the data would be in a variable but to set up the register I need the physical address | 23:19 |
| _franck_ | ok, you want to do some dma from he user's space | 23:20 |
| andresjk | exactly! | 23:20 |
| glowplug | Will pagemap accomplish that? | 23:21 |
| glowplug | I think that pagemap is actually now called smem. | 23:25 |
| _franck_ | you won't be able to flush cache from the user's space | 23:25 |
| _franck_ | in the kernel space you allocate dma buffer with dma_alloc_coherent | 23:26 |
| _franck_ | to get a contigous uncached region of memory | 23:26 |
| _franck_ | you should try to make a simple device driver, it's not difficult | 23:27 |
| glowplug | I think we all saw that coming. O_O | 23:27 |
| glowplug | There is this. He seems to have C code that can determine physical address mapping of virtual memory pages. | 23:28 |
| glowplug | http://stackoverflow.com/questions/6284810/proc-pid-pagemaps-and-proc-pid-maps-linux | 23:28 |
| glowplug | I'm not sure if it's actually of any use. _franck_ is probably right about the driver. | 23:28 |
| andresjk | cool. | 23:29 |
| andresjk | thanks guys | 23:29 |
| glowplug | Here is some more information hinting to pagemap. http://log.or.cz/?p=89 | 23:36 |
| glowplug | They give some explination but also what looks like 64-bit perl code. Not very useful. | 23:38 |
| andresjk | everything is useful rightnow | 23:39 |
| andresjk | thanks glowplug | 23:40 |
| glowplug | Np. =) | 23:41 |
| glowplug | Do you have any opinions on the Numato schematics I found yesterday? Advice? | 23:41 |
| andresjk | which ones? the little, low-cost boards ? | 23:45 |
| glowplug | http://numato.cc/content/kicad-more-complex-boards-our-experiment-spartan6-csg225 | 23:46 |
| glowplug | They are theoretically low cost. Free software schematics of spartan-6 modules with a 512mb DDR chip and pic32 for peripherals (usb, ethernet ect.). | 23:46 |
| glowplug | They could be made for under $35 in single quantity. I'm trying to figure out how much interest there is. | 23:47 |
| _franck_ | back | 23:47 |
| glowplug | _franck_ welcome back. =) | 23:47 |
| andresjk | sounds great | 23:48 |
| _franck_ | just kicked my ethernet cable out of the switch and I was waiting for the link to come back :) | 23:49 |
| glowplug | It would have only 15k LE's. Just enough for ORPSoc. But with the peripherals on the pic32 that saves a lot of chip space. | 23:49 |
| _franck_ | until I realized it was too much long :) | 23:49 |
| glowplug | It might be time to mount your network equipment. Haha | 23:49 |
| glowplug | The thing about the Quandary board is that it's 6 layer. We can assemble the boards ourselves but the boards need to be ordered. Everything else can be sourced individually. Including the courage to solder them. Haha | 23:51 |
| andresjk | less than $35 its very impressive. I would surpass the raspberrypi in cost and performance since you are talking about a programmable logic device | 23:54 |
| glowplug | I would agree with the detail of manually assembly / time being a fairly high cost. | 23:54 |
| andresjk | I guess some porting should be done in order for the linux kernel to support the peripherals | 23:55 |
| glowplug | But for the case of operisc the next best board is $90 and has no pic32 and significantly less RAM. | 23:55 |
| glowplug | And also having a non-proprietary development board seems like a necessesity (in my opinion at least). | 23:56 |
| andresjk | you mean pic32 microcontroller right? | 23:56 |
| glowplug | Right. The design has an interconnect between the pic32 and the spartan-6. | 23:57 |
| glowplug | The pic32 has ethernet and usb, as well as the ability to program the FPGA using JTAG (no external programmer). | 23:58 |
| glowplug | There is not a lot of information about the project except the SVN repo. | 23:58 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!
