| --- Log opened Mon Mar 30 00:00:44 2015 | ||
| DarkFox | olofk: I'll have to check this one out - I have indeed, seen references to it. Thanks | 03:56 |
|---|---|---|
| DarkFox | More research I have found risc-v's "why not openrisc" but I'm yet to see any openrisc "why not risc-v" anyone here know any references for this? | 03:58 |
| stekern | DarkFox: that's because the risc-v "why not openrisc" question answers the question why they didn't choose to build upon the already existing openrisc | 04:21 |
| DarkFox | stekern: That isn't what I'm asking. I'm responding to that question asking "why not risc-v" ? | 04:22 |
| DarkFox | They already answered why risc-v over openrisc; but failed to include why openrisc over risc-v. | 04:23 |
| dalias | yeah i'd be interested in hearing the openrisc side too :) | 04:23 |
| dalias | from what i've seen of both i like risc-v better | 04:24 |
| stekern | yes, I understand that, I'm just explaining the reason why you haven't seen the answer | 04:24 |
| DarkFox | From what I've seen - there isn't an answer :( | 04:24 |
| DarkFox | dalias: I'm leaning slightly towards risc-v now myself. One reason ignoring the "why not openrisc" answers is the usage of BSD over GPL (which I do preferr) and they seem to have asics already made. | 04:26 |
| DarkFox | Two reasons * | 04:26 |
| DarkFox | :P | 04:26 |
| dalias | *sigh* crashed my firefox | 04:27 |
| DarkFox | dalias: jor1k? :P | 04:27 |
| dalias | no opening the risc-v rationale pdf :) | 04:27 |
| DarkFox | :) | 04:27 |
| dalias | but it's great. i dropped my swap down to 768M | 04:27 |
| DarkFox | jor1k vs angel; jor1k <3 | 04:27 |
| dalias | so now instead of the box becoming unusable for 10 min when i open too many tabs, firefox just crashes :) | 04:28 |
| * DarkFox doesn't have swap; but instead is living in 8G ram with no disks :P | 04:28 | |
| stekern | and, yes, I agree, risc-v is nicer in a lot of aspects. There's a lot of old ugly baggage in the or1k arch | 04:28 |
| stekern | but GPL? | 04:28 |
| DarkFox | stekern: So you argue that GPL is better? :P | 04:29 |
| stekern | not at all | 04:29 |
| DarkFox | Good; no flame war here :D | 04:29 |
| stekern | that's only relevant for implementations, not architectures | 04:29 |
| DarkFox | Indeed | 04:29 |
| stekern | ...and our current main implementation is not GPL anyway | 04:30 |
| DarkFox | One thing I'd like to do is run https://github.com/thepowersgang/rust-barebones-kernel in jor1k. But my only system that I can access right now is alpine; which conflicts with rust due to mprotect (pax) and rust is expecting the paxctl-ng (which alpine won't have for another few weeks). | 04:31 |
| DarkFox | stekern: Which is that and what license? | 04:31 |
| stekern | https://github.com/openrisc/mor1kx | 04:32 |
| DarkFox | License too long :C | 04:32 |
| * DarkFox hugs MIT/bsd/etc :P | 04:32 | |
| stekern | yeah, I agree. All cores I've done from scratch is BSD | 04:33 |
| DarkFox | Nice! | 04:33 |
| * DarkFox still yet to do such.... need a good development system - and don't have that :( | 04:34 | |
| DarkFox | Long term: What is expected in terms of openrisc vs risc-v? Risc-v to take over? OpenRISC to improve following Risc-V's innovations? | 04:36 |
| stekern | but to answer the question "why openrisc", IMO the openrisc project's biggest strength (and weakness) is that it's completely "community driven". I.e. there's no single driving entity behind it. | 04:36 |
| DarkFox | stekern: I do agree with this... What about a merge? :P | 04:37 |
| stekern | which means that it's all open arms for anyone to take a significant role in the project | 04:37 |
| DarkFox | I have a project (won't be doing hardware for a while ...) with requirements for being cheap and powerful enough to run a custom RTOS written in rust for specific applications (secure communications, decentralised infrastructure, ephemeral design, etc); ideally with a crypto core (would need common primitives from NaCl; chacha20-poly1305, salsa20, curve25519/ed25519[4~) | 04:40 |
| DarkFox | What would you recommend? (OpenRisc or Risc-v) | 04:40 |
| DarkFox | For an idea for the crypto load - just consider tor :P | 04:42 |
| stekern | if you are going to run it on an FPGA, openrisc, afaik the risc-v project haven't released any implementation targeted for that yet | 04:42 |
| stekern | if you're hoping for asics, risc-v | 04:42 |
| DarkFox | Hoping for ascis.. if cheap enough while RPGA does enable lots more flexibilties to the end-users. | 04:43 |
| DarkFox | Also; not any time soon for hardware here* | 04:44 |
| DarkFox | Lots of software to do :P | 04:44 |
| dalias | :) | 04:44 |
| DarkFox | I'm after a portable userland toolchain for my network and applications - portable so should work on linux,bsd,windows, etc and this part is for a standalone 100% trusted computing base where all the hardware to the software is known. | 04:45 |
| * DarkFox = cypherpunk :) | 04:45 | |
| DarkFox | stekern: Why would asics exist for risc-v but not fpga? Isn't FPGA the pre-asic development stage? Why no FPGA? o.0 | 04:46 |
| stekern | you can run it on an FPGA, but it's not targeted for it | 04:47 |
| DarkFox | So it was optimized for asic and fpga pre-asic designs purged? o.0 | 04:48 |
| stekern | you can put it that way | 04:48 |
| dalias | there should be risc-v fpga implementations sometime middle of this year | 04:49 |
| DarkFox | Damn .. Why can't these projects just merge? :D | 04:49 |
| dalias | according to lowrisc.org | 04:49 |
| DarkFox | dalias: That's cool | 04:49 |
| dalias | but asic is the main target (aiming to have them available sometime next year) | 04:49 |
| stekern | for instance, their "rocket" core use CAM for their TLB's. That's something that doesn't translate well to FPGA block ram | 04:50 |
| DarkFox | TLB? | 04:50 |
| dalias | part of how the mmu works | 04:50 |
| stekern | so it's a conscious choice | 04:51 |
| DarkFox | Right | 04:51 |
| dalias | my impressions so far: | 04:51 |
| DarkFox | So for my future project (hardware side of it); risc-v would be the ideal decision? | 04:52 |
| dalias | - risc-v has a better chance of having high-performance implementations that are competitive with proprietary archs in many real-world applications and in performance-per-watt | 04:53 |
| dalias | - risc-v isa admits more efficient compiled code gen | 04:53 |
| dalias | (e.g. it has efficient ways of doing 32-bit-pc-relative addressing, conditional branches, etc) | 04:54 |
| dalias | risc-v looks like it was designed by people who understand the ABI requirements for modern compiled position-independent code | 04:54 |
| DarkFox | Okay; so risc-v it is. \o/ | 04:56 |
| DarkFox | I guess I could always make it compabible with both archetectures; already want it to work on x86, arm, or1k, and now risc-v :P | 04:57 |
| dalias | there's really no reason it can't be compatible with both | 04:57 |
| dalias | most of the software should be C or other high-level langs | 04:57 |
| DarkFox | All of my code - ideally... will be rust. | 04:58 |
| dalias | ah ok | 04:58 |
| dalias | well then you need the compiler to be able to generate code for either or both :-) | 04:58 |
| DarkFox | So - so long that rust can compile through llvm for the architecture; it should be fine (and then boot specifics and drivers...) | 04:58 |
| olofk | DarkFox: And FYI, people have done ASIC implementations of OpenRISC for over 10 years | 04:58 |
| dalias | i suspect initial support for both is via gcc/binutils, not llvm | 04:58 |
| DarkFox | Rust uses both iirc | 04:59 |
| dalias | olofk, neat. links to any commercially availabls asic boards/socs? | 04:59 |
| DarkFox | +1 | 04:59 |
| olofk | I would like to put it this way. If you are targetin FPGA, want 32-bit and want something that is available today, go for OpenRISC | 04:59 |
| olofk | If you are cool with waiting for a RISC-V ASIC and require 64-bit, go for RISC-V | 05:00 |
| * DarkFox the latter | 05:00 | |
| dalias | olofk, is there any good reason to prefer fpga as a target except in the case where you're implementing other (non-cpu) stuff directly on fpga and want the cpu integrated with it for direct access? | 05:00 |
| DarkFox | dalias: Custom cores | 05:00 |
| olofk | dalias: Not really, but I know that stekern made the OpenRISC inside is allwinner-A10 chipset run some code :) | 05:00 |
| dalias | darkfox, doesn't "custom cores" mean something like what i said? | 05:01 |
| olofk | dalias: Volume. If you require a custom implementation you would ned to sell millions of units to make it worth doing a ASIC | 05:01 |
| DarkFox | dalias: I guess so; also more modifications and maybe custom instructions may be desired | 05:01 |
| olofk | Ah sorry. That's what you said :) | 05:01 |
| dalias | :) | 05:02 |
| dalias | e.g. if you're doing hashing (like bitcoin mining ;-) and just want the cpu to control the process, then fpga makes a lot of sense | 05:02 |
| DarkFox | For confirmation; asic is much cheaper than fpga when finalised correct? | 05:02 |
| dalias | or if you're doing some sort of dsp or gpu type thing and again just want the cpu there to control it... | 05:02 |
| DarkFox | (FPGA always available while asic needs mass production of a specific design) | 05:03 |
| olofk | Time to market is another thing. Many companies put out products with FPGA and do an ASIC spin later on | 05:03 |
| DarkFox | Fair enough | 05:03 |
| dalias | darkfox, fpga = C*n where C is a moderately large constant. asic = M+ε*n where M is a huge constant and ε is a tiny constant | 05:04 |
| olofk | Got to run | 05:04 |
| dalias | olofk, did i get that approximately right? :) | 05:04 |
| DarkFox | dalias: Is that for quantity available for general fpga vs exact-order asic? | 05:05 |
| dalias | both are expressions for cost :) | 05:05 |
| DarkFox | Okay so the tiny 3 or e or whatever that is.. is the asics being much cheaper; but have a larger production fee (that is already included in the many fpgas as they are distributed) | 05:07 |
| dalias | basically ASIC has a huge startup cost for production that's not going to make sense unless you can use millions of them | 05:08 |
| dalias | but then each unit is dirt cheap | 05:08 |
| dalias | whereas fpga has low or no startup cost (in principle you could make them all at home with the same tools you use for development, i suppose, but don't quote me on that) but each unit is rather expensive | 05:09 |
| * DarkFox intends to do fpga for dev/prototype and kickstarter(or similar) for asic/production | 05:12 | |
| DarkFox | But that'll be a while away still :) | 05:12 |
| dalias | i really should do some project with musl that aims to be popular to a wide audience and kickstarter it | 05:18 |
| DarkFox | Thanks everyone who discussed the pros/cons for these architectures - and their futures. | 05:18 |
| DarkFox | dalias: +1 | 05:18 |
| dalias | because it's hard to get funding for low-level systems infrastructure stuff :( | 05:19 |
| DarkFox | I vote something with widespread use of cryptography on alpine or sabotage or custom (linux,bsd,rtos,etc). | 05:19 |
| DarkFox | :) | 05:20 |
| DarkFox | dalias: Sadly; indeed. :( | 05:20 |
| DarkFox | Has anyone hooked an openrisc or risc-v up to a display in their implementation? | 05:30 |
| DarkFox | (Not just serial or jor1k/software emulators) | 05:30 |
| DarkFox | Appears that the results on youtube are prooving yes :D | 05:36 |
| DarkFox | stekern: Nice | 05:37 |
| olofk | There's a lot of talk about Intel buying Altera. I wonder if that will happen | 06:12 |
| DarkFox | I sure hope not... | 06:18 |
| DarkFox | Imagine if.... Intel went as open as opencores... | 06:19 |
| olofk | I would like to have x86 + FPGA. I find it a bit scary that ARM has such large dominance in the embedded market | 06:21 |
| olofk | Same as with Intel on the desktops for the last 20 years | 06:22 |
| DarkFox | olofk: x86+FPGA; IIRC ... xeon? | 06:22 |
| DarkFox | Hybrids | 06:22 |
| olofk | And I would say that Intel is as good as ARM when it comes to Open Source. | 06:22 |
| olofk | oh right. Forgot about those | 06:23 |
| DarkFox | Drivers are sane; hardware closed :( | 06:23 |
| DarkFox | olofk: And I'm the software guy :P | 06:23 |
| olofk | Yeah. Sounds like both ARM and Intel :) | 06:23 |
| olofk | But Intel at least have better reputation when it comes to graphics drivers | 06:24 |
| DarkFox | olofk: OpenCores does it right :P | 06:24 |
| DarkFox | GPL, BSD, etc. <3 | 06:24 |
| olofk | Anyone familiar with exFAT? | 06:38 |
| DarkFox | olofk: Is that the one with windows drivers? | 06:53 |
| olofk | Yep. Microsof stuff. Required for newer SD cards :( | 06:56 |
| DarkFox | Isn't that the half ext4 half fat? | 06:57 |
| DarkFox | Nope | 06:57 |
| DarkFox | :) | 06:57 |
| DarkFox | For what I can remember; it works well on all systems and is much better than fat | 06:58 |
| DarkFox | http://ntfs.com/exfat-comparison.htm | 06:59 |
| DarkFox | olofk: For filesystems; I personally vote either zfs or ram/tmpfs :P | 07:04 |
| DarkFox | jor1k: 100MIPS = 1e8 (100 million) instructions per second; aka 100Mhz ? | 07:30 |
| ams | hz has nothing with instructions per second. | 07:38 |
| DarkFox | Erm: I'm thinking fpga | 07:39 |
| DarkFox | Not instructions but yea... | 07:40 |
| ams | still has nothing to do with how many instructions can be exeucted per second. | 07:40 |
| DarkFox | I still mixed things :) | 07:41 |
| DarkFox | Technically it is 100Mhz - just not clock cycles nor the standard way to represend it (Hz is just frequency) | 07:41 |
| DarkFox | 138MIPS for "Safe Core (slow)" and 102.8MIPS for "asm.js" - That "(slow)" is questionable.... Is faster o.0 | 07:46 |
| DarkFox | 142MIPS even | 07:46 |
| * DarkFox wonders how hard it would be to port risc-v to jor1k | 08:52 | |
| bandvig | Hello all! It was interesting discussion today morning about “why not (openrisc/risc-v)”. I would like to present my personal answer “why not risc-v”. My requirements to CPU were: | 09:18 |
| bandvig | (1) Potential performance should be on ARM Cortex-A8/A9 (if implemented as ASIC) level | 09:18 |
| bandvig | (2) Support virtual memory and multicore | 09:18 |
| bandvig | (3) Should be already implemented (perhaps not completely) as for FPGA or ASIC. A tool chain should be already available | 09:19 |
| bandvig | (4) License should be BSD-like or LGPL | 09:19 |
| bandvig | (5) HDL should be Verilog | 09:19 |
| bandvig | The only OpenRISC meets all my requirements | 09:19 |
| Hesham | bandvig: Thanks for sharing your answer. I agree with point 5. Do you mean RISC-V doesn't meet the other 4 points you mentioned? | 09:26 |
| Hesham | (2): RISC-V supports virtual memory. | 09:31 |
| Hesham | Not sure what do you mean by (3), but there is both a complete FPGA implementation and a toolchain for RISC-V https://github.com/ucb-bar/rocket https://github.com/ucb-bar/fpga-zynq | 09:33 |
| ysionneau | FPGA implementation of risc-v is very very big | 09:47 |
| ysionneau | risc-v is not an option on FPGA afaik | 09:47 |
| ysionneau | openrisc or lm32 are both smaller and more (or as ?) performant as risc-v | 09:47 |
| ysionneau | the interesting thing about risc-v is their ISA | 09:48 |
| ysionneau | but you don't do anything with an ISA | 09:48 |
| ysionneau | you need an implementation to use | 09:48 |
| ysionneau | and right now the FPGA implementation is aweful | 09:49 |
| ysionneau | unless you have a lot of money to make an ASIC out of it, which anyway won't be open source since you will be using proprietary tools and proprietary cell information that the manufacturer won't agree to disclose | 09:49 |
| Hesham | The good thing about RISC-V ISA, is that you can implement it on your own, managing the size as you want. AFAIK, there's Bluespec implementation, and lowRISC is working on some RISC-V minions cores which I believe it will be very small. | 09:50 |
| ysionneau | let's see what comes out :) | 09:51 |
| ysionneau | where is the lowRISC source code? | 09:51 |
| Hesham | Not published yet | 09:51 |
| ysionneau | then it does not exist ;) | 09:51 |
| Hesham | They say it should be available within six months or so. | 09:51 |
| Hesham | But it's a "real" project ;) | 09:52 |
| ysionneau | I don't feel very confortable with "open source project" which don't publish their source right away | 09:52 |
| ysionneau | yes I agree | 09:52 |
| olofk | RISC-V is 64-bit and upwards, so chances are that you will never reach the same size as a 32-bit OpenRISC or LM32 | 09:52 |
| ysionneau | 11:51 < Hesham> They say it should be available within six months or so. < and they said that 6 month ago ? :p | 09:52 |
| ysionneau | opening a github or bitbucket account takes 5 minutes | 09:53 |
| Hesham | ysionneau: I was thinking of the same issue yesterday :) | 09:53 |
| ysionneau | mor1kx is there today, and works very well, and has tons of software support | 09:53 |
| ysionneau | and is really open source | 09:53 |
| Hesham | I think they didn't because they don't have a working prototype yet. | 09:53 |
| ysionneau | I have tons of "work in progress" source code on github | 09:54 |
| ysionneau | which gets reviewed because it's open | 09:54 |
| ysionneau | even if it's not functional yet | 09:54 |
| Hesham | I agree with you actually | 09:54 |
| ysionneau | anyway, let's see what's coming out of it | 09:54 |
| Hesham | I asked them for the code before, but got no clear response | 09:54 |
| olofk | Hesham: They claim that they have done several tapeouts o RISC-V ASICs, so it's probably working in some regard, but if I have understood things correctly they rely on FPGAs and ARM CPUs for all the things outside of the RISC-V core | 09:54 |
| olofk | and several parts of the ISA isn't locked down yet | 09:55 |
| ysionneau | risc-v is working and the source is out already | 09:55 |
| ysionneau | but for lowrisc it's not published so far | 09:55 |
| Hesham | olofk: Great, so they have a prototype! | 09:55 |
| Hesham | Why don't they publish it as ysionneau said? | 09:56 |
| olofk | Hesham: Yes, I believe so, but I haven't really gotten any details | 09:56 |
| ysionneau | Hesham: maybe we can ask juliusb :) | 09:56 |
| olofk | They have received some critisim for not releasing code and docs until they are already finished | 09:57 |
| ysionneau | I think it's pretty common in university/research work | 09:57 |
| ysionneau | to not publish anything until they are happy with the results | 09:57 |
| Hesham | Has RISC-V done the same before publishing their code? | 09:58 |
| Hesham | I mean UC Berkeley... | 09:59 |
| bandvig | Hesham: No, I don't. In fact the (5) is exactly the reason "why not risc-v" for me. I also rejected OpenSPARC (GPLed) and Leon3 (SPARC-V8, GPLed, VHDL). | 10:05 |
| ysionneau | they use Chisel, but AFAIK it generates verilog code | 10:06 |
| ysionneau | but I don't know about the quality of the generated verilog code | 10:06 |
| Hesham | Well, some of my colleagues who worked with the generated Verilog code said it's buggy. | 10:06 |
| Hesham | But lowRISC folks say it's not. Maybe it was buggy for earlier Chisel implementations. | 10:07 |
| bandvig | Hesham: under (3) I mean that implementation could lack of a functionality I need. In the case I'm ready to contribute. | 10:09 |
| Hesham | bandvig: What are the current missing functionalists? | 10:11 |
| Hesham | functionalities* | 10:12 |
| * Hesham BRB | 10:14 | |
| bandvig | Hesham: For today mor1kx it is FPU64. (FPU32 I finished a couple of weeks ago). | 11:05 |
| bandvig | I made the proposal to extend 32-bit arch. Of OpenRISC with FPU64 ISA (http://opencores.org/or1k/Architecture_Specification#ORFPX64A32) | 11:06 |
| bandvig | But right now I’m going to redesign pipeline in the way similar to Beyond Semiconductor’s BA25. The out of order completion is more suitable for incorporation multicycle instructions. | 11:06 |
| bandvig | Hesham: please find my answer I posted erlier. It is already in the log http://juliusbaxter.net/openrisc-irc/%23openrisc.2015-03-30.log.html | 13:08 |
| Hesham | bandvig: Thanks! | 13:09 |
| Hesham | Do you know how many LUTs mor1kxx takes on a specific Xilinx board (without memory, caches, MMU and FPU)? Some comparisons with RISC-V implementation on the same board would be great. | 13:12 |
| bandvig | No, I don't. Actually I'm not focused on LUT. I believe a Cortex-A8/A9 level kernel couldn't be too small. I use FPGA as prototyping platform rather than target. | 13:21 |
| bandvig | However, I got some care about size. As stekern noticed earlier, the OR1200 FPU had got size comparable with other OR1200 while FPU32 is half of rest of mor1kx. | 13:22 |
| Hesham | I see | 13:26 |
| olofk | But LUT/FF numbers is a decent way to compare implementations. I know that we have had some numbers, but I'm not sure where they are | 16:34 |
| Hesham | olofk: It would be great if you can find out about LUT numbers, especially mor1kxx. I need some minimal processor implementation (basically integer operations are enough). | 16:38 |
| olofk | Hesham: Any particular FPGA family? | 16:40 |
| Hesham | Well, we have Zynq and Virtex boards here, maybe ZC706 to compare between Rocket-Chip and mor1kxx? | 16:42 |
| olofk | ZC706 has a Zynq7045 IIRC | 16:43 |
| Hesham | Yeah and it's supported by Rocket Chip. | 16:43 |
| olofk | aha | 16:43 |
| olofk | That should be a good fit then | 16:43 |
| Hesham | I think FuseSoC doesn't have support for building on this board? | 16:44 |
| olofk | It sucks that 7045 isn't supported by the free ISE license though | 16:44 |
| olofk | Hesham: No. Don't think anyone with access to one has made a fusesoc port | 16:44 |
| olofk | And it's always more tricky for boards where you need a paid license :/ | 16:44 |
| Hesham | Another option is my Atlys board, but I'll have to figure out how to get Rocket Chip on it | 16:44 |
| Hesham | But IIRC the current FuseSoC/Atlys support is broken. | 16:45 |
| olofk | I tried building it about an hour ago and noticed that it tries to access a file that doesn't exist | 16:45 |
| olofk | But when I removed that from the .core file it built just fine | 16:46 |
| Hesham | Yeah it builds, but it doesn't run baremetal hello world | 16:46 |
| olofk | ah | 16:46 |
| Hesham | I tried it last summer | 16:46 |
| olofk | Hmm | 16:46 |
| olofk | Do you remember what the problem was? Were you able to connect a debugger? | 16:47 |
| Hesham | I don't remember, maybe I can give it a try today later when I go home. | 16:48 |
| olofk | I would be very interested. It sucks to have broken ports in orpsoc-cores | 16:48 |
| olofk | Maybe I should get a new Atlys. | 16:48 |
| Hesham | OK then, I'll go home now with my board, that will be my tonight task. | 16:49 |
| Hesham | Will keep you noted with the issues. | 16:50 |
| olofk | Awesome | 16:50 |
| Hesham | See you later. Gotta go. | 16:50 |
| olofk | Hesham: Rough estimation after synthesis. 2900 LUTS and 1500 FFs for a Spartan 6 | 17:55 |
| Hesham | olofk: Thanks, what are the cores there? | 17:56 |
| Hesham | I am trying to build fusesoc for atlys board, got this error: "INFO: Preparing mor1kx | 17:57 |
| Hesham | ERROR: Cannot find rtl/verilog/pfpu32/pfpu32_addsub.v in" | 17:57 |
| olofk | Hesham: That was just for mor1kx | 17:58 |
| Hesham | Yeah | 17:58 |
| Hesham | With the FPU right? | 17:59 |
| olofk | Hesham: Hmm... try to update orpsoc-cores ("fusesoc update" should do that for you) | 17:59 |
| olofk | Or just a git pull in your orpsoc-cores | 17:59 |
| olofk | Or remove mor1kx from your cache and try again | 18:00 |
| olofk | Roughly the same number for a Zynq 7020 (2800 LUTs, 1400 FFs) | 18:01 |
| Hesham | olofk: I'm using the latest revisions, just forked them now. This is for orpsoc https://github.com/openrisc/orpsoc-cores | 18:04 |
| Hesham | Still getting the same error | 18:04 |
| Hesham | I'll have to figure out what's wrong | 18:05 |
| olofk | Does the file exist in ~/.cache/fusesoc/mor1kx/rtl/verilog/pfpu32 ? | 18:05 |
| Hesham | Perfect, removing mor1kxx from cache made it. | 18:06 |
| Hesham | Thanks | 18:06 |
| olofk | Ahh.. I have missed adding "cachable = false" to mor1kx.core | 18:07 |
| Hesham | olofk: Another error > Cannot find bench/orpsoc_tb.v in | 18:09 |
| Hesham | Should it be wb_sdram_ctrl_tb.v ? | 18:09 |
| olofk | Hesham: Yes. That's the error I noticed earlier today. Remove tb_private_src_files and the two files listed there | 18:10 |
| olofk | Pushed a fix for that now | 18:10 |
| olofk | ...and now mor1kx isn't cached anymore | 18:13 |
| Hesham | I removed the cache files and building again.. | 18:13 |
| bandvig | olofk: could you clarify the configuration for mor1kx synthesis? | 18:15 |
| olofk | bandvig: Just added a wrapper to mor1kx with the following content http://pastebin.com/9Sj7craX | 18:19 |
| olofk | And a .system file that look something like this http://pastebin.com/cV5XKi5h | 18:20 |
| olofk | And a .core file with just the wrapper and a dependency on mor1kx | 18:20 |
| bandvig | olofk: it looks you forgot to disable instruction MMU to get minimum config. | 18:23 |
| olofk | bandvig: I thought that was disabled by default, but I might have missed it | 18:24 |
| olofk | ohh.. but I explicitly enabled it. Whoops :) | 18:25 |
| Hesham | olofk: Don't say that I should build again without immu :/ | 18:26 |
| olofk | Hesham: I'll give you the new numbers soon and you can see if you think it's worth rebuilding | 18:27 |
| Hesham | Don't worry about numbers now, I just need a baremetal hello world working on Atlys as a start | 18:28 |
| olofk | 1400 FFs, 2600 LUTs. No biggie | 18:29 |
| Hesham | Without immu? | 18:29 |
| olofk | yep | 18:29 |
| Hesham | Great | 18:29 |
| olofk | For a Zynq | 18:29 |
| Hesham | FPU is included? | 18:29 |
| olofk | Nope | 18:29 |
| Hesham | Caches? | 18:29 |
| olofk | Nope | 18:30 |
| Hesham | Perfect :) | 18:30 |
| olofk | You got a few optional instructions though, so it can be made a bit smaller | 18:30 |
| olofk | I guess stekern is the minimification expert here | 18:30 |
| Hesham | So there wouldn't be any cache/MMU related initialization code right? | 18:30 |
| Hesham | SW code.. | 18:30 |
| bandvig | olofk: Hesham: :) btw, I also should remind that for fair comparision we also should decide how configure divider, multiplier and shifter and perhaps some other circuits :))) | 18:30 |
| olofk | bandvig: Yeah, I chose a serial divider. Didn't bother looking att the barrel shifter and stuff | 18:31 |
| olofk | Hesham: I'm not sure how the sw initialization is done. It might be that the cache init code is always compiled but never run if caches are disabled. wallento and other people probably know more | 18:32 |
| Hesham | I am a newbie to mor1kxx and hardware tools, so I'll have to learn how they work first. | 18:32 |
| bandvig | :) and switch off involving DSP modules, I think :)) | 18:32 |
| olofk | Hesham: First lesson. Assume they don't work :) | 18:32 |
| olofk | bandvig: Yeah, it's a bit tricky to get accurate numbers here. I see that mor1kx stole three DSP slices :) | 18:33 |
| Hesham | olofk: No SW exceptions for undefined instructions or writing to wrong addresses? | 18:33 |
| olofk | Hesham: Not a fucking clue :) | 18:33 |
| Hesham | I hope assuming they don't work would be enough | 18:34 |
| olofk | Hesham: There are probably some compile flags you can play around with. If you want it really tiny you could disable the standard libs and write your own printf implementation | 18:36 |
| olofk | But using newlib as it is will pull in quite a lot of code I think | 18:37 |
| Hesham | OK. I got orpsoc_top.bit file. I think I will have to re-build the whole or1k toolchain as I believe it's rusty from last summer. | 18:38 |
| olofk | Hesham: I think the pre-built ones supplied by wallento works well if you want to install a precompiled one | 18:39 |
| olofk | http://openrisc.github.io/newlib/ | 18:39 |
| olofk | Anyone with some mad skillz is welcome to make .debs or .rpms out of them | 18:40 |
| olofk | Or an ebuild for us poor Gentoo users | 18:40 |
| olofk | That goes for FuseSoC too btw | 18:40 |
| Hesham | olofk: Link please? | 18:41 |
| Hesham | I can only find newlib repo | 18:41 |
| olofk | http://lis.ei.tum.de/pub-download/openrisc-builds/or1k-elf/release/or1k-elf-latest-ubuntu-14.04-amd64.tgz | 18:42 |
| olofk | It's not newlib, but a toolchain built with newlib as the C library | 18:42 |
| olofk | i.e. a bare-metal toolchain | 18:42 |
| olofk | If you prefer build instructions they are here http://opencores.org/or1k/OpenRISC_GNU_tool_chain#Newlib_toolchain_.28or1k-elf.29 | 18:43 |
| olofk | I ran through them just last week so they should work | 18:43 |
| Hesham | Thanks, I was going to build it from source anyway. | 18:44 |
| olofk | Please let us know how it goes. It's good to know if there are any potential issues with the build instructions | 18:45 |
| Hesham | Sure | 18:46 |
| Hesham | BTW, any news about pushing current or1k gcc upstream? | 18:46 |
| olofk | Not that I know, but I haven't really been involved with that other than nagging people about it :) | 18:50 |
| Hesham | olofk: I see. OK, I'm waiting for the slow download of gcc now. For downloading the images, should I convert the .bit file to .mcs, or what? Any instructions for how this download/boot process work for Atlys? | 18:58 |
| Hesham | I don't want to use the flash memory, data2mem and .bit file download is fine by me. Is that feasible? | 18:59 |
| olofk | Hesham: Use impact and download it directly to the FPGA | 18:59 |
| Hesham | What about the ELF file? | 19:00 |
| olofk | hmm.. | 19:00 |
| olofk | Do you have a JTAG debugger? | 19:00 |
| Hesham | I only have JTAG-USB cable | 19:01 |
| olofk | Hesham: What kind of cable? | 19:01 |
| Hesham | digilent_plugin | 19:01 |
| Hesham | Used it to both download .bit file to microblaze and ELF file. | 19:02 |
| olofk | Do you mean the one built-in to the board? | 19:02 |
| Hesham | Yeah the one that's used to program the board. | 19:02 |
| olofk | Ah yes. Not sure how to do that easiest. This is the situation where my not-yet-finished hex loader would had been great to have | 19:03 |
| olofk | I'm currently working on a small bootloader that allows you to send an ELF in Intel Hex Format through the UART and execute it | 19:03 |
| olofk | Like they do on Arduino more or less | 19:03 |
| Hesham | Isn't there an easy way as with data2mem? | 19:04 |
| olofk | You will need a built-in bootloader that pulls out your ELF from the SPI flash once the FPGA is configured | 19:04 |
| Hesham | XDM is using the same JTAG-USB cable to download the ELF file to microblaze using their debug module. | 19:04 |
| Hesham | Without any SPI/UART stuff. | 19:05 |
| olofk | We do something like that on the Altera boards, but I think that no one has reverse engineered the protocol used by Digilent | 19:05 |
| olofk | Stupid proprietary crap | 19:05 |
| Hesham | What a bitty! | 19:06 |
| olofk | Yeah. It sucks | 19:06 |
| Hesham | So for now I wouldn't be able to get any software running there? | 19:06 |
| olofk | stekern might have a better answer. He's been using the Atlys far more than I have | 19:07 |
| olofk | There are probably more Atlys owners here as well | 19:07 |
| Hesham | *pity | 19:08 |
| olofk | Interested in writing a Intel Hex loader? :) | 19:08 |
| Hesham | How much time would it take? | 19:08 |
| Hesham | Just tell me how to debug/trace it | 19:08 |
| olofk | Not sure how much work it would be. I could push what I got to github | 19:10 |
| olofk | It's probably easiest to debug it in an RTL simulator such as Icarus | 19:10 |
| Hesham | olofk: You mean this one? http://srecord.sourceforge.net/man/man5/srec_intel.html | 19:10 |
| olofk | Yep, that's the format | 19:11 |
| olofk | There's a good wikipedia article for it as well | 19:11 |
| Hesham | Ah, Epiphany is using it as well. | 19:11 |
| Hesham | link please? | 19:12 |
| Hesham | And maybe you would want to push the existing code to github, then I can try | 19:13 |
| olofk | http://en.wikipedia.org/wiki/Intel_HEX | 19:13 |
| olofk | Yeah. I'll push my very incomplete ASM together with some pseudo code | 19:13 |
| Hesham | Perfect, thanks olofk | 19:14 |
| olofk | https://github.com/olofk/or1k-hexloader | 19:18 |
| olofk | I wrote it in asm mainly to avoid using any memory at all | 19:20 |
| olofk | But it's probably an awful lot easier to do it in C | 19:20 |
| olofk | But as it is meant to be implemented directly in on-chip memory it has to be really tiny. Like a few kB at most | 19:21 |
| Hesham | Makes sense. So the hex loader would be the first executing code, right? | 19:24 |
| olofk | Exactly. It would listen to input from the UART | 19:25 |
| Hesham | And how would the ELF file be sent using UART? | 19:26 |
| Hesham | I think there was some digilent utils for that? | 19:27 |
| bandvig | I'm Atlys owner. But I doubt that you like my approach. I use SoC with ROM+SPI_FLASH+ETHERNET+UART+SDRAM. ROM cofigured to perform bootstrap from SPI_FLASH. SPI_FLASH contains U-boot. I convert elf->bin->uboot image and load the uboot image by tftp. Uff... :) | 19:27 |
| Hesham | bandvig: I would definitely love it if there was a tutorial for that :) | 19:28 |
| Hesham | Do you use orpsocv2? | 19:29 |
| olofk | bandvig: Utilizing u-boot would have been my other choice, but why do you need to load u-boot through tftp? Can't you load the elf directly? | 19:29 |
| bandvig | It was log way for me. Most part of the way I went with the guide: http://www.rte.se/blog/blogg-modesty-corex/index Even so it describes orpsocv2, but it could be useful for fusesoc. | 19:32 |
| Hesham | bandvig: And you didn't have to use Jtag debug cable right? | 19:34 |
| Hesham | olofk: I think I'd go for u-boot | 19:37 |
| olofk | If you have a JTAG debugger it's pretty straight forward. Then you can just download the elf with OpenOCD | 19:37 |
| Hesham | For now.. | 19:37 |
| Hesham | Unfortunately I don't have it. | 19:37 |
| olofk | But the absolutely best option would be if we could utilize the onboard Digilent JTAG stuff | 19:38 |
| olofk | Hesham: What? The asm code was almost complete. Just a few lines missing :P | 19:39 |
| bandvig | olofk: I don't load uboot through tftp. I compiled U-boot and put it into SPI-FLASH on atlys board with Digilent's "Adapt" soft startig from address 0x??? (don't rememdber exactly, buth the address must corresponde to hardcoded into BOOT-ROM) | 19:39 |
| olofk | bandvig: Yeah, but I got the impression that you loaded a new u-boot image with an embedded elf file from tftp | 19:39 |
| olofk | But that was not what you meant, right? | 19:40 |
| Hesham | olofk: Would you write these few lines then? ;) | 19:41 |
| olofk | :) | 19:42 |
| Hesham | It will take sometime for me to grasp srec format and the assembly code, and how to use Icarus. | 19:43 |
| bandvig | olofk: Oh! The blog I mentioned above stays that it is possible to load elf without any conversions. I tried do it. But it didn't work now. Only elf->bin->uboot image works. I don't know the reason. | 19:45 |
| olofk | bandvig: Yeah, I've loaded Linux through tftp with u-boot like that on an old OpenRISC board | 19:48 |
| olofk | Might be something simple like it's failing to set the reset address or something like that | 19:48 |
| olofk | But you're pretty blind at that point so it's hard to tell what's going wrong | 19:49 |
| olofk | hmm.. just thought of something. Can u-boot load over zmodem? That would spare us from using tftp and ethernet | 19:51 |
| olofk | Ah.. I see that it does support ymodem at least | 19:53 |
| olofk | zmodem isn't supported yet. I can understand that. It takes some time to support these new fancy protocols from 1986 | 19:54 |
| * olofk is waiting for FPGAs to be a bit bigger so we can just embed u-boot directly in onchip RAM | 19:55 | |
| bandvig | olofk: of course using OR1K port of U-boot it is possible to load an image through UART (Kermit as far as I remember) avoiding ETHERNET and tftp. But it is too slow for image like Linux. So I use tftp for any casse :) | 19:56 |
| olofk | Sorry _franck_ . I mean barebox of course | 19:56 |
| olofk | Yeah, that's of course a good reason, but for small files it might be a bit easier to set up | 19:57 |
| bandvig | I tried loading by UART. It worked. | 19:59 |
| olofk | bandvig: Cool. That's good to know | 20:02 |
| Hesham | Toolchain builds fine. | 21:04 |
| olofk | Hesham1: Thanks. Good to know | 21:08 |
| -!- Hesham1 is now known as hesham | 21:11 | |
| hesham | olofk: Are these two command for generating bootable mcs file are still valid with generated fusesoc atlys .bit file? | 21:24 |
| hesham | bitgen -w -intstyle silent -g StartUpClk:CClk orpsoc_top orpsoc_spiboot.bit | 21:24 |
| hesham | promgen -spi -p mcs -w -o orpsoc.mcs -s 16384 -u 0 orpsoc_spiboot.bit -data_file up 1c000 u-boot-bsw.bin | 21:24 |
| hesham | I got no output when programming the flash the the final orpsoc.mcs file. | 21:25 |
| hesham | bitgen -w -intstyle silent -g StartUpClk:CClk orpsoc_top.ncd orpsoc_spiboot.bit | 21:26 |
| olofk | hesham: You need a bootloader built into the FPGA that pulls out u-boot from the Flash | 21:36 |
| olofk | If you are using the default bootloader from the FuseSoC Atlys system I highly suspect that it won't do the job for you | 21:36 |
| olofk | Nope. I see now that the built-in bootloader just does an endless loop | 21:37 |
| olofk | Someone got the SPI loader from orpsocv2 working with the de0 nano system quite recently. Was it me1234 perhaps? | 21:38 |
| hesham | olofk: I was about to ask | 21:38 |
| olofk | Time to sleep here unfortunately, but I'll try to help out more tomorrow | 21:39 |
| hesham | I got it u-boot working before with orposocv2 | 21:39 |
| hesham | olofk: Good night, see you tomorrow. Thanks for your help. | 21:39 |
| --- Log closed Tue Mar 31 00:00:45 2015 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!