| --- Log opened Mon May 19 00:00:55 2014 | ||
| stekern | olofk: how about omg-ic as the name for the turing complete interrupt controller? | 03:41 |
|---|---|---|
| stekern | Open Multiprocessor Global Interrupt Controller | 03:42 |
| stekern | I think for real, I'll call it ompic | 03:45 |
| stekern | (I'm writing a driver for the IPI part, and I think it | 03:45 |
| stekern | 'll make sense to keep everything in the same driver) | 03:46 |
| olofk | haha. I like it even though it's a pity that you dropped the 'g' | 04:17 |
| stekern | would it be crazy to use wb_intercon in it internally? | 05:01 |
| stekern | just thinking, since I've already made the ipi part standalone | 05:03 |
| stekern | blueCmd: did you notice this thread? https://sourceware.org/ml/binutils/2014-05/msg00157.html | 05:10 |
| stekern | it'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 it | 05:15 |
| olofk | stekern: I'm all for code reuse so that sounds like a good idea. Is it wb_mux you're thinking of reusing? | 06:08 |
| stekern | yes | 06:18 |
| olofk | I'm not planning to change anything in the interface, so you should be safe | 06:21 |
| olofk | And if I want to change something, I'll make sure to implement versioning support first so that you can point out an older version | 06:22 |
| stekern | I'm mostly worried about using a big bulky bus interface for arbitration between in-core registers ;) | 06:24 |
| olofk | Yeah, but most signals are just pass-through | 06:44 |
| olofk | I just routed them through the component to get a cleaner architecture | 06:45 |
| stekern | yes, that's my thought. the wb slave arbitration should be pretty light weight I think | 06:46 |
| stekern | and 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 design | 06:47 |
| stekern | I can't imagine someone wanting to opt-out on the app store though, maybe we should make that mandatory? | 06:48 |
| olofk | Yeah 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 mistake | 06:57 |
| stekern | maybe we can utilize alteras OpenCore system too, and use their time limiting feature to implement opening hours to the app store? | 07:00 |
| stekern | since that will per se demand a jtag connection, maybe we could use that to connect to the cloud too? | 07:02 |
| stekern | seems the irqchip code in Linux isn't very dynamic | 07:16 |
| stekern | maybe 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 before | 07:18 |
| stekern | even though the irq controllers have been soc specific and not cpu specific | 07:18 |
| olofk | I like how you're thinking. I totally missed the cloud connection | 07:51 |
| olofk | So do you see any indications that Linux is moving to SoC-specific controllers? | 07:51 |
| stekern | I 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 |
| stekern | for instance, arms gic is a SoC-specific controller, but it's not like it could ever be used on anything else than arm | 07:56 |
| stekern | because it ties in to specific code in arch/arm/ | 07:56 |
| stekern | (or arch/arm64/) | 07:56 |
| stekern | now, 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 |
| stekern | I 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 archs | 08:00 |
| stekern | I 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 point | 08:06 |
| stekern | iirc, two for two different arm socs and one for a powerpc soc | 08:07 |
| stekern | I'm not entirely sure how I will make the ompic nicely snug into being in between the or1k-pic and the actual irq-lines | 08:09 |
| stekern | maybe we can name it omg-epic btw | 08:12 |
| stekern | Open Multiprocessor Generic External Programmable Interrupt Controller | 08:14 |
| olofk | That's the best thing I have heard, ever! | 08:22 |
| blueCmd | stekern: 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 merged | 08:24 |
| blueCmd | then possibly a 3) but I don't know what it would be | 08:24 |
| stekern | oh, 1) and 2) was unrelated | 08:25 |
| stekern | there's a seperate cgen patch needed to solve 1) | 08:26 |
| blueCmd | Ah I see | 08:26 |
| stekern | my point was mostly that there was some response from a cgen guy about your patch though | 08: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 point | 08:28 |
| stekern | umm, "that guy" in the second sentence being the muller guy that started the thread | 08:29 |
| blueCmd | stekern: did I understand it correctly that they will merge our cgen patch? | 09:26 |
| stekern | that was actually a bit unclear, but at least it got an "OK" from Frank | 09:31 |
| stekern | I guess Alan have write access to the cgen repo, so maybe he'll just commit it | 09:32 |
| stekern | if not, I guess we'll just have to ping that thread in a while ;) | 09:32 |
| blueCmd | yep! | 09:34 |
| sb0 | hi | 14:37 |
| sb0 | what's the current status of LLVM support? | 14:37 |
| blueCmd | I think someone wrote a basic port but AFAIK it lacks a lot of stuff | 15:01 |
| stekern | nah, it | 15:10 |
| stekern | 's not lacking *lot of stuff* | 15:10 |
| stekern | what's lacking is debug symbols and TLS | 15:11 |
| stekern | ...and someone that sync it with upstream ;) | 15:11 |
| blueCmd | it has dynamic linking? | 15:14 |
| blueCmd | it has atomics? ;) | 15:15 |
| stekern | yes | 15:18 |
| stekern | if you use the normal binutils | 15:18 |
| blueCmd | oh right | 15:29 |
| blueCmd | doesn't llvm do linking/as ? | 15:29 |
| stekern | it can, and we have support for that in our port (thanks to simoncook), but it can also use external as/ld | 15:40 |
| blueCmd | I see | 15:40 |
| stekern | well, it at least have assembling support, linking is probably still done with ld | 15:44 |
| blueCmd | stekern: https://sourceware.org/cgi-bin/cvsweb.cgi/src/cgen/sim-arch.scm?rev=1.8&content-type=text/x-cvsweb-markup&cvsroot=cgen | 19:36 |
| --- 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 secs | 19:58 | |
| stekern | that link didn't show the diff though, just the sim-arch.scm file | 19:58 |
| stekern | but the commit msg showed at the top ;) | 19:58 |
| blueCmd | stekern: yes, I tried to find the diff | 20:00 |
| blueCmd | I failed because CVS | 20:00 |
| stekern | I see | 20:01 |
| stekern | I can't find a diff that is combined with the commit msg neither | 20:01 |
| blueCmd | stekern: https://github.com/bluecmd/or1k-debian/issues/34 *sigh* | 20:52 |
| blueCmd | it's always something :) | 20:52 |
| stekern | yeah, didn't you get that with apache too? | 21:13 |
| stekern | and then when I compiled it, it didn't fail? | 21:14 |
| stekern | what is -pie suppose to add over -fPIE? | 21:14 |
| blueCmd | ah, right. that might be true | 21:15 |
| blueCmd | I forgot about that one | 21:15 |
| blueCmd | I don't know, haven't debugged it at all yet | 21:15 |
| blueCmd | I got my de0 nano to boot to uboot now from the EPCS flash | 21:16 |
| stekern | nice, have you had time to test your add-on board? | 21:17 |
| blueCmd | this is the first time in weeks I actually booted the VM with all my fpga tools, so sadly no | 21:18 |
| blueCmd | Or, I'm using the expansion board atm | 21:18 |
| blueCmd | but only the dual UARTs are tested | 21:18 |
| stekern | ah | 21:18 |
| blueCmd | u-boot with ethoc. somebody said that was supported, time to grep in the logs! | 21:22 |
| blueCmd | #define somebody stekern | 21:23 |
| blueCmd | http://git.openrisc.net/cgit.cgi/stefan/u-boot/commit/?id=c7845df64f7df75dc3d46e2f6385c0d901f9d416 as it turns out, but I should just rebuild gcc I guess | 21:24 |
| * blueCmd steals from atlys.h | 21:28 | |
| stekern | _franck__ was having problems with it, I'm pretty sure that HEAD of my git worked though | 21:29 |
| _franck__ | it works, it was due to a memory controller bug | 21:30 |
| _franck__ | ah sorry, I didn't try uboot again after that fix. I only worked with barebox | 21:32 |
| _franck__ | so blueCmd you'll tell us if it works | 21:32 |
| stekern | ok, but you were seeing similar problems on both? | 21:32 |
| _franck__ | I didn't investigate much on uboot to see what the problem was | 21:33 |
| _franck__ | I'll give it a try now | 21:33 |
| _franck__ | it does not work for me, don't know why | 21:38 |
| _franck__ | it does not receive ARP answer | 21:41 |
| _franck__ | or may be there is something different in my SoC | 21:44 |
| blueCmd | I have an SD card I want to use to have the kernel + filesystem on later, I wonder how hard that will be to implement | 21:48 |
| blueCmd | MMC + SPI is there already so hopefully not too extreme | 21:48 |
| stekern | _franck__: works here | 21:51 |
| stekern | on the fusesoc/orpsoc-cores atlys port | 21:52 |
| _franck__ | ok, might be something somewhere :) | 21:52 |
| blueCmd | stekern: how big is your u-boot binary for the atlys port? | 21:53 |
| stekern | 190k | 21:54 |
| blueCmd | heh | 21:55 |
| blueCmd | 1.1M | 21:55 |
| blueCmd | (the .bin is 250k something) | 21:55 |
| stekern | yes, my elf is bigger | 21:55 |
| stekern | 870k | 21:55 |
| blueCmd | hm | 21:55 |
| blueCmd | how do you generate u-boot.hex? or do you? | 21:56 |
| stekern | I don't | 21:56 |
| blueCmd | ah ok | 21:56 |
| stekern | or... actually, I have | 21:56 |
| stekern | you want it for the flash, right? | 21:56 |
| blueCmd | yep | 21:57 |
| stekern | I used some bin2hex.py | 21:57 |
| blueCmd | yeah it seems to have worked | 21:58 |
| blueCmd | I was just assuming stuff | 21:58 |
| blueCmd | but for some reason the newly built uboot doesn't boot, but that could be a million things | 21:58 |
| blueCmd | hmpf, my old copy of u-boot.hex stopped booting as well | 22:04 |
| blueCmd | hm, reflashing the jic worked | 22:05 |
| blueCmd | haha. If I blow on the FPGA it boots | 22:33 |
| blueCmd | this might be what olofk called a 'temperature dependency' ;) | 22:34 |
| dalias | :) | 22:36 |
| JakeUSC | Anyone willing to help me out? I'm trying to load a linux image with u-boot on a de0 nano. | 22:40 |
| blueCmd | JakeUSC: I just did that | 22:41 |
| blueCmd | like 2 min ago | 22:41 |
| blueCmd | oh | 22:42 |
| blueCmd | well not the Linux image part | 22:42 |
| blueCmd | but I'm working towards that! :) | 22:42 |
| JakeUSC | oh 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 both | 22:42 |
| blueCmd | right | 22:43 |
| blueCmd | cant you use openocd for that? | 22:43 |
| blueCmd | or, how are you loading either uboot or linux now? | 22:43 |
| JakeUSC | I load linux up through openocd | 22:44 |
| JakeUSC | I can load up u-boot as well through openocd | 22:44 |
| blueCmd | right, so just load the linux image to another memory location and do 'bootm 0xwhatever' | 22:44 |
| blueCmd | where 0xwhatever is where you put it :) | 22:45 |
| JakeUSC | ok, 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 |
| blueCmd | well, 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 |
| JakeUSC | Oh ok, I was trying to use uboot mkimage | 22:47 |
| blueCmd | you probably need to | 22:47 |
| blueCmd | I don't think you want to upload the vmlinux image, but instead upload the uImage | 22:47 |
| blueCmd | but why do you want to do this? it feels very.. troublesome | 22:48 |
| blueCmd | why not boot linux directly? | 22:48 |
| JakeUSC | Honestly, 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 |
| blueCmd | right, that's what I'm working on | 22:50 |
| blueCmd | I'm currently loading u-boot from the FPGA configuration EPCS flash on power-on | 22:50 |
| blueCmd | You could read the Linux kernel from that as well, but I'm going to read it from an SD card I think | 22:51 |
| JakeUSC | Sounds like your quite a few steps ahead me. It took me almost a week to get this far lol | 22:51 |
| blueCmd | hah, yeah - it's time consuming all right | 22:51 |
| JakeUSC | So 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 |
| blueCmd | uImage or u-boot image? | 22:55 |
| JakeUSC | The u-boot image | 22:55 |
| blueCmd | what 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 EPCS | 22:55 |
| blueCmd | for 1) you can use https://github.com/bluecmd/or1k-devel/tree/master/bootrom | 22:57 |
| JakeUSC | Thanks, I am going to check that out | 22:57 |
| blueCmd | ./build.sh 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 |
| blueCmd | de0_nano being the system in orpsoc-cores | 22:58 |
| JakeUSC | ok thanks, I appreciate the help. | 23:02 |
| blueCmd | np! good luck :) | 23:03 |
| blueCmd | time to sleep, nice hardware hacking for a change :) | 23:16 |
| --- Log closed Tue May 20 00:00:56 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!