IRC logs for #openrisc Monday, 2014-05-19

--- Log opened Mon May 19 00:00:55 2014
stekernolofk: how about omg-ic as the name for the turing complete interrupt controller?03:41
stekernOpen Multiprocessor Global Interrupt Controller03:42
stekernI think for real, I'll call it ompic03:45
stekern(I'm writing a driver for the IPI part, and I think it03:45
stekern'll make sense to keep everything in the same driver)03:46
olofkhaha. I like it even though it's a pity that you dropped the 'g'04:17
stekernwould it be crazy to use wb_intercon in it internally?05:01
stekernjust thinking, since I've already made the ipi part standalone05:03
stekernblueCmd: did you notice this thread?
stekernit'd be nice if that longstanding 32-bit enum problem would be solved, if that guy doesn't propose a cgen patch, we should do it05:15
olofkstekern: I'm all for code reuse so that sounds like a good idea. Is it wb_mux you're thinking of reusing?06:08
olofkI'm not planning to change anything in the interface, so you should be safe06:21
olofkAnd if I want to change something, I'll make sure to implement versioning support first so that you can point out an older version06:22
stekernI'm mostly worried about using a big bulky bus interface for arbitration between in-core registers ;)06:24
olofkYeah, but most signals are just pass-through06:44
olofkI just routed them through the component to get a cleaner architecture06:45
stekernyes, that's my thought. the wb slave arbitration should be pretty light weight I think06:46
stekernand I like the idea of having the controller parts being stand-alone, that way someone can just pick parts of it and include it in their design06:47
stekernI can't imagine someone wanting to opt-out on the app store though, maybe we should make that mandatory?06:48
olofkYeah that's probably the best way. We could provide it as an obfuscated netlist perhaps so we make sure that no one removes it by mistake06:57
stekernmaybe we can utilize alteras OpenCore system too, and use their time limiting feature to implement opening hours to the app store?07:00
stekernsince that will per se demand a jtag connection, maybe we could use that to connect to the cloud too?07:02
stekernseems the irqchip code in Linux isn't very dynamic07:16
stekernmaybe it's a transitional thing, from what I can see, all the irq controller code have previously been hidden away in the arch/xxx/ dirs somehow before07:18
stekerneven though the irq controllers have been soc specific and not cpu specific07:18
olofkI like how you're thinking. I totally missed the cloud connection07:51
olofkSo do you see any indications that Linux is moving to SoC-specific controllers?07:51
stekernI think that's how the reality is, it's just that the current way to tie in the SoC-specific controllers is cpu-specific...07:55
stekernfor instance, arms gic is a SoC-specific controller, but it's not like it could ever be used on anything else than arm07:56
stekernbecause it ties in to specific code in arch/arm/07:56
stekern(or arch/arm64/)07:56
stekernnow, I don't believe that particular irq controller ever will be used with anything else, but it serves as an example of the weaknesses of the framework (of today)07:57
stekernI think it's a way of thinking that goes through other subsystems too though, that some peripherals will *never* be used on different cpus.07:59
stekern...or at tops, one or two different archs08:00
stekernI think it's partly that kind of thinking that has lead to interesting things like that the DW USB core had three different drivers at some point08:06
stekerniirc, two for two different arm socs and one for a powerpc soc08:07
stekernI'm not entirely sure how I will make the ompic nicely snug into being in between the or1k-pic and the actual irq-lines08:09
stekernmaybe we can name it omg-epic btw08:12
stekernOpen Multiprocessor Generic External Programmable Interrupt Controller08:14
olofkThat's the best thing I have heard, ever!08:22
blueCmdstekern: yes, I saw the thread but my understanding was that 1) the patch was for an autogenerated file and 2) it depends on that our CGEN patch is merged08:24
blueCmdthen possibly a 3) but I don't know what it would be08:24
stekernoh, 1) and 2) was unrelated08:25
stekernthere's a seperate cgen patch needed to solve 1)08:26
blueCmdAh I see08:26
stekernmy point was mostly that there was some response from a cgen guy about your patch though08:27
stekern...and that we should keep our eyes open if that guy presents a solution to 1), if not, we should probably step in and do it at some point08:28
stekernumm, "that guy" in the second sentence being the muller guy that started the thread08:29
blueCmdstekern: did I understand it correctly that they will merge our cgen patch?09:26
stekernthat was actually a bit unclear, but at least it got an "OK" from Frank09:31
stekernI guess Alan have write access to the cgen repo, so maybe he'll just commit it09:32
stekernif not, I guess we'll just have to ping that thread in a while ;)09:32
sb0what's the current status of LLVM support?14:37
blueCmdI think someone wrote a basic port but AFAIK it lacks a lot of stuff15:01
stekernnah, it15:10
stekern's not lacking *lot of stuff*15:10
stekernwhat's lacking is debug symbols and TLS15:11
stekern...and someone that sync it with upstream ;)15:11
blueCmdit has dynamic linking?15:14
blueCmdit has atomics? ;)15:15
stekernif you use the normal binutils15:18
blueCmdoh right15:29
blueCmddoesn't llvm do linking/as ?15:29
stekernit can, and we have support for that in our port (thanks to simoncook), but it can also use external as/ld15:40
blueCmdI see15:40
stekernwell, it at least have assembling support, linking is probably still done with ld15:44
--- Log closed Mon May 19 19:57:43 2014
--- Log opened Mon May 19 19:58:00 2014
-!- Irssi: #openrisc: Total of 41 nicks [0 ops, 0 halfops, 0 voices, 41 normal]19:58
-!- Irssi: Join to #openrisc was synced in 24 secs19:58
stekernthat link didn't show the diff though, just the sim-arch.scm file19:58
stekernbut the commit msg showed at the top ;)19:58
blueCmdstekern: yes, I tried to find the diff20:00
blueCmdI failed because CVS20:00
stekernI see20:01
stekernI can't find a diff that is combined with the commit msg neither20:01
blueCmdstekern: *sigh*20:52
blueCmdit's always something :)20:52
stekernyeah, didn't you get that with apache too?21:13
stekernand then when I compiled it, it didn't fail?21:14
stekernwhat is -pie suppose to add over -fPIE?21:14
blueCmdah, right. that might be true21:15
blueCmdI forgot about that one21:15
blueCmdI don't know, haven't debugged it at all yet21:15
blueCmdI got my de0 nano to boot to uboot now from the EPCS flash21:16
stekernnice, have you had time to test your add-on board?21:17
blueCmdthis is the first time in weeks I actually booted the VM with all my fpga tools, so sadly no21:18
blueCmdOr, I'm using the expansion board atm21:18
blueCmdbut only the dual UARTs are tested21:18
blueCmdu-boot with ethoc. somebody said that was supported, time to grep in the logs!21:22
blueCmd#define somebody stekern21:23
blueCmd as it turns out, but I should just rebuild gcc I guess21:24
* blueCmd steals from atlys.h21:28
stekern_franck__ was having problems with it, I'm pretty sure that HEAD of my git worked though21:29
_franck__it works, it was due to a memory controller bug21:30
_franck__ah sorry, I didn't try uboot again after that fix. I only worked with barebox21:32
_franck__so blueCmd you'll tell us if it works21:32
stekernok, but you were seeing similar problems on both?21:32
_franck__I didn't investigate much on uboot to see what the problem was21:33
_franck__I'll give it a try now21:33
_franck__it does not work for me, don't know why21:38
_franck__it does not receive ARP answer21:41
_franck__or may be there is something different in my SoC21:44
blueCmdI have an SD card I want to use to have the kernel + filesystem on later, I wonder how hard that will be to implement21:48
blueCmdMMC + SPI is there already so hopefully not too extreme21:48
stekern_franck__: works here21:51
stekernon the fusesoc/orpsoc-cores atlys port21:52
_franck__ok, might be something somewhere :)21:52
blueCmdstekern: how big is your u-boot binary for the atlys port?21:53
blueCmd(the .bin is 250k something)21:55
stekernyes, my elf is bigger21:55
blueCmdhow do you generate u-boot.hex? or do you?21:56
stekernI don't21:56
blueCmdah ok21:56
stekernor... actually, I have21:56
stekernyou want it for the flash, right?21:56
stekernI used some bin2hex.py21:57
blueCmdyeah it seems to have worked21:58
blueCmdI was just assuming stuff21:58
blueCmdbut for some reason the newly built uboot doesn't boot, but that could be a million things21:58
blueCmdhmpf, my old copy of u-boot.hex stopped booting as well22:04
blueCmdhm, reflashing the jic worked22:05
blueCmdhaha. If I blow on the FPGA it boots22:33
blueCmdthis might be what olofk called a 'temperature dependency' ;)22:34
JakeUSCAnyone willing to help me out? I'm trying to load a linux image with u-boot on a de0 nano.22:40
blueCmdJakeUSC: I just did that22:41
blueCmdlike 2 min ago22:41
blueCmdwell not the Linux image part22:42
blueCmdbut I'm working towards that! :)22:42
JakeUSCoh wow. I have .sof image that works which i can load either the linux file and boot it or I can load u-boot but I cannot figure out how to upload both22:42
blueCmdcant you use openocd for that?22:43
blueCmdor, how are you loading either uboot or linux now?22:43
JakeUSCI load linux up through openocd22:44
JakeUSCI can load up u-boot as well through openocd22:44
blueCmdright, so just load the linux image to another memory location and do 'bootm 0xwhatever'22:44
blueCmdwhere 0xwhatever is where you put it :)22:45
JakeUSCok, so after I load the u-boot image how do I add the linux image? I don't think I know how to specify the address to load it to.22:46
blueCmdwell, the documentation for openocd would be a good place to start ;)22:46
blueCmd— Command: load_image filename address [[bin|ihex|elf|s19] min_addr max_length]22:46
JakeUSCOh ok, I was trying to use uboot mkimage22:47
blueCmdyou probably need to22:47
blueCmdI don't think you want to upload the vmlinux image, but instead upload the uImage22:47
blueCmdbut why do you want to do this? it feels very.. troublesome22:48
blueCmdwhy not boot linux directly?22:48
JakeUSCHonestly, I would like to boot linux directly but I am looking for a way have it loaded in flash so I don't need to use openocd everytime I turn it on.22:49
blueCmdright, that's what I'm working on22:50
blueCmdI'm currently loading u-boot from the FPGA configuration EPCS flash on power-on22:50
blueCmdYou could read the Linux kernel from that as well, but I'm going to read it from an SD card I think22:51
JakeUSCSounds like your quite a few steps ahead me. It took me almost a week to get this far lol22:51
blueCmdhah, yeah - it's time consuming all right22:51
JakeUSCSo do you think I can take this u-boot image and flash it as is and it will load at poweron? Or are there more steps I need to work on?22:53
blueCmduImage or u-boot image?22:55
JakeUSCThe u-boot image22:55
blueCmdwhat you need is 1) a boot ROM that will move the code from the EPCS to RAM and jump to it and 2) u-boot support for reading the EPCS22:55
blueCmdfor 1) you can use
JakeUSCThanks, I am going to check that out22:57
blueCmd./ creates a bootrom.v (which is also checked in for some reason). you need to modify de0_nano to use it (I've done so, give me a ping if you want (dirty) patches to do so)22:58
blueCmdde0_nano being the system in orpsoc-cores22:58
JakeUSCok thanks, I appreciate the help.23:02
blueCmdnp! good luck :)23:03
blueCmdtime to sleep, nice hardware hacking for a change :)23:16
--- Log closed Tue May 20 00:00:56 2014

Generated by 2.15.2 by Marius Gedminas - find it at!