IRC logs for #openrisc Friday, 2014-07-18

--- Log opened Fri Jul 18 00:00:24 2014
stekernblueCmd_: I think you should02:41
daliasstekern, 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
stekerndalias: sure, no problem04:09
daliasi 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
stekernI was planning on writing up some step-to-step instrucions on how to get an or1k musl system up and running anyways04:10
daliasit 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 support04:11
daliasdo they need patching or does upstream work fully already?04:12
stekernbinutils work fully from upstream04:12
stekerngcc is not upstream04:12
stekernour 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
stekernbut blueCmd_ is working hard on that, so hopefully it will be done soon enough.04:14
daliasah yes :(04:15
stekernblueCmd_: 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
stekernhttp://juliusbaxter.net/openrisc-irc/%23openrisc.2014-06-13.log.html#t04:3105:40
rajahi08:43
-!- raja is now known as Guest5144708:43
Guest51447hi08:47
Guest51447i have problem while Bulid & installing gnu tool - uClibc.08:57
Guest51447Can anyone help me08:57
Guest51447http://pastebin.com/raw.php?i=TX8TvXeK08:57
Guest51447please find the link08:57
amsas was mentioned yesterday, PLEASE PRODUCE THE FULL LOG08:58
amsand please do some actual brain work yourself.08:58
Guest51447i have pasted error in the log file pointed to you through pastebin09:01
amsdid you even read what you pasted?09:02
amsclearly, you didn't.  you did not paste the error in question, which happens far above the last message you got.09:02
amsyou are blindly yanking things for us to decipher for you, without spending any due dilligence in understanding the problem yourself.09:04
Guest51447no ams i am finding error during "To build and install just the uClibc toolchain"09:05
Guest51447i am following thesteps only09:06
amsplease stop building the tool chain.  simply please stop ..09:07
Guest51447Then how can i use GNUtool ?09:09
Guest51447http://pastebin.com/raw.php?i=qfWepwMG09:11
amsi have no idea what GNUtool is.09:11
Guest51447ok thanks alot09: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
amsyeah ...09:13
rahGuest51447: possibly you need a more recent makeinfo?09:14
amsrah: 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
rahams: perhaps we can help him by pointing out the error and explaining how it might be solved09:15
rahams: perhaps he isn't used to errors09:15
amsperhaps, he is incapable of reading.09:16
amsbuilding tool chains is non-trivial.09:16
stekernrah: presumably a *less* recent makeinfo09:16
amsplain impossible if you cannot read error messages09:16
rahstekern: I meant perhaps he needs a later release of makeinfo, which I would describe as "more recent"09:17
amsrah: stekern means an older.09:17
stekernyes, I understood what you said like that, but he is building an old toolchain09:18
rahstekern: are you saying he needs an earlier release of makeinfo, or that you would describe a later release as "less recent"? :-)09:18
rahoh09:18
rahwell that must be really old then, if he's using a makeinfo that isn't backwards compatible09:18
stekernmaybe it's time we replace the 'stable' label with 'deprecated' on those old toolchains09:19
amsrah: it isn't.09:19
amstexinfo 5.0 broke a few things09:19
stekernthere seems to be no real interest from anyone to maintain the 4.5.3 gcc anymore09:20
stekernGuest51447: if you are the Guest51447 from yesterday, yesterday you were trying to compile the current toolchain, why did you abandon that?09:21
Guest51447i didnt abondon that09:25
Guest51447i thought i am missing some Prerequisites libraries that are required to compile the GNU tools so i am trying ........09:26
stekernok, but you are not following the same instructions you were following yesterday anymore09:27
_franck__Guest51447: you are using ./bld-all.sh which is the way to compile the old (stable) toolchain09:27
stekerndid you install the missing libraries?09:27
Guest51447yes09:27
Guest51447i have installed it09:28
stekerngood, yesterday you were following these instructions: http://opencores.org/or1k/OpenRISC_GNU_tool_chain#Linux_.28uClibc.29_toolchain_.28or1k-linux-uclibc.2909:28
stekernI'd suggest you get back on that track09:29
Guest51447I know i am new to this installation procedure and it dosenot mean that i am not able to understand and having readablitiy issue09:29
Guest51447even if  am asking simple questions09:29
Guest51447apolozie for bothering09:30
Guest51447yeah sure09:30
Guest51447ok09:30
Guest51447i will follow the same now09: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 missing09:39
stekernok, what is the issue now?09:40
Guest51447its configure-target-libgcc  issue09:47
Guest51447because of dynamic linking issue09:48
ams"full error log"09:48
stekernGuest51447: ok, I think I've seen that. try to build without -j09:49
Guest51447ok i will try now09:49
stekernand start over from the beginning, i.e. remove the build dir09:49
stekernand rerun configure and then make09:49
Guest51447ok sure i will try that09:50
rajaHi11:52
-!- raja is now known as Guest8381211:53
Guest83812hi <stekern>11:53
Guest83812sorry for the delay as server was done11:54
Guest83812As per our discussion , I have tried without -j option still i am facing the issue11:56
Guest83812log file with error "http://pastebin.com/raw.php?i=BZrdkQgB"11:58
stekernGuest83812: can you provide the config.log file too?12:00
Guest83812yes one min12:00
stekernthe libgcc one12:01
stekerni.e., this: or1k-linux-uclibc/libgcc/config.log12:03
Guest83812http://pastebin.com/raw.php?i=6HsgQnXD12:05
Guest83812i am using Ubuntu 14.04 flavour this has any compatability issue12:09
stekernno, that should be fine12:13
stekern/home/aceic18/openrisc/build-gcc/./gcc/as: 106: exec: -o: not found12:15
stekernthat's the error message12:15
stekerncan't say I immediately understand what that mean12:16
stekernwhat happens if you run: build-gcc/gcc/as -v12:17
Guest83812that meansshould i try with -o option while using configure12:18
stekernno12: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.2412:21
maxpalngood news! I have found and fixed the bug :-)12:21
Guest83812may i know what do yo mean " what happens if you run: build-gcc/gcc/as -v "12:22
maxpalnbad 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 configured12:22
stekernGuest83812: when you are in your build dir, type: gcc/as -v12:23
maxpalnPreliminary checks have shown it jumps to panic() from populate_rootfs()12:24
maxpalnI'm rebuilding the HW with more appropriate ELA triggers as I am assuming this is a HW bug too -12:25
maxpalnMy 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
maxpalnmore to follow...12:26
ysionneaumaxpaln: what was your hardware bug?12:26
stekernGuest83812: 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
stekernGuest83812: do you have /opt/or1k-toolchain/bin in your PATH?12:28
maxpalnysionneau: 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 the12:28
maxpalncorrect data.12:28
maxpalnrun of the mill stuff really :-)12:28
ysionneaumaxpaln: ok :) good finding!12:29
maxpalnyeah, that's two bugs and god knows how many hours to find them!!!12:30
maxpalnsuch is life12:30
maxpalnthey are getting easier to find though - I am improving...12:30
ysionneau;)12:31
maxpalnthis 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
ysionneausure12:31
-!- raja is now known as Guest7148712:32
Guest71487hi <stekern> : /opt/or1k-toolchain/ is there12:32
stekernGuest71487: how about /opt/or1k-toolchain/bin12:36
stekern?12:36
Guest71487sorry i dont have bin in it.12:37
stekerntry again with that12:39
Guest71487<stekern> this or1k-toolchain is done at initial prepatations12:40
Guest71487one thing i want to confirm12:41
stekernyes12:41
Guest71487using this two commands right12:41
Guest71487sudo mkdir /opt/or1k-toolchain sudo chown username:username /opt/or1k-toolchain12:41
stekernyes, assuming that username:username is aceic18:aceic18 in your case12:42
Guest71487 i mean http://opencores.org/or1k/OpenRISC_GNU_tool_chain#Initial_preparations12:42
Guest71487yes12:42
Guest71487done the same let me  give a try once again12:43
stekernand the next step is: export PATH=$PATH:/opt/or1k-toolchain/bin12:43
Guest71487yes initial preparation is done i have done export also12:50
stekernhmm, 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 created12:57
Guest71487need to try gcc-stage1 again and see if any error pop up or not12:58
stekernok13:10
Guest71487<stekern>  yes now no error pops up13:21
Guest71487thanks <stekern>13:23
Guest71487for the help13:23
stekerngreat and no problem13:30
maxpalngaah, 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
maxpalnany clues?13:59
maxpalndang my lack of Linux experience!13:59
maxpalnok, I should have guessed - linux/printk.h14:06
maxpalnalthough 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
maxpalns/elevant/elegant/14:07
ysionneaubecause printk.h is included by a lot of other headers14:10
ysionneaudon't worry about that since it's just for debugging, you will remove this include later on14:10
maxpalnok, I have traced it back through the code a little - it seems that when populate_rootfs is called, __initramfs_size has the value -114:33
maxpalnthis ripples through to decompress giving up before finding the right decompress method14:34
maxpalnso the question is where is the __initramfs_size written14:34
ysionneaudid you embed a ramfs in your kernel?14:34
maxpalnI thought I did14:34
maxpalnI am really not a Linux expert but when configuring the kernel I had the relevant box checked to include the initramfs14:35
maxpalnwhen I had Linux running on our previous FPGA family I don't remember doing anything more than that14:36
_franck__maxpaln: if your vmlinux boots with or1ksim then you have a valid rootfs14:36
maxpaln_franck__: ok - great, it boots with or1ksim14:36
_franck__maxpaln: so you're good14:36
maxpaln:-) in theory14:36
maxpalnexcept when booting on HW I get: Kernel panic - not syncing: compression method À14:37
maxpaln                                                                 not configured14:37
maxpalntracing it back through the code it is caused by _initramfs_size having the value -1 at the point where populate_rootfs is called14:37
maxpalnso is  _initramfs_size an intrinsic part of the kernel?14:38
maxpalnor is it calculated during runtime?14:38
_franck__don't know, nee to check14:38
maxpalnLooking in the disassembled kernel I can see:14:39
maxpalnc03179b8 <__initramfs_size>:14:39
maxpalnc03179b8:00 14 88 00 l.j c08399b8 <__bss_stop+0x514858>14:39
_franck__https://groups.google.com/forum/#!topic/linux.kernel/eeiR58eaPek14:40
maxpalnaha - great, thanks14: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
maxpalnwell, I am working on the theory there is still a gremlin in my memory controller - but I am hunting for the entry point to debug14:44
maxpalnI thought I could trigger on accesses to 0xc03179b8 (or 0x003179b8 ) - but the ELA isn't triggering14:45
maxpaln[looking harder]14:45
ysionneaumaybe trigger on 0x******9b8 but it might trigger a lot14:46
maxpalnhang on - misconfigured ELA, trying again14:46
maxpalnbingo - it is read back as 0xFFFFFFFF14:48
ysionneau:)14:48
ysionneaupesky hw bugs14:48
maxpalndarn them!14:48
stekerndalias: it was fairly straight forward to modify musl-cross to use a arbitrary source for gcc15:07
stekernbinutils snapshots worked out of the box15:07
stekerngcc had a couple of things hardcoded15:07
stekernmusl is harder, but that's not an issue once or1k is merged ;)15:07
daliasnice15:08
stekernmy stage 2 build fails when it tries to build libstdc++ though15:08
stekerngot to investigate that15:08
-!- raja is now known as Guest1268017: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 Dreamhack17:13
blueCmd_stekern: stekern as for the solution, nope - no idea more than what the comment says17:14
stekernblueCmd_: no, sim still missing18:03
stekernblueCmd_: ok, let me rephrase that question. How would I be able to observe breakage if I remove those two lines?18:04
daliasstekern, ok how about i go ahead and commit the port? :)18:07
daliasi think there was just one more change i should make, the __clang__ bug in pthread_arch.h, right?18:08
stekerndalias: sounds great! ;)18:08
stekernyes, if you could fix that before commiting, that'd be great18:08
daliasok18:08
daliasstekern, 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 GCC18:58
-!- Netsplit *.net <-> *.split quits: O01eg19:55
-!- Netsplit over, joins: O01eg19: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 today20:39
blueCmd_stekern: would you mind running the GCC testsuite using glibc or musl?20:41
daliasstekern, i realized our ppc and mips ports seem to be missing barrier instructions that are needed alongside their ll/sc style atomics22:35
daliasstekern, 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 any22:36
daliasi guess the synchronization is builtin to their ll/sc22:37
daliasis or1k supposed to work like that too?22:37
daliasor 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/1088523:07
blueCmd_hm, if I try to run Linux in qemu with more than 3f000000 (~1GiB) it doesn't output anything on boot23:21
blueCmd_odd23: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!