| --- Log opened Sun Jul 31 00:00:03 2016 | ||
| olofk | mafm: Saw the eoma68 article on slashdot now | 16:28 |
|---|---|---|
| mafm | olofk: yep. saw the comment? the guy says that openrisc cannot do more than 0.5GHz for some technical reason | 16:55 |
| mafm | olofk: he also says that the sifive designs are focused in pcie, so no way (for power reasons), but hopefully others will come in the future (perhaps lowrisc is simple/power constrained enough) | 16:57 |
| mafm | the campaign is not doing very well at the moment, though | 16:58 |
| olofk | mafm: Yes. I don't agree with his comments on OpenRISC. Looks to me like he's mixing up the ISA and implementations, but it doesn't really matter as there are still no OpenRISC implementations on ASIC that would fit his purposes | 17:01 |
| olofk | I think it was interesting to read about his choice for a parellel video interface. I was sceptic about that, but he's got a point | 17:01 |
| olofk | And regarding the SiFive silicon, I haven't really read up on their planned chips, but one of them was supposed to be for embedded | 17:02 |
| olofk | And PCIe could be a very good choice to make it extendable. Especially with the very tight power budget he's got, there need to be room for more processing outside of the module | 17:03 |
| olofk | And PCIe doesn't have to be high-power. I just worked on a handheld battery-powered device that had internal SATA, PCIe, MIPI and gigabit ethernet | 17:04 |
| olofk | But I hope he makes it. I like the idea very much and would like it to be successful even if I might be sceptic about some of the design decisions | 17:05 |
| olofk | poke53281: Have you talked to your student about the malloc issues that ssvb found? I had totally forgot that you were mentoring a project to improve Qemu for OpenRISC | 17:06 |
| mafm | olofk: I am also a bit sceptic, specially about delivering in time, at that price, etc (I am not 100% sure that he'll not have problems with the factories and similar) | 17:08 |
| olofk | poke53281: Is Ian here on IRC btw? | 17:08 |
| mafm | olofk: about the design in general, I am not sure about PCIe etc, but I think that he's too focused on cost^3 | 17:09 |
| olofk | mafm: Just as a comparasion, the parallela project was dangerously close to not making it since there was some unexpected problems with sourcing and not enough resources to do a backup plan | 17:09 |
| olofk | Yes. I think the modules are too cheap. It puts unnecessary restraints on the development | 17:10 |
| mafm | olofk: and specially for "general purpose computing", 32-bit starts to not cut it (much less if he plans that they're OK for 5-10 years), and the LCD resolution doesn't work for me at all | 17:10 |
| mafm | olofk: but I think that he's mainly working on the same basis/specs that they had for the Improv back in 2013 | 17:11 |
| olofk | But the big problem will probably be the ecosystem. Just look at our beloved Jollas. Except for this crazy dutch guy who made some cool stuff, not even Jolla themselves commmited to the modules | 17:11 |
| mafm | olofk: to not loose focus and start all over again | 17:11 |
| mafm | yeah, unless he pulls out this and other cards lately, I don't think that many people will follow | 17:12 |
| olofk | Agree. It would probably have been better to market them as something else than a general purpose design. But then on the other hand, there are plenty of other modular systems for IoT-like projects, so it's hard to find a good niche for a quite-fast-but-not-that-fast device | 17:12 |
| mafm | I think that if he pulled this in ~2013, the original Improv or so, it would be like the 2nd rpi or something -- maybe comparable to wandaboard, beaglebone or something | 17:14 |
| mafm | now, the marked is absolutely flooded with options and there's not even visibility for this project, so very few people even pay attention | 17:14 |
| mafm | "oh, jut another a20 board" | 17:14 |
| mafm | since he's pro-free designs and if he's really got contacts to make this happen, I hope that maybe he will do something with the "librecores" if something is close enough to give it a try | 17:16 |
| ssvb | olofk: regarding the clock speed of OR1200 in ASIC (without the MMU) - https://linux-sunxi.org/Orange_Pi_PC#OpenRISC_core | 17:16 |
| ssvb | olofk: the ARM Cortex-A7 cores run up to 1.3GHz in the same SoC, while OR1200 already has troubles around 400-500 MHz | 17:17 |
| ssvb | olofk: and because I still was unable to run CoreMark at any clock speed in a way that it gets valid results, the realistic reliable clock speed may be lower than this | 17:21 |
| olofk | ssvb: Aha. So that's where the numbers come from :) | 17:27 |
| olofk | I must say that it's pretty impressive numbers though for a CPU that's just supposed to wake up the real cores :) | 17:28 |
| ssvb | olofk: I have no idea where the lkcl's numbers come from, and why he thinks that the pipeline length is at fault :) | 17:29 |
| olofk | I had no idea that there had been this much experimenting with the or1200 in the A20 SoCs | 17:29 |
| olofk | ssvb: No, I haven't got a clue either why he's blaming the pipeline, but he cited 0.5GHz, which is roughly what was in the link you pasted | 17:30 |
| mafm | ssvb: he's aronud linux-sunxi communities, so maybe from there | 17:41 |
| mafm | olofk: there you are, the eoma68 will run openrisc after all! | 17:42 |
| olofk | mafm: Haha. I didn't even think about that. Way cool :) | 17:52 |
| ssvb | mafm: nope, he is not, he is strongly objecting the use of any google services and the linux-sunxi mailing list is currently a google group | 18:30 |
| ssvb | olofk: A20 has no OpenRISC core, it has been added only in A31 and newer SoCs | 18:30 |
| ssvb | mafm: moreover, Debian people have been advocating against the use of the OpenRISC core in Allwinner SoCs because of the OpenRISC toolchain concerns - http://linux-sunxi.narkive.com/pIoQeJMb/a64-arisc-scpi-and-regulator-handling | 18:35 |
| ssvb | I think that this is the primary reason why there is not much OpenRISC related activity happening in linux-sunxi | 18:39 |
| mafm | ssvb: oh, I see... The Toolchain Problem | 18:53 |
| ssvb | the toolchain has to be packaged and maintained somehow, otherwise compiling the firmware from sources is a PITA | 18:54 |
| ssvb | my personal opinion is that even without the copyright reassignment, the OpenRISC toolchain is a free software even though it has to exist as a separate fork of GCC | 18:57 |
| ssvb | but Linux distribution maintainers obviously don't like forks very much | 18:58 |
| mafm | ssvb: the problem is that the GCC maintainer would not accept that, and probably two copies of GCC would not be accepted in the archive | 18:58 |
| SMDhome1 | correct me please, but I don't think i.e. mor1kx has anything "special" in its design to be limited to 500 mhz and I don't think allwinner guys tried to make ar100 to have high clocks | 23:17 |
| SMDhome1 | but on the other hand AR9344(mips 74k, which is more complicated than current openrisc design) in my router has "only" 533-600 mhz | 23:22 |
| --- Log closed Mon Aug 01 00:00:05 2016 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!