| -!- tintenammae_ is now known as tintenammae | 06:03 | |
| LibertyTrader | Is openrisc fast enough for desktop use? | 11:04 |
|---|---|---|
| jeremybennett | LibertyTrader: Not really - it is for embedded use. Not sure if anyone has tried bringing up a desktop Linux on it. Mostly we use BusyBox | 11:15 |
| LibertyTrader | could openrisc be forked for desktop use? or is the architecture not really optimal for high performance | 11:16 |
| jeremybennett | I'm not sure it even needs to be forked. However its primary target is embedded use with FPGAs, so you'll typically be running at 25-100MHz. | 11:17 |
| LibertyTrader | i thought the point is to run on ASIC? | 11:17 |
| jeremybennett | It would be an interesting exercise to put a desktop up - one of the lighter distributions should work. | 11:17 |
| jeremybennett | You can make an ASIC - Samsung do in their set-top boxes. However the large NRE cost of ASIC rather militates against open source implementations. | 11:18 |
| LibertyTrader | NRE? | 11:18 |
| jeremybennett | Non-recurring engineering - for ASIC making the masksets. | 11:19 |
| LibertyTrader | i want open CPU design so I can be sure there is no backdoor in my computer lol | 11:19 |
| jeremybennett | Well you could build and FPGA based workstation. There are multi-core versions on OpenRISC in the work (see Stefan Wallentowitz work at TUM). | 11:20 |
| LibertyTrader | yeah, but it would cost me thousands | 11:21 |
| jeremybennett | Depends how much you want to invest. DE0-nano is $80. Not that you could run much of a workstation on that. But one of the larger Terasic DE boards would only set you back a few hundred dollars and easily runs OpenRISC Linux. | 11:22 |
| jeremybennett | If it were cheap and easy someone else would have done it! | 11:23 |
| derRichard | before you can use openrisc on your desktop we need better toolchain support | 16:13 |
| jeremybennett | derRichard: which particular aspect of the tool chain - dynamic linking? | 18:47 |
| derRichard | yep, dynamic linking. without it you cannot have a sane userspace | 18:49 |
| derRichard | e.g. glibc | 18:49 |
| derRichard | i'm sure having a glibc port will expose also lot's of bugs in openrisc/linux | 18:50 |
| derRichard | busybox and ulibc need not much :D | 18:50 |
| stekern | derRichard: I agree, we really need dynamic linking. But I'm confident we'll get there, one way or another | 20:18 |
| derRichard | yep :) | 20:19 |
| jeremybennett | derRichard: there are lots of different use cases for OpenRISC. Interestingly, almost all the commercial ones have been at the smaller end of embedded, so busybox and uClibc have been the most important. | 20:20 |
| jeremybennett | Which is not to discourage you from porting glibc and the dynamic linker. | 20:20 |
| jeremybennett | It's just that those actually paying for engineering on OpenRISC haven't had this objective (yet). | 20:20 |
| derRichard | jeremybennett: guess why most embedded stuff is pure CRAP | 20:21 |
| derRichard | "oh it boots a random kernel with some kind of busybox minimal userspace, let's ship it" | 20:22 |
| jeremybennett | No - I don't want to boot up a full Linux desktop on a Zigbee chip. I don't need a full desktop in a set-top box - indeed power regulations strongly militate against. | 20:22 |
| jeremybennett | I suspect the Zigbee chip (NXP) is either bare metal or has the simplest of microkernels. The Samsung STB I presume is running BusyBox. | 20:23 |
| derRichard | sure, but you have to test is well. testing with busybox/uclibc is not good. it uses only a subset of all features. | 20:24 |
| derRichard | at $dayjob i clean up the excrements of such projects all the time | 20:25 |
| jeremybennett | That's a different question. If you mean testing the hardware, the upper levels of the software stack are not key. Have you looked at Waqas Ahmed's masters dissertation on OVM verification of OpenRISC, or Cadence's reference UVM flow (which also uses OpenRISC)? | 20:25 |
| jeremybennett | If you mean testing the software, you should be testing with your target software environment. | 20:26 |
| derRichard | i was talking about the openrisc linux port | 20:27 |
| derRichard | the hardware is maybe ok | 20:27 |
| jeremybennett | Ah - well then you should be testing with what the end user is using. If you are going to deploy Linux with BusyBox and uClibc, you should be testing with those. If with glibc, then with that. | 20:27 |
| derRichard | but still we need more testing. and using real fat software (like glibc) will expose lots of bugs. | 20:27 |
| jeremybennett | I agree completely. | 20:28 |
| jeremybennett | The more software you run, the more bugs in that software you will find. | 20:28 |
| jeremybennett | You won't necessarily find more bugs in the hardware, because it is still the same compiler generating the same subset of instruction sequences. | 20:28 |
| * derRichard wonders if anyone has ever tested pthreads on openrisc/linux | 20:29 | |
| jeremybennett | That is one reason why having the LLVM compiler will be useful - test new sequences on the hardware. | 20:29 |
| jeremybennett | Yes - we spent six months at the start of 2011. We ran all the gcc/g++/libstdc++-v3 threads tests. In the end, the remaining faults were all due to bugs in the uClibc pthread implementation. | 20:30 |
| derRichard | uclibc's libpthread is rubbish :-( | 20:30 |
| jeremybennett | There are known problems there. One challenge is that uClibc regression expects to have dynamic linking and is not designed for remote use (assume you run native). | 20:30 |
| jeremybennett | I see fixing that as a high priority, so we can actually run the uClibc test suite. | 20:31 |
| derRichard | is uclibc using the futex() system call? | 20:33 |
| jeremybennett | Don't know - I didn't go that deeply into it. | 20:33 |
| derRichard | and PTHREAD_PRIO_INHERIT or PTHREAD_MUTEX_ROBUST_NP? | 20:34 |
| jeremybennett | Don't know. jonibo is the uClibc expert. | 20:35 |
| derRichard | there is a lot that can explode :D | 20:35 |
| jeremybennett | Like all these things, there is a trade-off between functionality and time/space. We currently have newlib and uClibc, which suit the "small" and "medium" sized applications. | 20:36 |
| jeremybennett | If you provided us with glibc, then we would have an option for "large" sized applications. | 20:36 |
| derRichard | currently i'm busy with other oss projects. sorry | 20:38 |
| jeremybennett | A problem that bedevils us all :( | 20:53 |
| newbie11 | Hi all. Can't start adv_jtag_bridge. It fails with error: Unable to get host entry for RSP server! Any help? | 22:05 |
| newbie11 | function gethostbyname return NULL. What could it be? | 22:07 |
| derRichard | jeremybennett: what exactly is missing to have dynamic linking support? | 22:38 |
| derRichard | i'm not a gcc expert, but one of my co-workers is | 22:38 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!