IRC logs for #openrisc Sunday, 2012-06-10

-!- tintenammae_ is now known as tintenammae06:03
LibertyTraderIs openrisc fast enough for desktop use?11:04
jeremybennettLibertyTrader: Not really - it is for embedded use. Not sure if anyone has tried bringing up a desktop Linux on it. Mostly we use BusyBox11:15
LibertyTradercould openrisc be forked for desktop use? or is the architecture not really optimal for high performance11:16
jeremybennettI'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
LibertyTraderi thought the point is to run on ASIC?11:17
jeremybennettIt would be an interesting exercise to put a desktop up - one of the lighter distributions should work.11:17
jeremybennettYou 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
jeremybennettNon-recurring engineering - for ASIC making the masksets.11:19
LibertyTraderi want open CPU design so I can be sure there is no backdoor in my computer lol11:19
jeremybennettWell 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
LibertyTraderyeah, but it would cost me thousands11:21
jeremybennettDepends 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
jeremybennettIf it were cheap and easy someone else would have done it!11:23
derRichardbefore you can use openrisc on your desktop we need better toolchain support16:13
jeremybennettderRichard: which particular aspect of the tool chain - dynamic linking?18:47
derRichardyep, dynamic linking. without it you cannot have a sane userspace18:49
derRicharde.g. glibc18:49
derRichardi'm sure having a glibc port will expose also lot's of bugs in openrisc/linux18:50
derRichardbusybox and ulibc need not much :D18:50
stekernderRichard: I agree, we really need dynamic linking. But I'm confident we'll get there, one way or another20:18
derRichardyep :)20:19
jeremybennettderRichard: 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
jeremybennettWhich is not to discourage you from porting glibc and the dynamic linker.20:20
jeremybennettIt's just that those actually paying for engineering on OpenRISC haven't had this objective (yet).20:20
derRichardjeremybennett: guess why most embedded stuff is pure CRAP20:21
derRichard"oh it boots a random kernel with some kind of busybox minimal userspace, let's ship it"20:22
jeremybennettNo - 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
jeremybennettI 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
derRichardsure, but you have to  test is well. testing with busybox/uclibc is not good. it uses only a subset of all features.20:24
derRichardat $dayjob i clean up the excrements of such projects all the time20:25
jeremybennettThat'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
jeremybennettIf you mean testing the software, you should be testing with your target software environment.20:26
derRichardi was talking about the openrisc linux port20:27
derRichardthe hardware is maybe ok20:27
jeremybennettAh - 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
derRichardbut still we need more testing. and using real fat software (like glibc) will expose lots of bugs.20:27
jeremybennettI agree completely.20:28
jeremybennettThe more software you run, the more bugs in that software you will find.20:28
jeremybennettYou 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/linux20:29
jeremybennettThat is one reason why having the LLVM compiler will be useful - test new sequences on the hardware.20:29
jeremybennettYes - 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
derRicharduclibc's libpthread is rubbish :-(20:30
jeremybennettThere 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
jeremybennettI see fixing that as a high priority, so we can actually run the uClibc test suite.20:31
derRichardis uclibc using the futex() system call?20:33
jeremybennettDon't know - I didn't go that deeply into it.20:33
jeremybennettDon't know. jonibo is the uClibc expert.20:35
derRichardthere is a lot that can explode :D20:35
jeremybennettLike 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
jeremybennettIf you provided us with glibc, then we would have an option for "large" sized applications.20:36
derRichardcurrently i'm busy with other oss projects. sorry20:38
jeremybennettA problem that bedevils us all :(20:53
newbie11Hi all. Can't start adv_jtag_bridge. It fails with error: Unable to get host entry for RSP server! Any help?22:05
newbie11function gethostbyname return NULL. What could it be?22:07
derRichardjeremybennett: what exactly is missing to have dynamic linking support?22:38
derRichardi'm not a gcc expert, but one of my co-workers is22:38

Generated by 2.15.2 by Marius Gedminas - find it at!