| --- Log opened Fri Jul 18 00:00:24 2014 | ||
| stekern | blueCmd_: I think you should | 02:41 |
|---|---|---|
| dalias | stekern, either before or shortly after i commit the or1k port, can you email the list with basic info on what's needed to get a toolchain and emulator environment up and running? | 04:08 |
| stekern | dalias: sure, no problem | 04:09 |
| dalias | i have a feeling some ppl from the musl side will want to test it, and having that info will be useful :) | 04:09 |
| dalias | (ppl from the or1k side probably already know all that stuff) | 04:09 |
| stekern | I was planning on writing up some step-to-step instrucions on how to get an or1k musl system up and running anyways | 04:10 |
| dalias | it would be nice to get or1k support in musl-cross but i don't know how practical that is if the upstream gcc/binutils don't have full or1k support | 04:11 |
| dalias | do they need patching or does upstream work fully already? | 04:12 |
| stekern | binutils work fully from upstream | 04:12 |
| stekern | gcc is not upstream | 04:12 |
| stekern | our biggest problem with gcc is that it's been touched by a various amount of people during the years, so it's a bit of a headache to track people down for copyright assignments. | 04:14 |
| stekern | but blueCmd_ is working hard on that, so hopefully it will be done soon enough. | 04:14 |
| dalias | ah yes :( | 04:15 |
| stekern | blueCmd_: I think you were having one of your 'busy with real life periods' when I asked this before, maybe I'll be more lucky this time ;) | 05:40 |
| stekern | http://juliusbaxter.net/openrisc-irc/%23openrisc.2014-06-13.log.html#t04:31 | 05:40 |
| raja | hi | 08:43 |
| -!- raja is now known as Guest51447 | 08:43 | |
| Guest51447 | hi | 08:47 |
| Guest51447 | i have problem while Bulid & installing gnu tool - uClibc. | 08:57 |
| Guest51447 | Can anyone help me | 08:57 |
| Guest51447 | http://pastebin.com/raw.php?i=TX8TvXeK | 08:57 |
| Guest51447 | please find the link | 08:57 |
| ams | as was mentioned yesterday, PLEASE PRODUCE THE FULL LOG | 08:58 |
| ams | and please do some actual brain work yourself. | 08:58 |
| Guest51447 | i have pasted error in the log file pointed to you through pastebin | 09:01 |
| ams | did you even read what you pasted? | 09:02 |
| ams | clearly, you didn't. you did not paste the error in question, which happens far above the last message you got. | 09:02 |
| ams | you are blindly yanking things for us to decipher for you, without spending any due dilligence in understanding the problem yourself. | 09:04 |
| Guest51447 | no ams i am finding error during "To build and install just the uClibc toolchain" | 09:05 |
| Guest51447 | i am following thesteps only | 09:06 |
| ams | please stop building the tool chain. simply please stop .. | 09:07 |
| Guest51447 | Then how can i use GNUtool ? | 09:09 |
| Guest51447 | http://pastebin.com/raw.php?i=qfWepwMG | 09:11 |
| ams | i have no idea what GNUtool is. | 09:11 |
| Guest51447 | ok thanks alot | 09:13 |
| rah | ../../../unisrc/bfd/doc/bfd.texinfo:326: unknown command `colophon' | 09:13 |
| rah | ../../../unisrc/bfd/doc/bfd.texinfo:337: unknown command `cygnus' | 09:13 |
| ams | yeah ... | 09:13 |
| rah | Guest51447: possibly you need a more recent makeinfo? | 09:14 |
| ams | rah: Guest51447he refuses to read the error messages, was doing the exact same thing yesterday ... wondering about an error which said "please install gmp/mpfr/mpc" ... and wondering what to do about it. | 09:14 |
| rah | ams: perhaps we can help him by pointing out the error and explaining how it might be solved | 09:15 |
| rah | ams: perhaps he isn't used to errors | 09:15 |
| ams | perhaps, he is incapable of reading. | 09:16 |
| ams | building tool chains is non-trivial. | 09:16 |
| stekern | rah: presumably a *less* recent makeinfo | 09:16 |
| ams | plain impossible if you cannot read error messages | 09:16 |
| rah | stekern: I meant perhaps he needs a later release of makeinfo, which I would describe as "more recent" | 09:17 |
| ams | rah: stekern means an older. | 09:17 |
| stekern | yes, I understood what you said like that, but he is building an old toolchain | 09:18 |
| rah | stekern: are you saying he needs an earlier release of makeinfo, or that you would describe a later release as "less recent"? :-) | 09:18 |
| rah | oh | 09:18 |
| rah | well that must be really old then, if he's using a makeinfo that isn't backwards compatible | 09:18 |
| stekern | maybe it's time we replace the 'stable' label with 'deprecated' on those old toolchains | 09:19 |
| ams | rah: it isn't. | 09:19 |
| ams | texinfo 5.0 broke a few things | 09:19 |
| stekern | there seems to be no real interest from anyone to maintain the 4.5.3 gcc anymore | 09:20 |
| stekern | Guest51447: if you are the Guest51447 from yesterday, yesterday you were trying to compile the current toolchain, why did you abandon that? | 09:21 |
| Guest51447 | i didnt abondon that | 09:25 |
| Guest51447 | i thought i am missing some Prerequisites libraries that are required to compile the GNU tools so i am trying ........ | 09:26 |
| stekern | ok, but you are not following the same instructions you were following yesterday anymore | 09:27 |
| _franck__ | Guest51447: you are using ./bld-all.sh which is the way to compile the old (stable) toolchain | 09:27 |
| stekern | did you install the missing libraries? | 09:27 |
| Guest51447 | yes | 09:27 |
| Guest51447 | i have installed it | 09:28 |
| stekern | good, yesterday you were following these instructions: http://opencores.org/or1k/OpenRISC_GNU_tool_chain#Linux_.28uClibc.29_toolchain_.28or1k-linux-uclibc.29 | 09:28 |
| stekern | I'd suggest you get back on that track | 09:29 |
| Guest51447 | I know i am new to this installation procedure and it dosenot mean that i am not able to understand and having readablitiy issue | 09:29 |
| Guest51447 | even if am asking simple questions | 09:29 |
| Guest51447 | apolozie for bothering | 09:30 |
| Guest51447 | yeah sure | 09:30 |
| Guest51447 | ok | 09:30 |
| Guest51447 | i will follow the same now | 09:30 |
| Guest51447 | <stekern> : i got an issue while following the procedure at gcc-stage1,I thought to check any Prerequisites libraries that are required to compile are missing | 09:39 |
| stekern | ok, what is the issue now? | 09:40 |
| Guest51447 | its configure-target-libgcc issue | 09:47 |
| Guest51447 | because of dynamic linking issue | 09:48 |
| ams | "full error log" | 09:48 |
| stekern | Guest51447: ok, I think I've seen that. try to build without -j | 09:49 |
| Guest51447 | ok i will try now | 09:49 |
| stekern | and start over from the beginning, i.e. remove the build dir | 09:49 |
| stekern | and rerun configure and then make | 09:49 |
| Guest51447 | ok sure i will try that | 09:50 |
| raja | Hi | 11:52 |
| -!- raja is now known as Guest83812 | 11:53 | |
| Guest83812 | hi <stekern> | 11:53 |
| Guest83812 | sorry for the delay as server was done | 11:54 |
| Guest83812 | As per our discussion , I have tried without -j option still i am facing the issue | 11:56 |
| Guest83812 | log file with error "http://pastebin.com/raw.php?i=BZrdkQgB" | 11:58 |
| stekern | Guest83812: can you provide the config.log file too? | 12:00 |
| Guest83812 | yes one min | 12:00 |
| stekern | the libgcc one | 12:01 |
| stekern | i.e., this: or1k-linux-uclibc/libgcc/config.log | 12:03 |
| Guest83812 | http://pastebin.com/raw.php?i=6HsgQnXD | 12:05 |
| Guest83812 | i am using Ubuntu 14.04 flavour this has any compatability issue | 12:09 |
| stekern | no, that should be fine | 12:13 |
| stekern | /home/aceic18/openrisc/build-gcc/./gcc/as: 106: exec: -o: not found | 12:15 |
| stekern | that's the error message | 12:15 |
| stekern | can't say I immediately understand what that mean | 12:16 |
| stekern | what happens if you run: build-gcc/gcc/as -v | 12:17 |
| Guest83812 | that meansshould i try with -o option while using configure | 12:18 |
| stekern | no | 12:18 |
| Guest83812 | " <stekern> what happens if you run: build-gcc/gcc/as -v " - GNU assembler version 2.24 (i686-linux-gnu) using BFD version (GNU Binutils for Ubuntu) 2.24 | 12:21 |
| maxpaln | good news! I have found and fixed the bug :-) | 12:21 |
| Guest83812 | may i know what do yo mean " what happens if you run: build-gcc/gcc/as -v " | 12:22 |
| maxpaln | bad news, Linux still doesn't boot - but it gets a lot further, which is cause for optimism! I got this now: Kernel panic - not syncing: compression method À not configured | 12:22 |
| stekern | Guest83812: when you are in your build dir, type: gcc/as -v | 12:23 |
| maxpaln | Preliminary checks have shown it jumps to panic() from populate_rootfs() | 12:24 |
| maxpaln | I'm rebuilding the HW with more appropriate ELA triggers as I am assuming this is a HW bug too - | 12:25 |
| maxpaln | My assumption about what has happened: the kernel has tried to unpack the rootfs, failed because it doesn't understand the data it gets back, assumes it is compressed in a format it can't uncompress, and then jump to panic() | 12:26 |
| maxpaln | more to follow... | 12:26 |
| ysionneau | maxpaln: what was your hardware bug? | 12:26 |
| stekern | Guest83812: ah, sorry. I missed that you already pasted the output. That's not right, it should be the or1k-linux-uclibc-as, not the i686-linux-gnu. | 12:27 |
| stekern | Guest83812: do you have /opt/or1k-toolchain/bin in your PATH? | 12:28 |
| maxpaln | ysionneau: it was in the logic I wrote to surround our DDR3 IP controller, I had foolishly forgotten to code for the different types of wrap accesses when clearing a buffer. It meant the buffer wasn't cleared for a very specific type of memory access (The sort of thing that is really difficult to find in simulation) so the next access pulled some errant data from the buffer instead of the | 12:28 |
| maxpaln | correct data. | 12:28 |
| maxpaln | run of the mill stuff really :-) | 12:28 |
| ysionneau | maxpaln: ok :) good finding! | 12:29 |
| maxpaln | yeah, that's two bugs and god knows how many hours to find them!!! | 12:30 |
| maxpaln | such is life | 12:30 |
| maxpaln | they are getting easier to find though - I am improving... | 12:30 |
| ysionneau | ;) | 12:31 |
| maxpaln | this one is interesting - I am intrigued to see what is happening here. At the stage of populating the rootfs the kernel must have gotten a long way through the boot process I guess. the bugs are getting more corner case... | 12:31 |
| ysionneau | sure | 12:31 |
| -!- raja is now known as Guest71487 | 12:32 | |
| Guest71487 | hi <stekern> : /opt/or1k-toolchain/ is there | 12:32 |
| stekern | Guest71487: how about /opt/or1k-toolchain/bin | 12:36 |
| stekern | ? | 12:36 |
| Guest71487 | sorry i dont have bin in it. | 12:37 |
| stekern | try again with that | 12:39 |
| Guest71487 | <stekern> this or1k-toolchain is done at initial prepatations | 12:40 |
| Guest71487 | one thing i want to confirm | 12:41 |
| stekern | yes | 12:41 |
| Guest71487 | using this two commands right | 12:41 |
| Guest71487 | sudo mkdir /opt/or1k-toolchain sudo chown username:username /opt/or1k-toolchain | 12:41 |
| stekern | yes, assuming that username:username is aceic18:aceic18 in your case | 12:42 |
| Guest71487 | i mean http://opencores.org/or1k/OpenRISC_GNU_tool_chain#Initial_preparations | 12:42 |
| Guest71487 | yes | 12:42 |
| Guest71487 | done the same let me give a try once again | 12:43 |
| stekern | and the next step is: export PATH=$PATH:/opt/or1k-toolchain/bin | 12:43 |
| Guest71487 | yes initial preparation is done i have done export also | 12:50 |
| stekern | hmm, so why was the 'bin' missing in the PATH? | 12:54 |
| Guest71487 | <stekern> previously bin has not created now once again i have done the same procedure its created | 12:57 |
| Guest71487 | need to try gcc-stage1 again and see if any error pop up or not | 12:58 |
| stekern | ok | 13:10 |
| Guest71487 | <stekern> yes now no error pops up | 13:21 |
| Guest71487 | thanks <stekern> | 13:23 |
| Guest71487 | for the help | 13:23 |
| stekern | great and no problem | 13:30 |
| maxpaln | gaah, I'm trying to print some debug from decompress.c - it won't let me use pr_info() and it complains about a definition of KERN_INFO for printk(KERN_INFO "msg"); | 13:59 |
| maxpaln | any clues? | 13:59 |
| maxpaln | dang my lack of Linux experience! | 13:59 |
| maxpaln | ok, I should have guessed - linux/printk.h | 14:06 |
| maxpaln | although I don't see that included on a lot of files that make use of printk() so maybe there is a more elevant way!! | 14:07 |
| maxpaln | s/elevant/elegant/ | 14:07 |
| ysionneau | because printk.h is included by a lot of other headers | 14:10 |
| ysionneau | don't worry about that since it's just for debugging, you will remove this include later on | 14:10 |
| maxpaln | ok, I have traced it back through the code a little - it seems that when populate_rootfs is called, __initramfs_size has the value -1 | 14:33 |
| maxpaln | this ripples through to decompress giving up before finding the right decompress method | 14:34 |
| maxpaln | so the question is where is the __initramfs_size written | 14:34 |
| ysionneau | did you embed a ramfs in your kernel? | 14:34 |
| maxpaln | I thought I did | 14:34 |
| maxpaln | I am really not a Linux expert but when configuring the kernel I had the relevant box checked to include the initramfs | 14:35 |
| maxpaln | when I had Linux running on our previous FPGA family I don't remember doing anything more than that | 14:36 |
| _franck__ | maxpaln: if your vmlinux boots with or1ksim then you have a valid rootfs | 14:36 |
| maxpaln | _franck__: ok - great, it boots with or1ksim | 14:36 |
| _franck__ | maxpaln: so you're good | 14:36 |
| maxpaln | :-) in theory | 14:36 |
| maxpaln | except when booting on HW I get: Kernel panic - not syncing: compression method À | 14:37 |
| maxpaln | not configured | 14:37 |
| maxpaln | tracing it back through the code it is caused by _initramfs_size having the value -1 at the point where populate_rootfs is called | 14:37 |
| maxpaln | so is _initramfs_size an intrinsic part of the kernel? | 14:38 |
| maxpaln | or is it calculated during runtime? | 14:38 |
| _franck__ | don't know, nee to check | 14:38 |
| maxpaln | Looking in the disassembled kernel I can see: | 14:39 |
| maxpaln | c03179b8 <__initramfs_size>: | 14:39 |
| maxpaln | c03179b8:00 14 88 00 l.j c08399b8 <__bss_stop+0x514858> | 14:39 |
| _franck__ | https://groups.google.com/forum/#!topic/linux.kernel/eeiR58eaPek | 14:40 |
| maxpaln | aha - great, thanks | 14:41 |
| _franck__ | __initramfs_size is computed during compile time and your value (in the disassembled code) is not equal to -1 so there is something somewhere.... | 14:42 |
| maxpaln | well, I am working on the theory there is still a gremlin in my memory controller - but I am hunting for the entry point to debug | 14:44 |
| maxpaln | I thought I could trigger on accesses to 0xc03179b8 (or 0x003179b8 ) - but the ELA isn't triggering | 14:45 |
| maxpaln | [looking harder] | 14:45 |
| ysionneau | maybe trigger on 0x******9b8 but it might trigger a lot | 14:46 |
| maxpaln | hang on - misconfigured ELA, trying again | 14:46 |
| maxpaln | bingo - it is read back as 0xFFFFFFFF | 14:48 |
| ysionneau | :) | 14:48 |
| ysionneau | pesky hw bugs | 14:48 |
| maxpaln | darn them! | 14:48 |
| stekern | dalias: it was fairly straight forward to modify musl-cross to use a arbitrary source for gcc | 15:07 |
| stekern | binutils snapshots worked out of the box | 15:07 |
| stekern | gcc had a couple of things hardcoded | 15:07 |
| stekern | musl is harder, but that's not an issue once or1k is merged ;) | 15:07 |
| dalias | nice | 15:08 |
| stekern | my stage 2 build fails when it tries to build libstdc++ though | 15:08 |
| stekern | got to investigate that | 15:08 |
| -!- raja is now known as Guest12680 | 17:01 | |
| blueCmd_ | stekern: binutils still lack gdb. did we submit sim? | 17:12 |
| blueCmd_ | stekern: for the "real life period", yes that would have been in the middle of Dreamhack | 17:13 |
| blueCmd_ | stekern: stekern as for the solution, nope - no idea more than what the comment says | 17:14 |
| stekern | blueCmd_: no, sim still missing | 18:03 |
| stekern | blueCmd_: ok, let me rephrase that question. How would I be able to observe breakage if I remove those two lines? | 18:04 |
| dalias | stekern, ok how about i go ahead and commit the port? :) | 18:07 |
| dalias | i think there was just one more change i should make, the __clang__ bug in pthread_arch.h, right? | 18:08 |
| stekern | dalias: sounds great! ;) | 18:08 |
| stekern | yes, if you could fix that before commiting, that'd be great | 18:08 |
| dalias | ok | 18:08 |
| dalias | stekern, done :) | 18:22 |
| stekern | \o/ | 18:40 |
| blueCmd_ | stekern: congrats :-) | 18:57 |
| blueCmd_ | dalias: also, grats on ports++ | 18:57 |
| dalias | :) | 18:58 |
| blueCmd_ | stekern: I'm not sure, try to remove it and run the dwarf tests in GCC | 18:58 |
| -!- Netsplit *.net <-> *.split quits: O01eg | 19:55 | |
| -!- Netsplit over, joins: O01eg | 19:55 | |
| blueCmd_ | kinda cool, I mirrored the wiki on http://openrisc.debian.net/tmp/opencores/opencores.org/or1k/ in just a plain browseable files thing - we have quite a lot of nice information, but it's super-hard to find it today | 20:39 |
| blueCmd_ | stekern: would you mind running the GCC testsuite using glibc or musl? | 20:41 |
| dalias | stekern, i realized our ppc and mips ports seem to be missing barrier instructions that are needed alongside their ll/sc style atomics | 22:35 |
| dalias | stekern, microblaze also has no explicit barriers, but, looking at gcc output for __sync_val_compare_and_swap to see what we might need, it doesn't seem to need any | 22:36 |
| dalias | i guess the synchronization is builtin to their ll/sc | 22:37 |
| dalias | is or1k supposed to work like that too? | 22:37 |
| dalias | or do we need to add some explicit barrier instructions? | 22:37 |
| blueCmd_ | stekern: want to see something cool? | 22:56 |
| blueCmd_ | stekern: https://asciinema.org/a/10885 | 23:07 |
| blueCmd_ | hm, if I try to run Linux in qemu with more than 3f000000 (~1GiB) it doesn't output anything on boot | 23:21 |
| blueCmd_ | odd | 23:21 |
| --- Log closed Sat Jul 19 00:00:25 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!