IRC logs for #openrisc Monday, 2015-03-30

--- Log opened Mon Mar 30 00:00:44 2015
DarkFoxolofk: I'll have to check this one out - I have indeed, seen references to it. Thanks03:56
DarkFoxMore 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
stekernDarkFox: that's because the risc-v "why not openrisc" question answers the question why they didn't choose to build upon the already existing openrisc04:21
DarkFoxstekern: That isn't what I'm asking. I'm responding to that question asking "why not risc-v" ?04:22
DarkFoxThey already answered why risc-v over openrisc; but failed to include why openrisc over risc-v.04:23
daliasyeah i'd be interested in hearing the openrisc side too :)04:23
daliasfrom what i've seen of both i like risc-v better04:24
stekernyes, I understand that, I'm just explaining the reason why you haven't seen the answer04:24
DarkFoxFrom what I've seen - there isn't an answer :(04:24
DarkFoxdalias: 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
DarkFoxTwo reasons *04:26
dalias*sigh* crashed my firefox04:27
DarkFoxdalias: jor1k? :P04:27
daliasno opening the risc-v rationale pdf :)04:27
daliasbut it's great. i dropped my swap down to 768M04:27
DarkFoxjor1k vs angel; jor1k <304:27
daliasso 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 :P04:28
stekernand, yes, I agree, risc-v is nicer in a lot of aspects. There's a lot of old ugly baggage in the or1k arch04:28
stekernbut GPL?04:28
DarkFoxstekern: So you argue that GPL is better? :P04:29
stekernnot at all04:29
DarkFoxGood; no flame war here :D04:29
stekernthat's only relevant for implementations, not architectures04:29
stekern...and our current main implementation is not GPL anyway04:30
DarkFoxOne thing I'd like to do is run 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
DarkFoxstekern: Which is that and what license?04:31
DarkFoxLicense too long :C04:32
* DarkFox hugs MIT/bsd/etc :P04:32
stekernyeah, I agree. All cores I've done from scratch is BSD04:33
* DarkFox still yet to do such.... need a good development system - and don't have that :(04:34
DarkFoxLong 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
stekernbut 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
DarkFoxstekern: I do agree with this... What about a merge? :P04:37
stekernwhich means that it's all open arms for anyone to take a significant role in the project04:37
DarkFoxI 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
DarkFoxWhat would you recommend? (OpenRisc or Risc-v)04:40
DarkFoxFor an idea for the crypto load - just consider tor :P04:42
stekernif you are going to run it on an FPGA, openrisc, afaik the risc-v project haven't released any implementation targeted for that yet04:42
stekernif you're hoping for asics, risc-v04:42
DarkFoxHoping for ascis.. if cheap enough while RPGA does enable lots more flexibilties to the end-users.04:43
DarkFoxAlso; not any time soon for hardware here*04:44
DarkFoxLots of software to do :P04:44
DarkFoxI'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
DarkFoxstekern: Why would asics exist for risc-v but not fpga? Isn't FPGA the pre-asic development stage? Why no FPGA? o.004:46
stekernyou can run it on an FPGA, but it's not targeted for it04:47
DarkFoxSo it was optimized for asic and fpga pre-asic designs purged? o.004:48
stekernyou can put it that way04:48
daliasthere should be risc-v fpga implementations sometime middle of this year04:49
DarkFoxDamn .. Why can't these projects just merge? :D04:49
daliasaccording to lowrisc.org04:49
DarkFoxdalias: That's cool04:49
daliasbut asic is the main target (aiming to have them available sometime next year)04:49
stekernfor instance, their "rocket" core use CAM for their TLB's. That's something that doesn't translate well to FPGA block ram04:50
daliaspart of how the mmu works04:50
stekernso it's a conscious choice04:51
daliasmy impressions so far:04:51
DarkFoxSo 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-watt04:53
dalias- risc-v isa admits more efficient compiled code gen04:53
dalias(e.g. it has efficient ways of doing 32-bit-pc-relative addressing, conditional branches, etc)04:54
daliasrisc-v looks like it was designed by people who understand the ABI requirements for modern compiled position-independent code04:54
DarkFoxOkay; so risc-v it is. \o/04:56
DarkFoxI guess I could always make it compabible with both archetectures; already want it to work on x86, arm, or1k, and now risc-v :P04:57
daliasthere's really no reason it can't be compatible with both04:57
daliasmost of the software should be C or other high-level langs04:57
DarkFoxAll of my code - ideally... will be rust.04:58
daliasah ok04:58
daliaswell then you need the compiler to be able to generate code for either or both :-)04:58
DarkFoxSo - so long that rust can compile through llvm for the architecture; it should be fine (and then boot specifics and drivers...)04:58
olofkDarkFox: And FYI, people have done ASIC implementations of OpenRISC for over 10 years04:58
daliasi suspect initial support for both is via gcc/binutils, not llvm04:58
DarkFoxRust uses both iirc04:59
daliasolofk, neat. links to any commercially availabls asic boards/socs?04:59
olofkI would like to put it this way. If you are targetin FPGA, want 32-bit and want something that is available today, go for OpenRISC04:59
olofkIf you are cool with waiting for a RISC-V ASIC and require 64-bit, go for RISC-V05:00
* DarkFox the latter05:00
daliasolofk, 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
DarkFoxdalias: Custom cores05:00
olofkdalias: Not really, but I know that stekern made the OpenRISC inside is allwinner-A10 chipset run some code :)05:00
daliasdarkfox, doesn't "custom cores" mean something like what i said?05:01
olofkdalias: Volume. If you require a custom implementation you would ned to sell millions of units to make it worth doing a ASIC05:01
DarkFoxdalias: I guess so; also more modifications and maybe custom instructions may be desired05:01
olofkAh sorry. That's what you said :)05:01
daliase.g. if you're doing hashing (like bitcoin mining ;-) and just want the cpu to control the process, then fpga makes a lot of sense05:02
DarkFoxFor confirmation; asic is much cheaper than fpga when finalised correct?05:02
daliasor 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
olofkTime to market is another thing. Many companies put out products with FPGA and do an ASIC spin later on05:03
DarkFoxFair enough05:03
daliasdarkfox, fpga = C*n where C is a moderately large constant. asic = M+ε*n where M is a huge constant and ε is a tiny constant05:04
olofkGot to run05:04
daliasolofk, did i get that approximately right? :)05:04
DarkFoxdalias: Is that for quantity available for general fpga vs exact-order asic?05:05
daliasboth are expressions for cost :)05:05
DarkFoxOkay 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
daliasbasically ASIC has a huge startup cost for production that's not going to make sense unless you can use millions of them05:08
daliasbut then each unit is dirt cheap05:08
daliaswhereas 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 expensive05:09
* DarkFox intends to do fpga for dev/prototype and kickstarter(or similar) for asic/production05:12
DarkFoxBut that'll be a while away still :)05:12
daliasi really should do some project with musl that aims to be popular to a wide audience and kickstarter it05:18
DarkFoxThanks everyone who discussed the pros/cons for these architectures - and their futures.05:18
DarkFoxdalias: +105:18
daliasbecause it's hard to get funding for low-level systems infrastructure stuff :(05:19
DarkFoxI vote something with widespread use of cryptography on alpine or sabotage or custom (linux,bsd,rtos,etc).05:19
DarkFoxdalias: Sadly; indeed. :(05:20
DarkFoxHas 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
DarkFoxAppears that the results on youtube are prooving yes :D05:36
DarkFoxstekern: Nice05:37
olofkThere's a lot of talk about Intel buying Altera. I wonder if that will happen06:12
DarkFoxI sure hope not...06:18
DarkFoxImagine if.... Intel went as open as opencores...06:19
olofkI would like to have x86 + FPGA. I find it a bit scary that ARM has such large dominance in the embedded market06:21
olofkSame as with Intel on the desktops for the last 20 years06:22
DarkFoxolofk: x86+FPGA; IIRC ... xeon?06:22
olofkAnd I would say that Intel is as good as ARM when it comes to Open Source.06:22
olofkoh right. Forgot about those06:23
DarkFoxDrivers are sane; hardware closed :(06:23
DarkFoxolofk: And I'm the software guy :P06:23
olofkYeah. Sounds like both ARM and Intel :)06:23
olofkBut Intel at least have better reputation when it comes to graphics drivers06:24
DarkFoxolofk: OpenCores does it right :P06:24
DarkFoxGPL, BSD, etc. <306:24
olofkAnyone familiar with exFAT?06:38
DarkFoxolofk: Is that the one with windows drivers?06:53
olofkYep. Microsof stuff. Required for newer SD cards :(06:56
DarkFoxIsn't that the half ext4 half fat?06:57
DarkFoxFor what I can remember; it works well on all systems and is much better than fat06:58
DarkFoxolofk: For filesystems; I personally vote either zfs or ram/tmpfs :P07:04
DarkFoxjor1k: 100MIPS = 1e8 (100 million) instructions per second; aka 100Mhz ?07:30
amshz has nothing with instructions per second.07:38
DarkFoxErm: I'm thinking fpga07:39
DarkFoxNot instructions but yea...07:40
amsstill has nothing to do with how many instructions can be exeucted per second.07:40
DarkFoxI still mixed things :)07:41
DarkFoxTechnically it is 100Mhz - just not clock cycles nor the standard way to represend it (Hz is just frequency)07:41
DarkFox138MIPS for "Safe Core (slow)" and 102.8MIPS for "asm.js" - That "(slow)" is questionable.... Is faster o.007:46
DarkFox142MIPS even07:46
* DarkFox wonders how hard it would be to port risc-v to jor1k08:52
bandvigHello 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) level09:18
bandvig(2) Support virtual memory and multicore09:18
bandvig(3) Should be already implemented (perhaps not completely) as for FPGA or ASIC. A tool chain should be already available09:19
bandvig (4) License should be BSD-like or LGPL09:19
bandvig(5) HDL should be Verilog09:19
bandvigThe only OpenRISC meets all my requirements09:19
Heshambandvig: 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
HeshamNot sure what do you mean by (3), but there is both a complete FPGA implementation and a toolchain for RISC-V
ysionneauFPGA implementation of risc-v is very very big09:47
ysionneaurisc-v is not an option on FPGA afaik09:47
ysionneauopenrisc or lm32 are both smaller and more (or as ?) performant as risc-v09:47
ysionneauthe interesting thing about risc-v is their ISA09:48
ysionneaubut you don't do anything with an ISA09:48
ysionneauyou need an implementation to use09:48
ysionneauand right now the FPGA implementation is aweful09:49
ysionneauunless 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 disclose09:49
HeshamThe 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
ysionneaulet's see what comes out :)09:51
ysionneauwhere is the lowRISC source code?09:51
HeshamNot published yet09:51
ysionneauthen it does not exist ;)09:51
HeshamThey say it should be available within six months or so.09:51
HeshamBut it's a "real" project ;)09:52
ysionneauI don't feel very confortable with "open source project" which don't publish their source right away09:52
ysionneauyes I agree09:52
olofkRISC-V is 64-bit and upwards, so chances are that you will never reach the same size as a 32-bit OpenRISC or LM3209:52
ysionneau11:51 < Hesham> They say it should be available within six months or so. < and they said that 6 month ago ? :p09:52
ysionneauopening a github or bitbucket account takes 5 minutes09:53
Heshamysionneau: I was thinking of the same issue yesterday :)09:53
ysionneaumor1kx is there today, and works very well, and has tons of software support09:53
ysionneauand is really open source09:53
HeshamI think they didn't because they don't have a working prototype yet.09:53
ysionneauI have tons of "work in progress" source code on github09:54
ysionneauwhich gets reviewed because it's open09:54
ysionneaueven if it's not functional yet09:54
HeshamI agree with you actually09:54
ysionneauanyway, let's see what's coming out of it09:54
HeshamI asked them for the code before, but got no clear response09:54
olofkHesham: 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 core09:54
olofkand several parts of the ISA isn't locked down yet09:55
ysionneaurisc-v is working and the source is out already09:55
ysionneaubut for lowrisc it's not published so far09:55
Heshamolofk: Great, so they have a prototype!09:55
HeshamWhy don't they publish it as ysionneau said?09:56
olofkHesham: Yes, I believe so, but I haven't really gotten any details09:56
ysionneauHesham: maybe we can ask juliusb :)09:56
olofkThey have received some critisim for not releasing code and docs until they are already finished09:57
ysionneauI think it's pretty common in university/research work09:57
ysionneauto not publish anything until they are happy with the results09:57
HeshamHas RISC-V done the same before publishing their code?09:58
HeshamI mean UC Berkeley...09:59
bandvigHesham: 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
ysionneauthey use Chisel, but AFAIK it generates verilog code10:06
ysionneaubut I don't know about the quality of the generated verilog code10:06
HeshamWell, some of my colleagues who worked with the generated Verilog code said it's buggy.10:06
HeshamBut lowRISC folks say it's not. Maybe it was buggy for earlier Chisel implementations.10:07
bandvigHesham: under (3) I mean that implementation could lack of a functionality I need. In the case I'm ready to contribute.10:09
Heshambandvig: What are the current missing functionalists?10:11
* Hesham BRB10:14
bandvigHesham: For today mor1kx it is FPU64. (FPU32 I finished a couple of weeks ago).11:05
bandvigI made the proposal to extend 32-bit arch. Of OpenRISC with FPU64 ISA (
bandvigBut 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
bandvigHesham: please find my answer I posted erlier. It is already in the log
Heshambandvig: Thanks!13:09
HeshamDo 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
bandvigNo, 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
bandvigHowever, 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
HeshamI see13:26
olofkBut 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 are16:34
Heshamolofk: 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
olofkHesham: Any particular FPGA family?16:40
HeshamWell, we have Zynq and Virtex boards here, maybe ZC706 to compare between Rocket-Chip and mor1kxx?16:42
olofkZC706 has a Zynq7045 IIRC16:43
HeshamYeah and it's supported by Rocket Chip.16:43
olofkThat should be a good fit then16:43
HeshamI think FuseSoC doesn't have support for building on this board?16:44
olofkIt sucks that 7045 isn't supported by the free ISE license though16:44
olofkHesham: No. Don't think anyone with access to one has made a fusesoc port16:44
olofkAnd it's always more tricky for boards where you need a paid license :/16:44
HeshamAnother option is my Atlys board, but I'll have to figure out how to get Rocket Chip on it16:44
HeshamBut IIRC the current FuseSoC/Atlys support is broken.16:45
olofkI tried building it about an hour ago and noticed that it tries to access a file that doesn't exist16:45
olofkBut when I removed that from the .core file it built just fine16:46
HeshamYeah it builds, but it doesn't run baremetal hello world16:46
HeshamI tried it last summer16:46
olofkDo you remember what the problem was? Were you able to connect a debugger?16:47
HeshamI don't remember, maybe I can give it a try today later when I go home.16:48
olofkI would be very interested. It sucks to have broken ports in orpsoc-cores16:48
olofkMaybe I should get a new Atlys.16:48
HeshamOK then, I'll go home now with my board, that will be my tonight task.16:49
HeshamWill keep you noted with the issues.16:50
HeshamSee you later. Gotta go.16:50
olofkHesham: Rough estimation after synthesis. 2900 LUTS and 1500 FFs for a Spartan 617:55
Heshamolofk: Thanks, what are the cores there?17:56
HeshamI am trying to build fusesoc for atlys board, got this error: "INFO:  Preparing mor1kx17:57
HeshamERROR: Cannot find rtl/verilog/pfpu32/pfpu32_addsub.v in"17:57
olofkHesham: That was just for mor1kx17:58
HeshamWith the FPU right?17:59
olofkHesham: Hmm... try to update orpsoc-cores ("fusesoc update" should do that for you)17:59
olofkOr just a git pull in your orpsoc-cores17:59
olofkOr remove mor1kx from your cache and try again18:00
olofkRoughly the same number for a Zynq 7020 (2800 LUTs, 1400 FFs)18:01
Heshamolofk: I'm using the latest revisions, just forked them now. This is for orpsoc
HeshamStill getting the same error18:04
HeshamI'll have to figure out what's wrong18:05
olofkDoes the file exist in ~/.cache/fusesoc/mor1kx/rtl/verilog/pfpu32  ?18:05
HeshamPerfect, removing mor1kxx from cache made it.18:06
olofkAhh.. I have missed adding "cachable = false" to mor1kx.core18:07
Heshamolofk: Another error > Cannot find bench/orpsoc_tb.v in18:09
HeshamShould it be wb_sdram_ctrl_tb.v ?18:09
olofkHesham: Yes. That's the error I noticed earlier today. Remove tb_private_src_files and the two files listed there18:10
olofkPushed a fix for that now18:10
olofk...and now mor1kx isn't cached anymore18:13
HeshamI removed the cache files and building again..18:13
bandvigolofk: could you clarify the configuration for mor1kx synthesis?18:15
olofkbandvig: Just added a wrapper to mor1kx with the following content
olofkAnd a .system file that look something like this
olofkAnd a .core file with just the wrapper and a dependency on mor1kx18:20
bandvigolofk: it looks you forgot to disable instruction MMU to get minimum config.18:23
olofkbandvig: I thought that was disabled by default, but I might have missed it18:24
olofkohh.. but I explicitly enabled it. Whoops :)18:25
Heshamolofk: Don't say that I should build again without immu :/18:26
olofkHesham: I'll give you the new numbers soon and you can see if you think it's worth rebuilding18:27
HeshamDon't worry about numbers now, I just need a baremetal hello world working on Atlys as a start18:28
olofk1400 FFs, 2600 LUTs. No biggie18:29
HeshamWithout immu?18:29
olofkFor a Zynq18:29
HeshamFPU is included?18:29
HeshamPerfect :)18:30
olofkYou got a few optional instructions though, so it can be made a bit smaller18:30
olofkI guess stekern is the minimification expert here18:30
HeshamSo there wouldn't be any cache/MMU related initialization code right?18:30
HeshamSW code..18:30
bandvigolofk: 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
olofkbandvig: Yeah, I chose a serial divider. Didn't bother looking att the barrel shifter and stuff18:31
olofkHesham: 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 more18:32
HeshamI 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
olofkHesham: First lesson. Assume they don't work :)18:32
olofkbandvig: Yeah, it's a bit tricky to get accurate numbers here. I see that mor1kx stole three DSP slices :)18:33
Heshamolofk: No SW exceptions for undefined instructions or writing to wrong addresses?18:33
olofkHesham: Not a fucking clue :)18:33
HeshamI hope assuming they don't work would be enough18:34
olofkHesham: 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 implementation18:36
olofkBut using newlib as it is will pull in quite a lot of code I think18:37
HeshamOK. 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
olofkHesham: I think the pre-built ones supplied by wallento works well if you want to install a precompiled one18:39
olofkAnyone with some mad skillz is welcome to make .debs or .rpms out of them18:40
olofkOr an ebuild for us poor Gentoo users18:40
olofkThat goes for FuseSoC too btw18:40
Heshamolofk: Link please?18:41
HeshamI can only find newlib repo18:41
olofkIt's not newlib, but a toolchain built with newlib as the C library18:42
olofki.e. a bare-metal toolchain18:42
olofkIf you prefer build instructions they are here
olofkI ran through them just last week so they should work18:43
HeshamThanks, I was going to build it from source anyway.18:44
olofkPlease let us know how it goes. It's good to know if there are any potential issues with the build instructions18:45
HeshamBTW, any news about pushing current or1k gcc upstream?18:46
olofkNot that I know, but I haven't really been involved with that other than nagging people about it :)18:50
Heshamolofk: 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
HeshamI don't want to use the flash memory, data2mem and .bit file download is fine by me. Is that feasible?18:59
olofkHesham: Use impact and download it directly to the FPGA18:59
HeshamWhat about the ELF file?19:00
olofkDo you have a JTAG debugger?19:00
HeshamI only have JTAG-USB cable19:01
olofkHesham: What kind of cable?19:01
HeshamUsed it to both download .bit file to microblaze and ELF file.19:02
olofkDo you mean the one built-in to the board?19:02
HeshamYeah the one that's used to program the board.19:02
olofkAh yes. Not sure how to do that easiest. This is the situation where my not-yet-finished hex loader would had been great to have19:03
olofkI'm currently working on a small bootloader that allows you to send an ELF in Intel Hex Format through the UART and execute it19:03
olofkLike they do on Arduino more or less19:03
HeshamIsn't there an easy way as with data2mem?19:04
olofkYou will need a built-in bootloader that pulls out your ELF from the SPI flash once the FPGA is configured19:04
HeshamXDM is using the same JTAG-USB cable to download the ELF file to microblaze using their debug module.19:04
HeshamWithout any SPI/UART stuff.19:05
olofkWe do something like that on the Altera boards, but I think that no one has reverse engineered the protocol used by Digilent19:05
olofkStupid proprietary crap19:05
HeshamWhat a bitty!19:06
olofkYeah. It sucks19:06
HeshamSo for now I wouldn't be able to get any software running there?19:06
olofkstekern might have a better answer. He's been using the Atlys far more than I have19:07
olofkThere are probably more Atlys owners here as well19:07
olofkInterested in writing a Intel Hex loader? :)19:08
HeshamHow much time would it take?19:08
HeshamJust tell me how to debug/trace it19:08
olofkNot sure how much work it would be. I could push what I got to github19:10
olofkIt's probably easiest to debug it in an RTL simulator such as Icarus19:10
Heshamolofk: You mean this one?
olofkYep, that's the format19:11
olofkThere's a good wikipedia article for it as well19:11
HeshamAh, Epiphany is using it as well.19:11
Heshamlink please?19:12
HeshamAnd maybe you would want to push the existing code to github, then I can try19:13
olofkYeah. I'll push my very incomplete ASM together with some pseudo code19:13
HeshamPerfect, thanks olofk19:14
olofkI wrote it in asm mainly to avoid using any memory at all19:20
olofkBut it's probably an awful lot easier to do it in C19:20
olofkBut as it is meant to be implemented directly in on-chip memory it has to be really tiny. Like a few kB at most19:21
HeshamMakes sense. So the hex loader would be the first executing code, right?19:24
olofkExactly. It would listen to input from the UART19:25
HeshamAnd how would the ELF file be sent using UART?19:26
HeshamI think there was some digilent utils for that?19:27
bandvigI'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
Heshambandvig: I would definitely love it if there was a tutorial for that :)19:28
HeshamDo you use orpsocv2?19:29
olofkbandvig: 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
bandvigIt was log way for me. Most part of the way I went with the guide: Even so it describes orpsocv2, but it could be useful for fusesoc.19:32
Heshambandvig: And you didn't have to use Jtag debug cable right?19:34
Heshamolofk: I think I'd go for u-boot19:37
olofkIf you have a JTAG debugger it's pretty straight forward. Then you can just download the elf with OpenOCD19:37
HeshamFor now..19:37
HeshamUnfortunately I don't have it.19:37
olofkBut the absolutely best option would be if we could utilize the onboard Digilent JTAG stuff19:38
olofkHesham: What? The asm code was almost complete. Just a few lines missing :P19:39
bandvigolofk: 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
olofkbandvig: Yeah, but I got the impression that you loaded a new u-boot image with an embedded elf file from tftp19:39
olofkBut that was not what you meant, right?19:40
Heshamolofk: Would you write these few lines then? ;)19:41
HeshamIt will take sometime for me to grasp srec format and the assembly code, and how to use Icarus.19:43
bandvigolofk: 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
olofkbandvig: Yeah, I've loaded Linux through tftp with u-boot like that on an old OpenRISC board19:48
olofkMight be something simple like it's failing to set the reset address or something like that19:48
olofkBut you're pretty blind at that point so it's hard to tell what's going wrong19:49
olofkhmm.. just thought of something. Can u-boot load over zmodem? That would spare us from using tftp and ethernet19:51
olofkAh.. I see that it does support ymodem at least19:53
olofkzmodem isn't supported yet. I can understand that. It takes some time to support these new fancy protocols from 198619:54
* olofk is waiting for FPGAs to be a bit bigger so we can just embed u-boot directly in onchip RAM19:55
bandvigolofk: 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
olofkSorry _franck_ . I mean barebox of course19:56
olofkYeah, that's of course a good reason, but for small files it might be a bit easier to set up19:57
bandvigI tried loading by UART. It worked.19:59
olofkbandvig: Cool. That's good to know20:02
HeshamToolchain builds fine.21:04
olofkHesham1: Thanks. Good to know21:08
-!- Hesham1 is now known as hesham21:11
heshamolofk: Are these two command for generating bootable mcs file are still valid with generated fusesoc atlys .bit file?21:24
heshambitgen -w -intstyle silent -g StartUpClk:CClk orpsoc_top orpsoc_spiboot.bit21:24
heshampromgen -spi -p mcs -w -o orpsoc.mcs -s 16384 -u 0 orpsoc_spiboot.bit -data_file up 1c000 u-boot-bsw.bin21:24
heshamI got no output when programming the flash the the final orpsoc.mcs file.21:25
heshambitgen -w -intstyle silent -g StartUpClk:CClk orpsoc_top.ncd orpsoc_spiboot.bit21:26
olofkhesham: You need a bootloader built into the FPGA that pulls out u-boot from the Flash21:36
olofkIf you are using the default bootloader from the FuseSoC Atlys system I highly suspect that it won't do the job for you21:36
olofkNope. I see now that the built-in bootloader just does an endless loop21:37
olofkSomeone got the SPI loader from orpsocv2 working with the de0 nano system quite recently. Was it me1234 perhaps?21:38
heshamolofk: I was about to ask21:38
olofkTime to sleep here unfortunately, but I'll try to help out more tomorrow21:39
heshamI got it u-boot working before with orposocv221:39
heshamolofk: Good night, see you tomorrow. Thanks for your help.21:39
--- Log closed Tue Mar 31 00:00:45 2015

Generated by 2.15.2 by Marius Gedminas - find it at!