IRC logs for #openrisc Wednesday, 2015-02-25

--- Log opened Wed Feb 25 00:00:56 2015
-!- Netsplit *.net <-> *.split quits: tariq786, mafm, sfa01:16
-!- Netsplit over, joins: sfa, tariq786, mafm01:20
-!- Netsplit *.net <-> *.split quits: blueCmd, rhythmx, ssvb, julzmb, Ptishell, GeneralStupid, kiwichris01:35
-!- Netsplit over, joins: kiwichris, julzmb, ssvb, blueCmd, rhythmx, GeneralStupid, Ptishell01:39
-!- Netsplit *.net <-> *.split quits: blueCmd, rhythmx, ssvb, julzmb, Ptishell, GeneralStupid, kiwichris01:40
-!- Netsplit *.net <-> *.split quits: sheridp01:40
-!- Netsplit over, joins: kiwichris, julzmb, ssvb, blueCmd, rhythmx, GeneralStupid, Ptishell01:41
stekernolofk: I've had an off-list discussion with jonas that I'll step in as co-maintainer while he's too busy to properly maintain the openrisc01:48
stekernand to be clear, he initiated the discussion01:52
-!- Netsplit *.net <-> *.split quits: sheridp02:10
-!- Netsplit over, joins: sheridp02:16
olofkstekern: That's great.07:16
Me1234_Why does this happen after linux is working on de0_nano for some time ?15:01
Me1234_And, It seems that SPI flash gets rewritten somehow. Next boot shows these errors, but somehow works.15:03
Me1234_Actually SPI flash contents do NOT get rewritten.15:07
Me1234_I powewed it off for too small period of time, so ram did not discharge.15:08
Me1234_But it does not solve this question:15:15
Me1234_Why does this happen after linux is working on de0_nano for some time ?15:15
olofkMe1234_: Never seen that one before.17:18
amsolofk: got a sec_17:55
sheridp1I noticed that when compiling my bootloader for the openrisc, it does not matter what I set the ORIGIN to be in my linker script; then I read that when using objcopy (to generate a bin file from elf) "All symbols and relocation information will be discarded."  Does anyone know if this is the reason?18:09
GeneralStupidmy Altera DE-2 Board is there :)18:19
Me1234_olofk: Now ok, when recompiled busybox with or1k-linux-gnu-gcc18:20
GeneralStupidWhich one is a good core implementation?18:34
GeneralStupidshoud i use trunk?18:34
GeneralStupidplease give me a start point... what does i need to use newlib and openrisc on my altera board?18:42
sheridp1GeneralStupid: What are your performance/area constraints.  I'm using a Spartan6 so I need a smaller design, and have been using the AltOR32 implementation.18:43
GeneralStupidsheridp1: i have 35000 LEs and 8Mb RAM18:44
sheridp1That's a fairly sizeable FPGA; I think you could implement the full pipelined openrisc processor18:50
GeneralStupidit is an DE2 development board from terasic18:50
GeneralStupidwhat i want is the wishbone bus (for "slaves") and one Master18:50
sheridp1OR is wishbone compatible18:51
sheridp1You might want to checkout FuseSOC (newer but less documented) or MinSOC if you want to get a complete system up and running18:52
GeneralStupidsheridp1: first of all i need some introduction how that git repo is organized18:55
sheridp1Try googling it:  there is plenty of documentation18:57
GeneralStupidwhats the different between fusesoc and minsoc?18:58
GeneralStupidthey are both different implementations from openrisc?18:58
sheridp1those projects are focused on rapid SOC development18:58
sheridp1The idea is that you can plug and play WB compatible components19:00
GeneralStupidWB means wishbone?19:00
sheridp1there's also which is based on the mor1kx implementation of OpenRISC19:01
sheridp1The difference between these projects is which processor implementation they use. mor1kx I think is a rewrite of the OR1200, and is configurable to have a 0, 3 or 5 stage pipeline19:02
sheridp1I think fuseSOC is an attempt to standardize these systems so that you can use a simple configuration script and build an SOC.  It's a great idea, but at the moment, I found the lack of documentation a deterrent19:03
GeneralStupidso they try to develop fusesoc that it is more like the leon19:04
sheridp1I'm not familiar with LEON, except that it is based on the SPARC ISA, but I thought it was just one processor design whereas fuseSOC allows plugging in different processors19:06
GeneralStupidok what i need to know is....19:07
GeneralStupidThe minsoc is _one_ implementation, and a well documentated one?19:07
sheridp1I think so, but your mileage may vary. I had some trouble installing minsoc -- library dependencies were outdated, so I gave up and decided on the AltOR32 implementation from ultraembedded19:10
GeneralStupidis it easy to access e.g. the display ?19:12
sheridp1using what?  I never got minsoc to work. For my altor32 system, I don't have a display, but you can probably find a display module on and connect it to the wishbone bus19:13
GeneralStupidok :)19:14
GeneralStupidthe install script from minsoc is not accessible19:14
sheridp1Are you just trying to get _any_ system up and running or are you interested in openrisc specifically19:15
GeneralStupidiam interested in any system which is open source and has a Bus system for co processors19:16
GeneralStupidi want to use newlib. I think openrisc fits best19:16
sheridp1Well for what its worth, you can check out or my own repo and base your design off that19:19
sheridp1But I think the mor1kx will offer better performance19:21
sheridp1I just found
sheridp1which is a mor1kx on a DE0 nano board; you could probably modify that pretty easily19:21
GeneralStupidsheridp1: thats a good starting point i guess19:23
sheridp1OK, so my gut feeling is this:  objcopy ignores ORIGIN from the linker_script, moving everything to 0x0, and then the .org commands are followed.  Nonetheless, the ORIGIN command is needed if the linker produced any position-dependent code such as jumping to an immediate value, and you need to actually store the objcopied code beginning at ORIGIN.19:53
olofkams: Here now20:06
olofksheridp1: objcopy doesn't move things to zero. I know this because I spent a lot of time trying to actually move everything to zero without success :)20:07
amsolofk: i need to stroke your beard for ideas.20:07
amsi.e. i need 10 minutes of your time, in private. >:)20:08
sheridp1olofk:  so if you take a look at the output of objcopy -O binary using xxd, you'll find that the code begins at the first .org rather than ORIGIN + .org; essentially everything is shifted back by ORIGIN when compared to the lst file20:09
olofkams: Well, in that case you're fucked
olofkDon't worry. I look like a retard, so it's growing back20:11
olofksheridp1: Do you have an elf you can share?20:38
sheridp1Sure, just a minute20:39
sheridp1How should I share it with you?20:41
olofksheridp1: You can mail to olof.kindgren@gmail.com20:43
Me1234_How can I use GPIO driver from linux 3.18 on linux 3.19. I compiled it as a module, When I load it, leds do not blink,howewer they are enabled in dts and kernel config20:58
GeneralStupidi cant just install some libs.. i need some background informations on this...21:06
olofkMe1234_: And it works in 3.18 with the same FPGA image?21:07
sheridp1Has anyone tried -Wl,--gc-sections with or1k gcc?  I'm finding that it stripped everything but the .bss out of the elf. Maybe it's not supported?21:18
olofksheridp1: I vaguely recall that there was some bug regarding --gc-sections, but I think that was fixed21:24
GeneralStupidolofk: you work on fusesoc, right?21:26
sheridp1olofk:  thanks, I think I'll just avoid it for the time being21:29
olofksheridp1: Reading the files you sent me, I realize that you probably know several times as much about elf and linkers than I do :)21:31
olofkSo I'm not sure how helpful I can be. I would have assumed that start would end up at 0x2ee8, but it looks like it's at 0x0 in the bin. That was your issue, right?21:33
sheridp1olofk:  definitely not, tbh I'm usually a python developer so all this is foreign to me, but I'm learning21:34
olofkGeneralStupid: Yes I do. Released FuseSoC 1.2 yesterday btw21:34
sheridp1Yeah, in the bin it ends up at .org rather than ORIGIN + .org; which is fine; just a curiosity.  But I'm guessing you have to load the code at 0x2ee8 and not 0x00 (or anywhere else) in case their is position-dependent instructions21:35
olofksheridp1: Yeah, I'm learning too. Lots of fun, combined with a lot of what-the-hell-is-going-on moments21:35
olofksheridp1: Just to get this straight, if the code is position independent, there's nothing to worry about, right?21:37
GeneralStupidolofk: is this stable and where do i find the configurator of this?21:37
olofkGeneralStupid: FuseSoC generally works fine for creating OpenRISC-based SoCs. There are a few ready-made systems available. Not for de2, but for both de0_nano and de1. I guess those would be your starting points21:39
sheridp1olofk:  I would think so because then all the jumps/branches would be relative to the PC; but if you had something like jmp <target>  where target was at some fixed location or e.g. grabbing some data that was supposed to be at a fixed location; then if you loaded the code at the wrong spot, it would jump/grab from the wrong location21:39
sheridp1actually, my code worked even without compiling with -fPIC, but I think I was just lucky in that, because the code is so short, it always chose to do things relative to the PC anyway21:40
olofkHmm.. is there some quick way to test that? Maybe you could define a global variable and put that in its own section21:42
olofkCome to think of it, I've probably never defined my own linker script for OpenRISC. Just used the default ones21:42
olofkI see that you're using or1k-nd btw. Does altor32 implement that?21:43
sheridp1yeah, I was trying to think of something, maybe a global variable would work.  I did try doing a little assembly using a l.jr operation, and confirmed that the objcopy does not modify the jump address (which makes sense, how would it know), but let me try with a global variable21:44
sheridp1yes AltOR32 implements the full OR ISA (I think), but does not use a delay slot so you have to compile gcc to not use it (and a whole bunch of other things like multipliers, dividers, etc)21:45
GeneralStupidis there a way to use the altera usb blaster for UART?21:46
Me1234_olofk: Yes, it works with 3.18 (, but does not with 3.19 form Note that in 3.19 I load it after startup, in 3.18 it is in kernel21:46
GeneralStupidAnd most of the links dosnt work anymore21:46
olofkGeneralStupid: We have experimented with running UART over JTAG with a USB Blaster. There seems to be some problems with the interrupts, so it works fine in polling mode, but when the IRQ is enabled, things break down21:51
olofkMe1234_: There have been many patches recently that haven't been upstreamed yet, so I'm not sure if you can use the one from kernel.org21:52
olofkWe have decided that the one on is our official OpenRISC kernel for now. It would be great if you could try that one21:52
Me1234_olofk: 3.19 actually boots.21:53
olofksheridp1: I see. Haven't had time to try out altor32 yet21:53
GeneralStupidi get back to this later21:53
GeneralStupidfusesoc list-systems displays nothing21:53
Me1234_olofk: And works.21:54
olofkGeneralStupid: Unfortunately, the OpenCores SVN has been down for some time, which means that most of the cores that FuseSoC use isn't available.21:54
olofkI need to update the links to our copies on github. Haven't gotten around to do that yet21:54
GeneralStupidis there a fix for me?!21:55
sheridp1olofk:  I know! It's crazy; I don't know what is up with opencores, but I've noticed that you can often only grab the latest snapshot and nothing older21:55
GeneralStupidThats some of my probs, i wanted to try this one:
GeneralStupidbut its down too21:55
olofkGeneralStupid: The only fix right now is patience21:55
olofksheridp1: We're trying to get their attention, but they are hard to reach sometimes. Good thing we have clones of all repos on github21:56
GeneralStupidwheres the copy of minsoc on github?21:57
olofkMe1234_: Ah.. I just saw that you only loaded it as a module on 3.19. Have you tried to build it into the kernel on 3.19?21:57
olofkGeneralStupid: I think this one should do
olofkGeneralStupid: The minsoc developer (rschmidlin) is usually here at least every week, so you could see if you can catch him21:59
olofkI'll do a mass change of the repo locations tomorrow. Unfortunately my ordinary dev computer is on repair, so I can't do much testing to see that everything works as expected22:00
olofkOh well. This will have to do for tonight. Good luck all of you. Let me know if things magically start to work :)22:02
GeneralStupidolofk: its totally fine, its hard to get into it... But i think you (all the Openrisc guys) had done a lot of work.22:02
GeneralStupidolofk: good night and thx 4 help22:02
GeneralStupidsheridp1: thank you too22:02
olofkNo problems.22:02
sheridp1olofk:  OK I think I've got it--yes you will run into problems if you have position dependent code.  I added a global variable to blink.c and saw from the lst file it's stored at the beginning of the .data section (0x2f24).  Then in start, I increment it and it accesses 2f24 as expected.  In the .bin hexdump however, I can see that it still accesse22:18
sheridp1s 2f24, but the data has been shifted all the way to 3c (which is 0x2f24 - 0x2ee8). Thus if I ran this code, loaded at 0x00, it would still access 0x2f24 and get the wrong value.22:18
sheridp1Also taking an objdump of blink.o shows that the VMA and LMA of everything is 0x0000, whereas in the elf, .data is 0x2f24 so these must get resolved at link-time to produce usable, position-dependent code22:23
sheridp1As a final test, I tried using -fPIC when compiling and it does nothing!  2f24 is still used to access the global variable.  I'm guessing position independent code isn't supported (at least on the altor32)22:32
--- Log closed Thu Feb 26 00:00:57 2015

Generated by 2.15.2 by Marius Gedminas - find it at!