| --- Log opened Mon Jul 21 00:00:28 2014 | ||
| blueCmd | jeremy_bennett: I managed to check out r133 and r132 and manually diff, so nvm | 00:13 |
|---|---|---|
| maxpaln | solved 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 gets | 06:30 |
| maxpaln | a little bit further. | 06:30 |
| maxpaln | It now hangs after: | 06:30 |
| maxpaln | Switched to clocksource openrisc_timer | 06:30 |
| maxpaln | unpack_to_rootfs: len is 1345536 | 06:30 |
| maxpaln | jffs2: version 2.2. (NAND) © 2001-2006 Red Hat, Inc. | 06:30 |
| maxpaln | Booo - one more to debug... | 06:31 |
| maxpaln | although i think I have working FPGA HW now, I think these are now SW problems... | 06:58 |
| stekern | maxpaln: that's not the same kernel you had working with or1ksim, is it? | 07:11 |
| maxpaln | yes, the same one - I guess you are referring to the loading of jffs2 | 07:25 |
| maxpaln | The 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 |
| maxpaln | In or1ksim the boot sequence progresses to the UART drivers after loading the jffs2 drivers: | 07:35 |
| maxpaln | unpack_to_rootfs: len is 1345536 | 07:35 |
| maxpaln | jffs2: version 2.2. (NAND) © 2001-2006 Red Hat, Inc. | 07:35 |
| maxpaln | Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled | 07:35 |
| maxpaln | SO I need to track down the issue between these | 07:36 |
| stekern | ah, ok | 07:44 |
| maxpaln | although 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 |
| maxpaln | but module_init() is a very common function :-| | 07:49 |
| stekern | don't you see where it get stuck from your ILA? | 07:49 |
| maxpaln | I was spending a little time working on it from the SW side first- trying to understand the flow of calls | 07:50 |
| maxpaln | I'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 |
| maxpaln | plus, finding a function in SW makes finding the starting point in HW a lot easier! | 07:52 |
| blueCmd | stekern: svn2github.com managed to convert the big openrisc repo! \o/ svn2git failed horribly | 08:13 |
| blueCmd | do you happen to have some mail or something left that might contain the changes? | 08:13 |
| blueCmd | ugh | 08:13 |
| blueCmd | https://github.com/svn2github/openrisc | 08:13 |
| blueCmd | https://github.com/openrisc/openrisc-docs tadaa | 08:16 |
| blueCmd | it's too bad it didn't absorb the trnk/tags/branches - but it's better than nothing I guess | 08:17 |
| poke53281 | one question to stekern and blueCmd: Did you every try the ethoc.c driver in this repository: https://github.com/bluecmd/or1k-linux | 08:52 |
| poke53281 | I checked the repository from jonas with Linux 3.13 and this one. | 08:53 |
| poke53281 | In both the ethoc.c driver is identical. | 08:53 |
| poke53281 | But in Linux 3.15 I get strange error messages | 08:54 |
| blueCmd | poke53281: I'm using it in qemu | 08:54 |
| poke53281 | Mhh, I get a strange timeout error when the kernel tries to attach the phy device. | 09:00 |
| poke53281 | It's not an endianess problem. | 09:02 |
| stekern | poke53281: I've tested that in a branch that's basically based of the one you are using now. | 09:06 |
| stekern | there was some phy related patches among the out of tree patches, you can check if they got along correctly | 09:07 |
| stekern | how can I get verilator to dump larger block rams? | 09:44 |
| blueCmd | stekern: fyi, I _think_ i now have a 'fire and forget' script that will run the gcc testsuite on Google Cloud | 11:06 |
| blueCmd | which is quite neat since you're building everything in a clean environment and testing it on an instance asynchroniously | 11:07 |
| stekern | sounds great | 11:20 |
| stekern | I think I have a shadow rf that can be written and read with SPRs now | 11:20 |
| stekern | wonder if or1ksim support that out of the box | 11:21 |
| stekern | s/with SPRs/as SPRs | 11:21 |
| stekern | it's also possible to write the normal RF as SPR too | 11:23 |
| stekern | ...which is nice if you want to change a reg directly from gdb... | 11:23 |
| stekern | wallento: ^ i.e. we can soon remove the SPR_ISR hack | 11:24 |
| wallento | nice one! | 11:25 |
| wallento | thanks | 11:25 |
| stekern | I can't remember what the status was last we spoke, but the dcache snooping is stable now at least | 11:29 |
| stekern | and I've been keeping this branch in sync with master: https://github.com/openrisc/mor1kx/commits/multicore | 11:30 |
| maxpaln | Hmmm, 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: BusyBox | 11:55 |
| maxpaln | v1.19.0.git (2011-02-16 08:10:12 CET) | 11:55 |
| maxpaln | '!) Time to switch to the ELA I think. | 11:55 |
| blueCmd | stekern: http://openrisc.debian.net/tmp/gcc-test-jul-21/gcc.fail if you're interested | 12:10 |
| blueCmd | as 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 figure | 12:18 |
| stekern | what are you running the tests on? | 12:19 |
| stekern | gcc.dg/stack-usage-1.c and gcc.dg/stack-usage-2.c are old failures | 12:21 |
| blueCmd | stekern: qemu with your smp kernel and my glibc | 12:23 |
| blueCmd | stekern: some failures are 'timeouts' as well, I'm running two in parallell now to be able to detect flakyness | 12:24 |
| stekern | what timeout do you have? | 12:47 |
| blueCmd | 300 sec | 12:47 |
| poke53281 | finally ethoc works. | 13:26 |
| blueCmd | poke53281: root cause? | 13:26 |
| poke53281 | The entity between screen and chair. | 13:27 |
| poke53281 | Indeed, the implementation of the device was not fully correct. | 13:27 |
| blueCmd | aha! | 13:27 |
| poke53281 | And the Linux behavior changed in 3.15. | 13:27 |
| poke53281 | For some reason, Linux resets part of the device. | 13:28 |
| poke53281 | But still, I get a segmentation fault when I try to chroot to debian. | 13:29 |
| blueCmd | poke53281: yeah, I need to heal Debian | 13:31 |
| poke53281 | you know the problem? | 13:32 |
| blueCmd | glibc 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 |
| blueCmd | poke53281: 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 again | 13:33 |
| blueCmd | that's the nice/bad thing with dynamic linking | 13:33 |
| poke53281 | Ok, thanks | 13:33 |
| blueCmd | if you want it working ASAP, you could try downgrading the libc in your chroot | 13:34 |
| poke53281 | Ahh, well. I can wait | 13:34 |
| blueCmd | cool | 13:35 |
| poke53281 | But it is also possible, that I made a mistake somewhere. | 13:37 |
| poke53281 | I think it would be also better, if your repository would use a stable kernel. | 13:39 |
| blueCmd | poke53281: well then you wouldn't have ethoc support | 13:47 |
| blueCmd | but yes, I agree | 13:47 |
| poke53281 | ??? | 13:49 |
| poke53281 | you can merge with a stable kernel, or am I wrong? | 13:49 |
| poke53281 | Or with a relatively high release candidate. | 13:50 |
| blueCmd | poke53281: oh right. I could have them as debian-patches | 13:50 |
| blueCmd | that would work yes | 13:50 |
| blueCmd | especially now when stekern has made it nicely rebased | 13:51 |
| blueCmd | poke53281: not super-sure it would make sense to ship a kernel though | 13:55 |
| blueCmd | I mean, a lot of boards has their own DTSs | 13:55 |
| poke53281 | Yes, 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 |
| poke53281 | If I compile your repository it is possible, that we have bugs, which are not related to openrisc. | 13:57 |
| blueCmd | poke53281: I see what you mean | 14:01 |
| stekern | poke53281: at least the tree that I did the rebase in is based on the 3.15 release | 14:06 |
| stekern | but perhaps you meant 3.x.y releases | 14:06 |
| poke53281 | no, 3.15.0 is Ok. | 14:11 |
| poke53281 | uname -a shows me a dirty kernel | 14:11 |
| blueCmd | it is a dirty kernel | 14:12 |
| blueCmd | poke53281: but on page 3 you will find Linus's 3.15 commit | 14:12 |
| blueCmd | https://github.com/bluecmd/or1k-linux/commits/smp?page=3 | 14:12 |
| rah | does anybody have an FPGA board they'd be willing to part with? | 14:16 |
| blueCmd | rah: what are you looking for? | 14:17 |
| rah | blueCmd: a sockit or a Xilinx board? | 14:19 |
| rah | it seems Xilinx has better free software programming tools | 14:19 |
| blueCmd | rah: sorry no, there was a post on /r/FPGA on reddit about a guy looking for buyers of his DE4 board, but that's altera | 14:20 |
| rah | hmm | 14:20 |
| rah | hmm | 14:21 |
| rah | the sockit retails here for about £208 (~US$254) | 14:22 |
| rah | err ~US$354 | 14:22 |
| rah | at $2995 for a DE4, I think that might not be the way to go :-) | 14:23 |
| blueCmd | rah: well, this would be 2nd hand for a board that is pretty old, so it wouldn't be that price - but yes, sockit is cheap | 14:24 |
| rah | blueCmd: I wouldn't turn down an Altera board, if it was the right price :-) | 14:24 |
| rah | I can't imagine that guy accepting $300 for his board | 14:30 |
| * rah asks him | 14:40 | |
| blueCmd | rah: the worst that can happen is that you get a 'no' :) | 14:41 |
| rah | weeeellll... 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 |
| rah | but yes, he could (and probably will) just say 'no' | 14:42 |
| markus_wanner | Shouldn'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 |
| dalias | markus_wanner, not too late to make money, just too late to make money mining bitcoins | 15:14 |
| dalias | the way you make money now is by selling ASICs to people who think they can make money mining bitcoins | 15:14 |
| dalias | :) | 15:14 |
| markus_wanner | dalias: I'm not interested in mining bitcoins. I'm interested in getting an FPGA board, though. | 15:15 |
| dalias | ohhh you want to buy from ppl who realize they got scammed after they failed to make money mining. got it. :) | 15:16 |
| dalias | yeah in principle that sounds like a good way to get cheap FPGA | 15:16 |
| dalias | dunno if there are actually many such sellers tho | 15:17 |
| markus_wanner | ..although specifically targetted BTC mining boards tend to have very few I/O ports. | 15:17 |
| markus_wanner | But at least they have shiny LEDs and loud fans: | 15:20 |
| markus_wanner | https://bitcointalk.org/index.php?topic=87761.0 | 15:20 |
| markus_wanner | :-) | 15:20 |
| markus_wanner | That was 2012 ... "all boards sold" in March 2013 (on another post). Looks like I'm too late with that idea, too. :-( | 15:21 |
| rah | looking through ebay, there are a number of boards there going for prices well above the RRP :-/ | 15:27 |
| rah | particularly Digilent boards | 15:28 |
| * rah suspects unscrupulous sellers | 15:28 | |
| blueCmd | "This board was owned by Steve Jobs" | 15:47 |
| rah | I'm wondering if a Parallela board with a Zynq in it would be useful for OpenRISC purposes | 16:00 |
| rah | http://forums.parallella.org/viewtopic.php?f=23&t=639 | 16:19 |
| rah | meta | 16:19 |
| rah | and/or cyclic | 16:21 |
| blueCmd | rah: sure it would | 17:04 |
| blueCmd | rah: 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 true | 17:14 |
| * stekern has that board | 17:15 | |
| stekern | blueCmd: 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 from | 17:19 |
| blueCmd | stekern: probably, I didn't spend much time implementing it | 17:21 |
| blueCmd | Maybe I should though, currently I have a problem that program execution deadlocks every 10:th or so attempt | 17:22 |
| jeremy_bennett | blueCmd: Just seen your email from earlier. | 17:28 |
| jeremy_bennett | There might be a discussion in the forums about Jungsook | 17:28 |
| jeremy_bennett | Or possibly even the mailing list, although I think it predates that | 17:29 |
| blueCmd | jeremy_bennett: cool! | 18:08 |
| blueCmd | jeremy_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 port | 18:09 |
| jeremy_bennett | blueCmd: 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 |
| blueCmd | as for the actual submission process, I have no clue | 18:09 |
| jeremy_bennett | New ports need approval, but that should not of itself be a problem. | 18:09 |
| blueCmd | jeremy_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_bennett | Possibly. There were 150 attendees and my memory of names and faces is *terrible* | 18:10 |
| blueCmd | jeremy_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 |
| blueCmd | jeremy_bennett: haha, I hear you :) | 18:11 |
| jeremy_bennett | You really want to get a new port in before the end of stage 1 for the 4.10/5.0 release | 18:11 |
| blueCmd | Jungsook was a co-author with juliusb for the floating point stuff, Matjaz has written quite a lot from what I can tell | 18:12 |
| jeremy_bennett | Yes - I always regarded Matjaz as the biggest step to deal with. Have you tried calling him at BA Semi? | 18:12 |
| blueCmd | I 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 address | 18:13 |
| jeremy_bennett | At 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_bennett | Essential 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_bennett | I 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_bennett | You'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_bennett | I would suggest get your patch prepared in parallel with clearing up Joon Sook and Matjaz. | 18:16 |
| jeremy_bennett | For 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 derivatives | 18:17 |
| jeremy_bennett | You might like to look at their EE Times article of a year or two ago before speaking to him. | 18:18 |
| jeremy_bennett | blueCmd: I'm about to head off home, but should be online tomorrow | 18:19 |
| blueCmd | jeremy_bennett: much valueable input, thanks! | 18:32 |
| blueCmd | stekern: surprisingly many differences between or1k-gcc and the upstream merge point | 19:30 |
| blueCmd | stuff that shouldn't really be different like fortran, java and documentation stuff | 19:30 |
| blueCmd | the merge point being a7aa3838 | 19:33 |
| rah | stekern: you have a parallela? | 19:54 |
| stekern | rah: yes | 19:57 |
| stekern | blueCmd: I don't see that? | 19:58 |
| blueCmd | stekern: really? if you do 'git diff master a7aa3838' that only contains or1k changes? | 20:00 |
| rah | stekern: have you managed to use any of the peripherals through the ARM bus? | 20:02 |
| stekern | there'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 |
| rah | stekern: would you say it was worth getting? | 20:02 |
| stekern | rah: haven't got around to do anything with it | 20:02 |
| blueCmd | stekern: yes, I guess so - but we shouldn't have touched them so they shouldn't have needed to have been resolved | 20:02 |
| blueCmd | anyway, I'm not going to include them in the patch obviously | 20:03 |
| stekern | blueCmd: but you did touch them, since you rebased upstrean work ontop of your own | 20:03 |
| blueCmd | stekern: 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 sure | 20:03 |
| rah | stekern: ah :-) | 20:03 |
| stekern | I have no idea ;) | 20:03 |
| blueCmd | stekern: right, but I rebased the same commit - the commits applied to the other tree should not have conflicted in those files | 20:04 |
| blueCmd | maybe I don't understand enough about rebase internals | 20:04 |
| stekern | no, I'm speaking about your earlier rebase | 20:04 |
| blueCmd | let's forget that one :P | 20:05 |
| blueCmd | I've done some rebases I'm not proud of | 20:05 |
| stekern | it's hard when the tree is a complete mess with diffs in arm and i386 and all over the place ;) | 20:06 |
| blueCmd | stekern: don't fret! this will all be good soon enough :) | 20:07 |
| stekern | hehe, don't worry, I'm just teasing you. | 20:08 |
| blueCmd | stekern: good :P | 20:09 |
| stekern | if you feel like it, you could revert the mismerges in the unrelated files though | 20:10 |
| blueCmd | wouldn't that polute the tree more? | 20:12 |
| blueCmd | the 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 enough | 20:13 |
| blueCmd | that is what will happen with or1k-src I bet | 20:13 |
| blueCmd | our local revision history will silently die when we explode or1k-src in parts, no use to having a non-upstream binutils then | 20:14 |
| stekern | well, it would at least be correct, it's already polluted | 20:14 |
| stekern | sure, but we should of course break out gdb and newlib with their respective histories intact until they get upstreamed as wel | 20:16 |
| blueCmd | yeah | 20:17 |
| blueCmd | *sigh* | 20:17 |
| stekern | from 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 conflicts | 20:21 |
| blueCmd | right | 20:22 |
| blueCmd | anyway, stekern - have you seen this before? | 20:22 |
| blueCmd | ./target-hooks-def.h:455:31: error: ‘default_expand_builtin’ was not declared in this scope | 20:22 |
| blueCmd | I know I got that while rebasing in the past but I cannot for my life remember what was the issue | 20:22 |
| blueCmd | maybe it suddenly became mandatory to define TARGET_EXPAND_BUILTIN, but I doubt it | 20:23 |
| stekern | don't think I've seen that | 20:23 |
| stekern | is that when you apply the or1k diff to tip of svn? | 20:23 |
| blueCmd | yes | 20:25 |
| blueCmd | hm, it's still defined in builtins.c just like last version (default_expand_builtin that is) | 20:26 |
| stekern | blueCmd: | 20:33 |
| stekern | https://github.com/openrisc/or1k-gcc/commit/c729a0dbac13ca875637e8852310852b5d66daa9 | 20:33 |
| blueCmd | stekern: cool! thanks | 20:35 |
| blueCmd | stekern: I found that #include "builtins.h" was the last include on most arches | 20:35 |
| blueCmd | suspicious :) | 20:35 |
| stekern | indeed | 20:36 |
| blueCmd | stekern: I think we can remove some of the test overrides btw | 20:36 |
| blueCmd | some seems to be to workaround the alignment that we shouldn't do anymore | 20:36 |
| stekern | yes, probably | 20:37 |
| stekern | I haven't looked through them at all after that change | 20:38 |
| blueCmd | hm | 20:48 |
| blueCmd | gcc crashes when I compile glibc, I wonder if svn is actually a tad bit unstable | 20:49 |
| stekern | cool, or1ksim supports accessing the gpr address space outside of the normal 32 | 20:51 |
| blueCmd | stekern: cool I guess :) | 20:58 |
| stekern | that just means that a kernel built for what I'm currently adding support for in mor1kx will work on old or1ksim | 20:59 |
| blueCmd | ah, that is nice! | 21:00 |
| blueCmd | man, either trunk is really unstable or we will have a fun time merging | 21:13 |
| blueCmd | sure helps if I regenerate configure.. | 22:26 |
| blueCmd | stekern: FYI: | 23:20 |
| blueCmd | https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=cfbc1a6ceba60d30e46ee82af8ea6803fec4a449 | 23:20 |
| blueCmd | https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=3d52a869b2e09d88fc0ebae762d25428d891dd11 | 23: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!