| --- Log opened Sat Nov 08 00:00:19 2014 | ||
| poke53281 | I think I have stabilized my smp emulation. At least a little bit. | 02:10 |
|---|---|---|
| poke53281 | stekern: May I ask you if I can give you some suggestions for ompic improvements? :) | 02:10 |
| stekern_ | poke53281: absolutely | 05:14 |
| poke53281 | I don't like the inner retry loop. And I don't think that this loop is necessary. Especially the udelay is highly inconvenient inside a spinlock. | 05:40 |
| poke53281 | Without changing the hardware I think we can change the IPI-flags to a IPI-bitfield. | 05:41 |
| poke53281 | And instead of waiting for a acknowledge, we can just or the irq-data field. | 05:42 |
| poke53281 | We would lose the knowledge about the source of the interrupt, but this information is not needed. | 05:43 |
| stekern_ | yeah, that could work | 05:52 |
| -!- stekern_ is now known as stekern | 05:52 | |
| stekern | irq-data is 16 bits anyway, and we don't have that many IPI functions | 05:53 |
| poke53281 | exactly | 05:54 |
| stekern | and no, I don't like that loop neither. but, my first impression was that you'd never hit that situation | 05:54 |
| poke53281 | Maybe not with 4 cores. | 05:56 |
| stekern | oh, that happens with 4 cores too | 05:57 |
| poke53281 | And I thought never does not count in smp systems ;) | 05:57 |
| stekern | I mean when I first wrote it | 05:57 |
| stekern | with "never" I meant very rarely ;) | 05:58 |
| poke53281 | Not sure, m system is still not stable. But removing this loop helps for some reason. But it- is very simple. A udelay inside a spinlock region is wrong. | 05:59 |
| poke53281 | we can unlock it and lock it again before and after the udelay. | 06:00 |
| poke53281 | But it would be better to get fully rid of this loop. | 06:00 |
| poke53281 | I checked other irqchips, and they don't have such a loop. | 06:00 |
| poke53281 | I think a bitfield and probably another spinlock is the easiest solution. | 06:01 |
| stekern | why do you need another spinlock? | 06:06 |
| poke53281 | not another, the same. But we need it for the ipi_handler too. | 06:08 |
| poke53281 | or-ing the irq-data is not atomic. | 06:09 |
| stekern | ah, of course | 09:11 |
| Hesham | Hi, we (RTEMS community) want to know whether the gcc or1k/rtems patches have been merged to or1k-gcc repo or not, can anyone confirm? | 12:48 |
| stekern | Hesham: I don't think they have been, was there a final set of patches that everybody was happy with at some point? | 13:08 |
| stekern | if so, we can certainly just apply them | 13:08 |
| stekern | poke53282: not sure if using a bit-field will entirely solve it, you still have to check that the bit isn't set for the dest-cpu before you can issue the soft-irq | 13:48 |
| Hesham | stekern: Sorry for being late. Yeah, there were final set of patches that Joel and I provided, I think blueCmd maybe aware of them. | 15:03 |
| Hesham | Another question Joel asked is "Do you have C11 atomic operations already"? | 15:04 |
| Hesham | We may think to add SMP support to OpenRISC port on RTEMS, but we need details about the current HW (NoC, SMP), simulators supports, and boards too. It maybe part of an MSc research project. | 15:07 |
| stekern | Hesham: I have a couple of multicore orpsoc-cores systems here: https://github.com/skristiansson/orpsoc-cores/tree/multicore | 15:51 |
| stekern | iirc you had an atlys board, but that's unfortunately pretty much untested since my board broke down right after I was done with that port | 15:53 |
| Hesham | stekern: If you can give alternatives for Atlys board that would be good. In the research we are interested in many cores (i.e, 16 cores or more). So, do you think there is or will be good HW support for such a many-core architecture on OpenRISC? | 15:59 |
| Hesham | And of course a platform to test results and make some analysis... | 16:01 |
| stekern | you just need to find a big enough FPGA ;) | 16:07 |
| stekern | I have a 4-core setup running on the sockit board, and the whole soc takes around 40%, so finding an FPGA that'd fit 16 cores doesn't sound impossible | 16:08 |
| wallento1 | Hesham: We are researching NoC-based manycore. But more with a focus on distributed memory and less on SMP | 18:06 |
| Hesham | stekern: So it's all a matter of a big FPGA? do you use Wishbone as a NoC? | 18:40 |
| Hesham | wallento: I think we are targeting the same research field. Actually we have many candidates HW platforms like Parallella, OpenRISC, Bluestar | 18:42 |
| stekern | Hesham: pretty much yes, but the soc's I've done isn't NoC, I think you want to look more at wallento's optimsoc for that | 19:51 |
| Hesham | Thanks. I googled it and found some good results. | 19:52 |
| --- Log closed Sun Nov 09 00:00:20 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!