IRC logs for #openrisc Monday, 2014-07-21

--- Log opened Mon Jul 21 00:00:28 2014
blueCmdjeremy_bennett: I managed to check out r133 and r132 and manually diff, so nvm00:13
maxpalnsolved the initramfs_size issue, this bug wasn't actually mine. It is in our SPI Flash writing software - it is miscalculating the size of the binary (really???) and not writing the last few dozen bytes. The initramfs_size is the final four bytes in the kernel so the relevant address in the SPI Flash was erased, which is 0xFFFFFFFF in SPI parlance. I have fixed this now - so the kernel gets06:30
maxpalna little bit further.06:30
maxpalnIt now hangs after:06:30
maxpalnSwitched to clocksource openrisc_timer06:30
maxpalnunpack_to_rootfs: len is 134553606:30
maxpalnjffs2: version 2.2. (NAND) © 2001-2006 Red Hat, Inc.06:30
maxpalnBooo - one more to debug...06:31
maxpalnalthough i think I have working FPGA HW now, I think these are now SW problems...06:58
stekernmaxpaln: that's not the same kernel you had working with or1ksim, is it?07:11
maxpalnyes, the same one - I guess you are referring to the loading of jffs207:25
maxpalnThe dts file doesn't refer to the SPI Flash but I think I am including the drivers in the kernel (they were in there from the last working kernel I had - and I will be including the SPI Flash once I have the basic boot working)07:27
maxpalnIn or1ksim the boot sequence progresses to the UART drivers after loading the jffs2 drivers:07:35
maxpalnunpack_to_rootfs: len is 134553607:35
maxpalnjffs2: version 2.2. (NAND) © 2001-2006 Red Hat, Inc.07:35
maxpalnSerial: 8250/16550 driver, 4 ports, IRQ sharing disabled07:35
maxpalnSO I need to track down the issue between these07:36
stekernah, ok07:44
maxpalnalthough I am struggling to find the entry point to the jffs2 drivers - the above message gets printed inside init_jffs2_fs(), which in turn appears to get called from module_init() in the same file (fs/jffs2/super.c)07:48
maxpalnbut module_init() is a very common function :-|07:49
stekerndon't you see where it get stuck from your ILA?07:49
maxpalnI was spending a little time working on it from the SW side first- trying to understand the flow of calls07:50
maxpalnI'll give it another few minutes then jump into the ELA - it's generally quicker to debug via SW - but only if I can navigate the maze :-)07:50
maxpalnplus, finding a function in SW makes finding the starting point in HW a lot easier!07:52
blueCmdstekern: svn2github.com managed to convert the big openrisc repo! \o/ svn2git failed horribly08:13
blueCmddo you happen to have some mail or something left that might contain the changes?08:13
blueCmdugh08:13
blueCmdhttps://github.com/svn2github/openrisc08:13
blueCmdhttps://github.com/openrisc/openrisc-docs tadaa08:16
blueCmdit's too bad it didn't absorb the trnk/tags/branches - but it's better than nothing I guess08:17
poke53281one question to stekern and blueCmd: Did you every try the ethoc.c driver in this repository: https://github.com/bluecmd/or1k-linux08:52
poke53281I checked the repository from jonas with Linux 3.13 and this one.08:53
poke53281In both the ethoc.c driver is identical.08:53
poke53281But in Linux 3.15 I get strange error messages08:54
blueCmdpoke53281: I'm using it in qemu08:54
poke53281Mhh, I get a strange timeout error when the kernel tries to attach the phy device.09:00
poke53281It's not an endianess problem.09:02
stekernpoke53281: I've tested that in a branch that's basically based of the one you are using now.09:06
stekernthere was some phy related patches among the out of tree patches, you can check if they got along correctly09:07
stekernhow can I get verilator to dump larger block rams?09:44
blueCmdstekern: fyi, I _think_ i now have a 'fire and forget' script that will run the gcc testsuite on Google Cloud11:06
blueCmdwhich is quite neat since you're building everything in a clean environment and testing it on an instance asynchroniously11:07
stekernsounds great11:20
stekernI think I have a shadow rf that can be written and read with SPRs now11:20
stekernwonder if or1ksim support that out of the box11:21
stekerns/with SPRs/as SPRs11:21
stekernit's also possible to write the normal RF as SPR too11:23
stekern...which is nice if you want to change a reg directly from gdb...11:23
stekernwallento: ^ i.e. we can soon remove the SPR_ISR hack11:24
wallentonice one!11:25
wallentothanks11:25
stekernI can't remember what the status was last we spoke, but the dcache snooping is stable now at least11:29
stekernand I've been keeping this branch in sync with master: https://github.com/openrisc/mor1kx/commits/multicore11:30
maxpalnHmmm, curious - the kernel is iterating through the task scheduler when it hangs. It is somewhere in the schedule() loop (kernel/sched/core.c) when it hangs. However, adding debug into the scheduler process causes varying functionality. I have caused an infinite loop within the scheduling process and I have also caused the kernel to almost fully boot (getting as far as 'init started: BusyBox11:55
maxpalnv1.19.0.git (2011-02-16 08:10:12 CET)11:55
maxpaln'!) Time to switch to the ELA I think.11:55
blueCmdstekern: http://openrisc.debian.net/tmp/gcc-test-jul-21/gcc.fail if you're interested12:10
blueCmdas for gcc.dg/atomic/c11-atomic-exec-4.c and gcc.dg/torture/tls/tls-test.c those are broken because pthread_create segfaults. go figure12:18
stekernwhat are you running the tests on?12:19
stekerngcc.dg/stack-usage-1.c and gcc.dg/stack-usage-2.c are old failures12:21
blueCmdstekern: qemu with your smp kernel and my glibc12:23
blueCmdstekern: some failures are 'timeouts' as well, I'm running two in parallell now to be able to detect flakyness12:24
stekernwhat timeout do you have?12:47
blueCmd300 sec12:47
poke53281finally ethoc works.13:26
blueCmdpoke53281: root cause?13:26
poke53281The entity between screen and chair.13:27
poke53281Indeed, the implementation of the device was not fully correct.13:27
blueCmdaha!13:27
poke53281And the Linux behavior changed in 3.15.13:27
poke53281For some reason, Linux resets part of the device.13:28
poke53281But still, I get a segmentation fault when I try to chroot to debian.13:29
blueCmdpoke53281: yeah, I need to heal Debian13:31
poke53281you know the problem?13:32
blueCmdglibc and gcc is already much better, so I need to recompile those packages - but I have some regressions that I want to fix before (http://openrisc.debian.net/tmp/gcc-test-jul-21/gcc.fail)13:32
blueCmdpoke53281: there are a lot of candidates to what might be the problem. for now I'm just focusing on making the gcc tests succeed which should be enough to compile glibc and then I think a lot of things will work again13:33
blueCmdthat's the nice/bad thing with dynamic linking13:33
poke53281Ok, thanks13:33
blueCmdif you want it working ASAP, you could try downgrading the libc in your chroot13:34
poke53281Ahh, well. I can wait13:34
blueCmdcool13:35
poke53281But it is also possible, that I made a mistake somewhere.13:37
poke53281I think it would be also better, if your repository would use a stable kernel.13:39
blueCmdpoke53281: well then you wouldn't have ethoc support13:47
blueCmdbut yes, I agree13:47
poke53281???13:49
poke53281you can merge with a stable kernel, or am I wrong?13:49
poke53281Or with a relatively high release candidate.13:50
blueCmdpoke53281: oh right. I could have them as debian-patches13:50
blueCmdthat would work yes13:50
blueCmdespecially now when stekern has made it nicely rebased13:51
blueCmdpoke53281: not super-sure it would make sense to ship a kernel though13:55
blueCmdI mean, a lot of boards has their own DTSs13:55
poke53281Yes, what I mean is, that you should keep your or1k-linux repository on a state, that is as close as possible to a stable kernel release.13:56
poke53281If I compile your repository it is possible, that we have bugs, which are not related to openrisc.13:57
blueCmdpoke53281: I see what you mean14:01
stekernpoke53281: at least the tree that I did the rebase in is based on the 3.15 release14:06
stekernbut perhaps you meant 3.x.y releases14:06
poke53281no, 3.15.0 is Ok.14:11
poke53281uname -a shows me a dirty kernel14:11
blueCmdit is a dirty kernel14:12
blueCmdpoke53281: but on page 3 you will find Linus's 3.15 commit14:12
blueCmdhttps://github.com/bluecmd/or1k-linux/commits/smp?page=314:12
rahdoes anybody have an FPGA board they'd be willing to part with?14:16
blueCmdrah: what are you looking for?14:17
rahblueCmd: a sockit or a Xilinx board?14:19
rahit seems Xilinx has better free software programming tools14:19
blueCmdrah: sorry no, there was a post on /r/FPGA on reddit about a guy looking for buyers of his DE4 board, but that's altera14:20
rahhmm14:20
rahhmm14:21
rahthe sockit retails here for about £208 (~US$254)14:22
raherr ~US$35414:22
rahat $2995 for a DE4, I think that might not be the way to go :-)14:23
blueCmdrah: well, this would be 2nd hand for a board that is pretty old, so it wouldn't be that price - but yes, sockit is cheap14:24
rahblueCmd: I wouldn't turn down an Altera board, if it was the right price :-)14:24
rahI can't imagine that guy accepting $300 for his board14:30
* rah asks him14:40
blueCmdrah: the worst that can happen is that you get a 'no' :)14:41
rahweeeellll... actually, I just signed up to reddit for the first time so there's a whole load of privacy worst-case scenarios that could happen now ;-)14:42
rahbut yes, he could (and probably will) just say 'no'14:42
markus_wannerShouldn't there be quite a few bitcoin enthusiasts that now sell their FPGA for an ASIC? Or am I too late to that party, already?15:09
daliasmarkus_wanner, not too late to make money, just too late to make money mining bitcoins15:14
daliasthe way you make money now is by selling ASICs to people who think they can make money mining bitcoins15:14
dalias:)15:14
markus_wannerdalias: I'm not interested in mining bitcoins. I'm interested in getting an FPGA board, though.15:15
daliasohhh you want to buy from ppl who realize they got scammed after they failed to make money mining. got it. :)15:16
daliasyeah in principle that sounds like a good way to get cheap FPGA15:16
daliasdunno if there are actually many such sellers tho15:17
markus_wanner..although specifically targetted BTC mining boards tend to have very few I/O ports.15:17
markus_wannerBut at least they have shiny LEDs and loud fans:15:20
markus_wannerhttps://bitcointalk.org/index.php?topic=87761.015:20
markus_wanner:-)15:20
markus_wannerThat was 2012 ... "all boards sold" in March 2013 (on another post). Looks like I'm too late with that idea, too. :-(15:21
rahlooking through ebay, there are a number of boards there going for prices well above the RRP :-/15:27
rahparticularly Digilent boards15:28
* rah suspects unscrupulous sellers15:28
blueCmd"This board was owned by Steve Jobs"15:47
rahI'm wondering if a Parallela board with a Zynq in it would be useful for OpenRISC purposes16:00
rahhttp://forums.parallella.org/viewtopic.php?f=23&t=63916:19
rahmeta16:19
rahand/or cyclic16:21
blueCmdrah: sure it would17:04
blueCmdrah: looking at the architecture it should be possible to attach an AXI-master to the bus and use all the periphreals in an openrisc, but I'm not sure if the schematic is simplified or if that's actually true17:14
* stekern has that board17:15
stekernblueCmd: I took a look at what other archs do with their atomic insns in qemu, seems like there would be a lot of examples to adapt from17:19
blueCmdstekern: probably, I didn't spend much time implementing it17:21
blueCmdMaybe I should though, currently I have a problem that program execution deadlocks every 10:th or so attempt17:22
jeremy_bennettblueCmd: Just seen your email from earlier.17:28
jeremy_bennettThere might be a discussion in the forums about Jungsook17:28
jeremy_bennettOr possibly even the mailing list, although I think it predates that17:29
blueCmdjeremy_bennett: cool!18:08
blueCmdjeremy_bennett: I was going to ask you about your experience in submitting new ports. As far as I can decode from the internet, there is something called a GCC Steering Committee that will need to review the port18:09
jeremy_bennettblueCmd: If you find you are still stuck, get in touch. I'm just back from the GNU Tools Cauldron, so may have more time to pay attention.18:09
blueCmdas for the actual submission process, I have no clue18:09
jeremy_bennettNew ports need approval, but that should not of itself be a problem.18:09
blueCmdjeremy_bennett: aha! cool, you might have inadvertenly spoken with a guy named Manuel that is helping me with the Debian port then :)18:09
jeremy_bennettPossibly. There were 150 attendees and my memory of names and faces is *terrible*18:10
blueCmdjeremy_bennett: also, I took a look at what code there is that belongs to authors that I have been unable to reach, and it seems to only be Jungsook (manageable) and Matjaz Breskvar (not so manageable, need to get hold of him).18:11
blueCmdjeremy_bennett: haha, I hear you :)18:11
jeremy_bennettYou really want to get a new port in before the end of stage 1 for the 4.10/5.0 release18:11
blueCmdJungsook was a co-author with juliusb for the floating point stuff, Matjaz has written quite a lot from what I can tell18:12
jeremy_bennettYes - I always regarded Matjaz as the biggest step to deal with. Have you tried calling him at BA Semi?18:12
blueCmdI haven't, the initial email was sent out to his opencores.org address, which looking back was doomed to fail. I re-sent it to his bsemi.com address18:13
jeremy_bennettAt the cauldron the suggestion was Stage 1 would close at the end of September. So you really want to get in for code review ASAP.18:13
jeremy_bennettEssential the port follows the GCC style guide, but more important that it follows the GCC design philosophy (see how other major ports do things to help with this).18:14
jeremy_bennettI suggest you get your patch prepared ASAP, and I'll see if Joern Rennecke (amylaar) can spare some time to give a preliminary review.18:14
jeremy_bennettYou'll also need someone to be a maintainer, and that person ought to be someone recognized. Certainly it would be a good idea to already be someone with a few GCC patches already under their belt and with write-after-approval permission.18:15
jeremy_bennettI would suggest get your patch prepared in parallel with clearing up Joon Sook and Matjaz.18:16
jeremy_bennettFor Matjaz I think telephone will be the only suitable route. I would be inclined to follow the line that upstream acceptance of the OpenRISC tool chain will add credibility, which will be good for BA Semi selling their designs, since these are OpenRISC derivatives18:17
jeremy_bennettYou might like to look at their EE Times article of a year or two ago before speaking to him.18:18
jeremy_bennettblueCmd: I'm about to head off home, but should be online tomorrow18:19
blueCmdjeremy_bennett: much valueable input, thanks!18:32
blueCmdstekern: surprisingly many differences between or1k-gcc and the upstream merge point19:30
blueCmdstuff that shouldn't really be different like fortran, java and documentation stuff19:30
blueCmdthe merge point being a7aa383819:33
rahstekern: you have a parallela?19:54
stekernrah: yes19:57
stekernblueCmd: I don't see that?19:58
blueCmdstekern: really? if you do 'git diff master a7aa3838' that only contains or1k changes?20:00
rahstekern: have you managed to use any of the peripherals through the ARM bus?20:02
stekernthere's no master branch, but yes I see the differences in arm and i386 and a bunch of other too. I guess those got autoresolved after the big rebase debacle.20:02
rahstekern: would you say it was worth getting?20:02
stekernrah: haven't got around to do anything with it20:02
blueCmdstekern: yes, I guess so - but we shouldn't have touched them so they shouldn't have needed to have been resolved20:02
blueCmdanyway, I'm not going to include them in the patch obviously20:03
stekernblueCmd: but you did touch them, since you rebased upstrean work ontop of your own20:03
blueCmdstekern: do you happen to know if I should base this patch upon svn/trunk or the latest release? svn/trunk would be my guess, but I want to be sure20:03
rahstekern: ah :-)20:03
stekernI have no idea ;)20:03
blueCmdstekern: right, but I rebased the same commit - the commits applied to the other tree should not have conflicted in those files20:04
blueCmdmaybe I don't understand enough about rebase internals20:04
stekernno, I'm speaking about your earlier rebase20:04
blueCmdlet's forget that one :P20:05
blueCmdI've done some rebases I'm not proud of20:05
stekernit's hard when the tree is a complete mess with diffs in arm and i386 and all over the place ;)20:06
blueCmdstekern: don't fret! this will all be good soon enough :)20:07
stekernhehe, don't worry, I'm just teasing you.20:08
blueCmdstekern: good :P20:09
stekernif you feel like it, you could revert the mismerges in the unrelated files though20:10
blueCmdwouldn't that polute the tree more?20:12
blueCmdthe way I'm constructing the patch is currently to squash everything to gether to a single commit and then apply it, obviously that kind of sucks from an internal perspective, but when it's merged that might be fine enough20:13
blueCmdthat is what will happen with or1k-src I bet20:13
blueCmdour local revision history will silently die when we explode or1k-src in parts, no use to having a non-upstream binutils then20:14
stekernwell, it would at least be correct, it's already polluted20:14
stekernsure, but we should of course break out gdb and newlib with their respective histories intact until they get upstreamed as wel20:16
blueCmdyeah20:17
blueCmd*sigh*20:17
stekernfrom what I can see it's just a mismerge in amd.md and i386.md and the documentation got screwed up since my editor obviously added newlines to the end of them when I resolved the conflicts20:21
blueCmdright20:22
blueCmdanyway, stekern - have you seen this before?20:22
blueCmd./target-hooks-def.h:455:31: error: ‘default_expand_builtin’ was not declared in this scope20:22
blueCmdI know I got that while rebasing in the past but I cannot for my life remember what was the issue20:22
blueCmdmaybe it suddenly became mandatory to define TARGET_EXPAND_BUILTIN, but I doubt it20:23
stekerndon't think I've seen that20:23
stekernis that when you apply the or1k diff to tip of svn?20:23
blueCmdyes20:25
blueCmdhm, it's still defined in builtins.c just like last version (default_expand_builtin that is)20:26
stekernblueCmd:20:33
stekernhttps://github.com/openrisc/or1k-gcc/commit/c729a0dbac13ca875637e8852310852b5d66daa920:33
blueCmdstekern: cool! thanks20:35
blueCmdstekern: I found that #include "builtins.h" was the last include on most arches20:35
blueCmdsuspicious :)20:35
stekernindeed20:36
blueCmdstekern: I think we can remove some of the test overrides btw20:36
blueCmdsome seems to be to workaround the alignment that we shouldn't do anymore20:36
stekernyes, probably20:37
stekernI haven't looked through them at all after that change20:38
blueCmdhm20:48
blueCmdgcc crashes when I compile glibc, I wonder if svn is actually a tad bit unstable20:49
stekerncool, or1ksim supports accessing the gpr address space outside of the normal 3220:51
blueCmdstekern: cool I guess :)20:58
stekernthat just means that a kernel built for what I'm currently adding support for in mor1kx will work on old or1ksim20:59
blueCmdah, that is nice!21:00
blueCmdman, either trunk is really unstable or we will have a fun time merging21:13
blueCmdsure helps if I regenerate configure..22:26
blueCmdstekern: FYI:23:20
blueCmdhttps://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=cfbc1a6ceba60d30e46ee82af8ea6803fec4a44923:20
blueCmdhttps://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=3d52a869b2e09d88fc0ebae762d25428d891dd1123:20
--- Log closed Tue Jul 22 00:00:30 2014

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