IRC logs for #openrisc Monday, 2015-09-28

--- Log opened Mon Sep 28 00:00:03 2015
-!- orsonmmz|away is now known as orsonmmz07:37
maxpalnok, so I've manually created the sys-root directory described in the 'Linux Headers' section here: http://opencores.org/or1k/OpenRISC_GNU_tool_chain09:15
maxpalnI am not sure if this is correct. Maybe it was supposed to be created during the or1k-src section (there is a --with-sysroot on the configure line) or if I am meant to create it manually. It is possible I will be missing some stuff - if so i'll abandon my attempts to compile uclibc since it doesn't seem to be necessary. But so far I am progressing without problems although I've only got to09:17
maxpalnthe gcc stage 1 instructions.09:17
maxpalnwell, that appears to have worked as far as I can tell - the install process completed without problems. Maybe the above installation instructions need to be updated to reflect the need to manually create the sys-root directory.10:35
maxpalnActually, having thought about it, maybe the make script creates the directory!! I didn't actually try - I just noticed it was missing and thought something had gone wrong! Poor form really. Well, at least my experiences are documented here now :-)10:36
maxpalnso, uclibc and musl installed. Next up the or1k-tests suite - so this is my first 'a little out of my comfort zone' question. Now I have two separate compilers available (uclibc and musl) - can I freely choose one or the other when compiling, for example, the or1k-tests. I know musl is the preferred compiler for Linux applications and newlib (which I haven't installed yet) is the preferred11:15
maxpalnfor baremetal applications. But is there a reason not to use musl for something like these tests (which aren't really going near HW in this case).11:15
stekernmaxpaln: for the asm only tests it doesn't really matter, but the C tests should be compiled with or1k-elf-11:21
maxpalnok - maybe I'll do a bit of background research on musl to help me understand the difference a little. For now, I'll stick to the path...11:22
blueCmddalias: I just read that you worked with a co-worker of mine! https://sourceware.org/ml/libc-alpha/2015-09/msg00447.html :)11:33
_franck_"efuse operation is not supported on this OS platform. It is only supported on 32-bit Windows XP"12:24
_franck_come one Xilinx, are you kidding me ?12:24
_franck_s/one/on12:25
maxpalncomputer says no12:48
maxpalnjust realised this is a very british reference - its from a TV show called Little Britain a few years ago. https://www.youtube.com/watch?v=AJQ3TM-p2QI12:58
blueCmdhahahha, I didn't know the source of that - thanks!13:00
maxpalnit was a ridiculously successful tv show - very funny too. WOrth a browse on Youtube if you have one of those unusual 'spare 5 minutes' that I hear people have sometimes...13:01
blueCmdI actually have the whole day of that13:02
maxpaln:-) too lucky!13:04
olofkI love Little Britain13:04
maxpaln:-) Glad the love made it as far as Sweden...13:05
blueCmdmoving to switzerland tomorrow, so cleaning out my desk today - pleeenty of time to watch stupid youtube videos13:05
maxpalnah, nice - big move! Good luck!13:06
olofkblueCmd: Cool. What will you do there?13:06
maxpalnand if someone wearing a FIFA badge offers you some money - say no!13:06
blueCmdolofk: The same as in Dublin, just in another country13:06
blueCmdolofk: working on what we call Borg, the cluster management thingy we use13:06
olofkblueCmd: Cool. We13:10
olofk'll see you in the new country in just over a week13:10
blueCmdYes! It's very convienient :)13:10
olofkWhich city will you be working in?13:10
blueCmdZ├╝rich, so a bit of a train ride, but still13:11
olofkmaxpaln: The main difference between the Linux-based C libraries (uClibc and musl) and the bare metal library (newlib) is how the system calls are implemented15:06
olofkUsing printf as an example, the Linux-based libraries asks the Linux kernel to put out a string on standard output (which can be for example a frame buffer, a UART or something else). The bare-metal libraries has a built-in UART driver that it calls to output the string15:08
olofkWhich means that the Linux-based libraries needs to be running on top of a Linux kernel, or else it will have nothing that can execute the system calls15:09
olofkOn the other hand, a bare-metal program can't run under Linux since it isn't allowed to access the hardware directly15:09
olofkA layman's view of C libraries. There are probably plenty of flaws in this explanation :)15:10
maxpalnah, nice - a useful primer! :-)15:10
maxpalnBTW, just installing icarus (making good progress today) to give a sanity check to my installation. Is it safe to grab the latest development release from github or should I stick to the snapshots?15:11
maxpalnI've just grabbed a snapshot for now - but can switch to a source distribution if it helps...15:12
olofkmaxpaln: snapshots for what?15:25
olofkIf you mean FuseSoC I think the github versions are best15:28
maxpalnsorry, icarus15:35
maxpalnI'll work on adding other sim support to fusesoc afterwards - but I want to do some sanity checks first using a known good starting point: icarus15:35
maxpalnlooks like I'm ready to go:15:38
maxpalnCompleted transaction 900/100015:38
maxpaln10039910 : All tests passed!15:38
maxpalnmatt@matt-VirtualBox:~/fusesoc/workspace$15:38
maxpalnOK, I am back where I was on Friday but one step further now :-)15:57
maxpalnI am trying to run the full test suite using something like this:15:58
maxpalnfor test in `ls ~/or1k-tests/native/build/or1k/`; do fusesoc sim --keep mor1kx-generic --elf-load ~/or1k-tests/native/build/or1k/$test; done15:58
maxpalnIt seems to have hung at the first test: http://pastie.org/1044850015:59
maxpalnIs this expected?15:59
maxpalnor1k-intloop also seems to hang!16:29
maxpalnmaybe this is one of those that requires certain memory conditions etc because or1k-intmulticycle hangs too and they both have large ELF files16:31
maxpalnin fact all the or1k-int* tests fail...16:31
maxpalnor rather hang...16:31
maxpalnor1k-alignillegalinsn also has a large ELF file - I guess that is the cause somewhere along the line...16:32
stekernmaxpaln: the intloop tests requires an "interrupt generator" core that's not available in fusesoc18:03
stekernthey are legacy tests from mor1kx-devenv18:04
-!- orsonmmz is now known as orsonmmz|away18:32
-!- Netsplit *.net <-> *.split quits: rokka18:39
-!- Netsplit over, joins: rokka18:44
-!- mboehnert1 is now known as mboehnert19:12
olofkI have a branch somewhere where I tried to put back the interrupt generator in mor1kx-generic19:35
andrzejr_olofk, looks like caching is still broken in my system, although in a less obvious way. So it may be my DDR2 i/f after all.22:47
andrzejr_Actually, it is not the only problem with memory - for some reason 64M*16b=1Gb=128MB RAM is seen as only 64MB. I guess that is related to the word size. The spec of the controller is very confusing in this part.22:51
--- Log closed Tue Sep 29 00:00:04 2015

Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!