| --- Log opened Mon Sep 28 00:00:03 2015 | ||
| -!- orsonmmz|away is now known as orsonmmz | 07:37 | |
| maxpaln | ok, so I've manually created the sys-root directory described in the 'Linux Headers' section here: http://opencores.org/or1k/OpenRISC_GNU_tool_chain | 09:15 |
|---|---|---|
| maxpaln | I 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 to | 09:17 |
| maxpaln | the gcc stage 1 instructions. | 09:17 |
| maxpaln | well, 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 |
| maxpaln | Actually, 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 |
| maxpaln | so, 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 preferred | 11:15 |
| maxpaln | for 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 |
| stekern | maxpaln: for the asm only tests it doesn't really matter, but the C tests should be compiled with or1k-elf- | 11:21 |
| maxpaln | ok - 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 |
| blueCmd | dalias: 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/on | 12:25 |
| maxpaln | computer says no | 12:48 |
| maxpaln | just 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-p2QI | 12:58 |
| blueCmd | hahahha, I didn't know the source of that - thanks! | 13:00 |
| maxpaln | it 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 |
| blueCmd | I actually have the whole day of that | 13:02 |
| maxpaln | :-) too lucky! | 13:04 |
| olofk | I love Little Britain | 13:04 |
| maxpaln | :-) Glad the love made it as far as Sweden... | 13:05 |
| blueCmd | moving to switzerland tomorrow, so cleaning out my desk today - pleeenty of time to watch stupid youtube videos | 13:05 |
| maxpaln | ah, nice - big move! Good luck! | 13:06 |
| olofk | blueCmd: Cool. What will you do there? | 13:06 |
| maxpaln | and if someone wearing a FIFA badge offers you some money - say no! | 13:06 |
| blueCmd | olofk: The same as in Dublin, just in another country | 13:06 |
| blueCmd | olofk: working on what we call Borg, the cluster management thingy we use | 13:06 |
| olofk | blueCmd: Cool. We | 13:10 |
| olofk | 'll see you in the new country in just over a week | 13:10 |
| blueCmd | Yes! It's very convienient :) | 13:10 |
| olofk | Which city will you be working in? | 13:10 |
| blueCmd | Zürich, so a bit of a train ride, but still | 13:11 |
| olofk | maxpaln: The main difference between the Linux-based C libraries (uClibc and musl) and the bare metal library (newlib) is how the system calls are implemented | 15:06 |
| olofk | Using 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 string | 15:08 |
| olofk | Which 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 calls | 15:09 |
| olofk | On the other hand, a bare-metal program can't run under Linux since it isn't allowed to access the hardware directly | 15:09 |
| olofk | A layman's view of C libraries. There are probably plenty of flaws in this explanation :) | 15:10 |
| maxpaln | ah, nice - a useful primer! :-) | 15:10 |
| maxpaln | BTW, 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 |
| maxpaln | I've just grabbed a snapshot for now - but can switch to a source distribution if it helps... | 15:12 |
| olofk | maxpaln: snapshots for what? | 15:25 |
| olofk | If you mean FuseSoC I think the github versions are best | 15:28 |
| maxpaln | sorry, icarus | 15:35 |
| maxpaln | I'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: icarus | 15:35 |
| maxpaln | looks like I'm ready to go: | 15:38 |
| maxpaln | Completed transaction 900/1000 | 15:38 |
| maxpaln | 10039910 : All tests passed! | 15:38 |
| maxpaln | matt@matt-VirtualBox:~/fusesoc/workspace$ | 15:38 |
| maxpaln | OK, I am back where I was on Friday but one step further now :-) | 15:57 |
| maxpaln | I am trying to run the full test suite using something like this: | 15:58 |
| maxpaln | for test in `ls ~/or1k-tests/native/build/or1k/`; do fusesoc sim --keep mor1kx-generic --elf-load ~/or1k-tests/native/build/or1k/$test; done | 15:58 |
| maxpaln | It seems to have hung at the first test: http://pastie.org/10448500 | 15:59 |
| maxpaln | Is this expected? | 15:59 |
| maxpaln | or1k-intloop also seems to hang! | 16:29 |
| maxpaln | maybe this is one of those that requires certain memory conditions etc because or1k-intmulticycle hangs too and they both have large ELF files | 16:31 |
| maxpaln | in fact all the or1k-int* tests fail... | 16:31 |
| maxpaln | or rather hang... | 16:31 |
| maxpaln | or1k-alignillegalinsn also has a large ELF file - I guess that is the cause somewhere along the line... | 16:32 |
| stekern | maxpaln: the intloop tests requires an "interrupt generator" core that's not available in fusesoc | 18:03 |
| stekern | they are legacy tests from mor1kx-devenv | 18:04 |
| -!- orsonmmz is now known as orsonmmz|away | 18:32 | |
| -!- Netsplit *.net <-> *.split quits: rokka | 18:39 | |
| -!- Netsplit over, joins: rokka | 18:44 | |
| -!- mboehnert1 is now known as mboehnert | 19:12 | |
| olofk | I have a branch somewhere where I tried to put back the interrupt generator in mor1kx-generic | 19: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!