| --- Log opened Mon May 26 00:00:05 2014 | ||
| -!- FreezingAlt is now known as FreezingCold | 02:38 | |
| veprbl | 05:41 | |
|---|---|---|
| stekern | blueCmd: ok, so it "works" in the sense that an executable is produced | 06:07 |
| stekern | ah, righ, that you already said here: https://github.com/bluecmd/or1k-debian/issues/34 | 06:09 |
| _franck__ | stekern: info registers your_register_name/or_group_name | 06:47 |
| _franck__ | "maint print reggroups" if you want to show group names | 06:48 |
| stekern | _franck__: ok, so what's "my_register_name" for epcr? | 07:12 |
| _franck__ | epcr I guess :) | 07:16 |
| stekern | hmm, I think I tried that, but it didn't work | 07:18 |
| _franck__ | http://repo.or.cz/w/openocd.git/blob/HEAD:/src/target/openrisc/or1k.c | 07:18 |
| _franck__ | reg names are here | 07:18 |
| stekern | I don't have access to anything to test on right now, so don't believe anything I say as a fact | 07:19 |
| stekern | ;) | 07:19 |
| stekern | ok, I see that they are in the "system" group | 07:20 |
| stekern | I seemed to only be able to access the once that had NULL | 07:20 |
| stekern | but I probably did something wrong then | 07:20 |
| stekern | hmm, maybe I forgot to try with the 0 appended to epcr | 07:22 |
| _franck__ | you can also access all registers with openocd | 07:23 |
| olofk | General orpsoc-cores system improvement. Implement a bootrom that is preloaded with _franck__'s blinky code | 07:57 |
| olofk | I've done that for my local lx9 microboard | 07:57 |
| olofk | Extra bonus points for reading a pin at boot to decide whether to run the blinky code or load from an onboard Flash | 07:59 |
| _franck__ | a bootrom associated with a assembler source file would be great. Then fusesoc would compile the file and generate the rom content | 08:33 |
| LoneTech | stekern: epcr0 perhaps. the spec indexes them because of the multicontext stuff | 08:33 |
| stekern | yes, that's what I meant with "forgot to append 0 to epcr" | 08:44 |
| stekern | olofk, _franck__: isn't blueCmd working on something like that? | 08:45 |
| _franck__ | stekern: I think so | 08:45 |
| stekern | of course when I have inserted more debug instrumentation for the RCU stalls, they refuse to appear... | 08:47 |
| blueCmd | I am! I have scripts! :) | 09:24 |
| LoneTech | blinky (: | 09:25 |
| blueCmd | which reminds me that I should read up on olofk's RAM/ROM thing | 09:25 |
| _franck__ | blueCmd: is your work already integrated with fusesoc core description file format ? | 09:26 |
| _franck__ | blueCmd: I'm talking about your bootrom work | 09:34 |
| LoneTech | hm. it ought to be possible to merge functionality of fusesoc and migen somewhat | 09:55 |
| LoneTech | something for later. barely started learning about both. | 09:58 |
| blueCmd | _franck__: nah, I don't think it can be | 10:25 |
| blueCmd | _franck__: I want to change it so that cores can generate files, but I haven't gotten around to it | 10:25 |
| blueCmd | so that you have a couple of boot.S for generic stuff as shuffling from EPCS or you can just do your own in the systems/ dir | 10:27 |
| blueCmd | wb_intercon should use that as well - no point in having autogenerated files checked in | 10:27 |
| stekern | I think we should have those checked in, but it should also be possible to generate them when you build | 10:30 |
| stekern | at least as long as wb_intercon is a fast moving target... | 10:31 |
| blueCmd | why? | 10:47 |
| blueCmd | that doesn't make any sense | 10:48 |
| blueCmd | then you hide when you introduce breakage | 10:48 |
| blueCmd | if you change wb_intercon and change the output it should be your resposibility making sure you don't break the other targets | 10:48 |
| blueCmd | (which is why we need CI testing :P) | 10:49 |
| stekern | no, you hide breakage from users | 10:49 |
| blueCmd | until said user wants to re-generate the intercon | 10:49 |
| stekern | the CI tests should of course autogen all the files | 10:49 |
| blueCmd | what would you earn by having the generated files in RCS? | 10:50 |
| stekern | the point I just made, hide breakage from (regular) users | 10:52 |
| LoneTech | autogenerated files can be helpful to get releases started with less dependencies; for instance, not requiring the assembler to build the boot rom while porting to a new board. and such releases belong in revision control as tags or branches. | 10:52 |
| LoneTech | (not necessarily the same repo, though) | 10:53 |
| stekern | yeah, I'm not arguing about the boot rom | 10:53 |
| stekern | eventually, I agree, the wb_intercon generated files should go too | 10:54 |
| LoneTech | the intercon is part of the build system though.. having it prebuilt would risk missing a reason to rebuild it | 10:54 |
| blueCmd | stekern: eventually? | 10:54 |
| stekern | yes, when it's "stable"... | 10:54 |
| blueCmd | LoneTech: +1 | 10:54 |
| stekern | it's even broken as is now | 10:54 |
| blueCmd | stekern: hah, well - that will never be :) | 10:54 |
| blueCmd | changes will always be introduced, no? | 10:55 |
| LoneTech | that's what freezes/releases are for; limiting the set of bugs to fix to reach stable | 10:55 |
| stekern | yes, but not changes like the one with the resize port | 10:55 |
| stekern | and you can change/fix things without breaking "ABI" | 10:57 |
| stekern | I think it's pretty close to that, but my point is just, I think we should hang on to the generated files for just a while longer | 10:58 |
| stekern | (+ we have to fix all the boards that will break with the current wb_intercon_gen) | 10:59 |
| stekern | (+ we have to fix wb_intercon_gen to generate right sized ports for the resizer) | 11:00 |
| stekern | ...then you have 'eventually' (perhaps =P) | 11:01 |
| blueCmd | which is my point :( | 11:05 |
| blueCmd | we shouldn't have pushed a broken wb_intercon_gen (it should have been a branch) | 11:06 |
| stekern | ...and then we would just point people to that branch, and then later explain "no, don't use that anymore" | 11:07 |
| stekern | to be fair though, it's not really broken now | 11:08 |
| stekern | but what's the problem? the big job is to get the infrastructure to auto-generate the files in there, whether they are autogenerated by default or not is just a small detail | 11:10 |
| stekern | we could even do it so, that if the builder finds a wb_intercon.v file in the system dir, it doesn't overwrite it by default | 11:12 |
| stekern | ...or well, if the generate statement is in the core files, it's not even an issue | 11:28 |
| blueCmd | ofc this discussion is moot until we implement the feature, so if the point in time where we autogenerate files is later than when wb_intercon_gen is stable - then everybody will be happy | 12:06 |
| stekern | right ;) | 12:07 |
| blueCmd | so, let's implement it slowly! | 12:07 |
| blueCmd | and procastinate it | 12:07 |
| stekern | turning on icache makes things crash in a lot more spectacular way | 12:08 |
| stekern | ...also, slightly less subtle ways | 12:09 |
| blueCmd | stekern: re | 13:04 |
| blueCmd | (wait, I pressed enter too soon) | 13:04 |
| blueCmd | http://dc387be60423e03e.paste.se/ | 13:05 |
| blueCmd | or1k-linux-gnu-gcc -g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Os -fomit-frame-pointer -D_FORTIFY_SOURCE=2 -fPIE -Wl,-z,relro -Wl,-z,now /srv/build/main.c -pie -o pie-test | 13:05 |
| blueCmd | ./pie-test | 13:05 |
| blueCmd | stekern: execute! | 13:05 |
| stekern | (unstable-or1k)root@wonka:~# gcc -g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Os -fomit-frame-pointer -D_FORTIFY_SOURCE=2 -fPIE -Wl,-z,relro -Wl,-z,now /main.c -pie -o pie-test | 13:12 |
| stekern | /main.c: In function 'main': | 13:12 |
| stekern | /main.c:2:2: warning: incompatible implicit declaration of built-in function 'printf' [enabled by default] | 13:12 |
| stekern | printf("Hello\n"); | 13:12 |
| stekern | ^ | 13:12 |
| stekern | (unstable-or1k)root@wonka:~# ./pie-test | 13:12 |
| stekern | Hello | 13:12 |
| stekern | blueCmd: you can have my working pie if you give me your working atomics ;) | 13:13 |
| _franck__ | (wb_intercon) not tested on hardware but generated files look good: https://github.com/fjullien/orpsoc-cores/commit/b0e64c84add4192aee03c65cb5b77aae3f3999f7 | 13:18 |
| blueCmd | stekern: haha, http://openrisc.debian.net/qemu-or1k-static.atomic | 13:33 |
| blueCmd | stekern: if you could upload that pie somewhere I would be grateful :) | 13:34 |
| blueCmd | stekern: apparently updating qemu to qemu.atomic worked for mafm and the new libc6 | 14:05 |
| stekern | blueCmd: are you insinuating that it might be a pebkac issue? | 14:33 |
| stekern | given that parts of that rootfs have been built by me with voodo and black magic, I'm not going to argue... | 14:34 |
| stekern | _franck_: I think that looks good (haven't tested though), I wonder why the < 32 is needed? | 14:36 |
| stekern | I mean, why can't everything be produced with the < 32 code? | 14:37 |
| _franck__ | I also wonder :) | 14:37 |
| _franck__ | you're right, I just copied what I did some lines after | 14:38 |
| _franck__ | we can remove this test | 14:38 |
| stekern | I think we should try to be compatible with the bus widths > 32 too | 14:39 |
| stekern | but that's of course another issue | 14:39 |
| stekern | ...but just that we shouldn't assume that the "normal" bus width is 32 | 14:40 |
| stekern | blueCmd: chrooting into it with that qemu works | 14:47 |
| stekern | ...and apt-getting libc6 too | 14:48 |
| stekern | I must have screwed something up when I built the qemu-or1k-static here... | 14:49 |
| stekern | blueCmd: pie? https://i.chzbgr.com/maxW500/5045393152/h0E1DA433/ | 14:56 |
| blueCmd | stekern: :( | 15:19 |
| stekern | I still have the issue with or1ksim/real hw though | 15:20 |
| blueCmd | yeah that's weird | 15:21 |
| blueCmd | or rather, it's probably in the 'failed' loop | 15:21 |
| stekern | I tried checking where it "stalls", but I needs some finer tools than just halting the processor and checking where it is | 15:21 |
| stekern | because, the kernel is happily chewing on doing something | 15:21 |
| blueCmd | it might be something like overwriting the registers used to hold parameters inside the loop (i.e. not marking them as early clobber) | 15:22 |
| stekern | I'd like or1ksim to break on U flag | 15:22 |
| stekern | what loop are you speaking about? | 15:22 |
| blueCmd | l.lwa, l.swa, l.bnf 1b | 15:23 |
| stekern | ah | 15:23 |
| blueCmd | I tried to be careful with the modifiers in the insns but maybe I missed something like that | 15:23 |
| blueCmd | it makes sense that it would be something related to that at least | 15:24 |
| blueCmd | but that probably means it's something totally different | 15:24 |
| stekern | yes ;) | 15:24 |
| stekern | I've tracked down my smp crashes to "something screws up r3 now and then" | 15:25 |
| blueCmd | that's easy | 15:25 |
| blueCmd | just move r3 somewhere else! | 15:25 |
| stekern | heh | 15:26 |
| stekern | did you get around to test to boot your rootfs in or1ksim? | 15:28 |
| stekern | hmmm... E: Failed to fetch http://openrisc.debian.net/pool/main/s/systemd/udev_204-8_or1k.deb 404 Not Found | 15:32 |
| stekern | when trying to reinstall udev | 15:32 |
| stekern | nvm... after apt-get update it found it | 15:34 |
| stekern | hmm, doing a new apt-get dist-upgrade after that started to pull in a lot of new systemd stuff | 15:36 |
| stekern | oho, now it breaks in new fascinating ways: http://pastie.org/9219165 | 15:39 |
| stekern | blueCmd: what do you have in your sources.list now? | 16:18 |
| olofk | I see that there's a lot of things to reply to. Excellent :) | 16:27 |
| olofk | LoneTech: I want to be able to use migen to generate parts of the SoC in FuseSoC. I'm also looking to rebuild the old misoc with fuseSoC | 16:28 |
| olofk | And regarding wb_intercon | 16:28 |
| olofk | wb_intercon is very loosely coupled to the build system and that's intentional | 16:29 |
| olofk | And I think it's fine(ish) to let 32 bit data be default, but it needs to be a lot more flexible so we can have wider buses | 16:29 |
| olofk | A complete rewrite is tempting. It's extremely messy code now | 16:30 |
| olofk | But the config format is probably fine as it is | 16:30 |
| olofk | and regarding bootrom generation and stuff. Storing precompiled stuff is fine if it cuts down on the deps. | 16:31 |
| olofk | and extra mega bonus points if someone either: | 16:31 |
| olofk | 1) patches binutils to make the verilog backend for objcopy spit out files with wider data | 16:32 |
| olofk | 2) Comes up with a way to let wb_ram read a byte hex file and still map it efficiently to the FPGA resources | 16:33 |
| blueCmd | stekern: http://941272f59399f4fa.paste.se/ | 16:34 |
| olofk | oh... and onani! Excrements! | 16:34 |
| blueCmd | stekern: word of warning: do not install the coreutils that is in http://openrisc.debian.net/debian, place a hold on the one you already have | 16:34 |
| stekern | ummm... how do I make sure of that... | 16:34 |
| blueCmd | also, binutils should be from http://openrisc.debian.net/pool/main/b/binutils/ to have all TLS patches | 16:35 |
| blueCmd | echo 'binutils hold' | dpkg --set-selections | 16:35 |
| blueCmd | what to do for coreutils is left as an exercise ;) | 16:35 |
| stekern | how do I now that the ones I have now is good? | 16:36 |
| blueCmd | that's harder :P | 16:37 |
| blueCmd | for coreutils it's easy since it's a specific version | 16:37 |
| blueCmd | for binutils the two repositories contain different stuff with the same version | 16:37 |
| blueCmd | dpkg-query -l 'binutils' | 16:38 |
| blueCmd | hi binutils 2.24.51.20140425 or1k GNU assembler, linker and binary utilities | 16:39 |
| blueCmd | hi coreutils 8.21-1 or1k GNU core utilities | 16:39 |
| stekern | ah, well, let's assume the one I have is good | 16:39 |
| stekern | unrelated to this, but I get: libasound2 : Depends: libasound2-data (>= 1.0.27.2-4) but 1.0.27.2-3 is to be installed | 16:40 |
| stekern | ok, I don't have that coreutils | 16:41 |
| stekern | hi coreutils 8.21-1.2 or1k GNU core utilities | 16:41 |
| blueCmd | I get a lot of weird stuff with cp and other utils with that version (error messages that you probably remember that we 'debugged') | 16:49 |
| blueCmd | stekern: are you sure you have the [arch=all] line that I have in your sources.list? | 16:50 |
| stekern | yes, I'm sure I have it in /etc/sources.list ... This is what you get for doing 5 different things at the same time :( | 16:53 |
| blueCmd | /etc/apt/sources.list | 16:57 |
| stekern | I know | 16:57 |
| blueCmd | sorry :( | 16:57 |
| blueCmd | :P | 16:57 |
| stekern | not your fault that I suck at multitasking | 16:58 |
| blueCmd | did you find the issue? | 16:59 |
| stekern | with libasound? yes, that I copied your version into /etc/sources.list instead of /etc/apt/sources.list | 17:03 |
| blueCmd | haha | 17:08 |
| blueCmd | now I see | 17:08 |
| stekern | it still stalls in or1ksim though | 17:23 |
| stekern | I want to see where... | 17:23 |
| stekern | if I'd put a little l.nop 8 in init | 17:26 |
| olofk | Anyone else having trouble with fusesoc? I can't get it to work at all right now | 18:33 |
| olofk | It just prints the help text | 18:33 |
| stekern | I haven't pulled in a while... | 18:33 |
| olofk | Don't! :) | 18:33 |
| olofk | Must have fucked something up with my command line improvements | 18:34 |
| stekern | hmm, I think I just found a bug in mor1kx | 18:34 |
| olofk | hmm, I think I just found a bug in fusesoc | 18:36 |
| stekern | who's next! ;) | 18:37 |
| stekern | unfortunately, this means that my not-so-subtle fails were due to a bug in the cache refill code... so fixing that will not remove the subtle failures :( | 18:38 |
| olofk | False alarm. The FuseSoC bug was a bug that I had introduced locally | 18:51 |
| stekern | a little house bug | 18:52 |
| blueCmd | I feel like coding python today | 19:28 |
| blueCmd | olofk! | 19:28 |
| blueCmd | write as much as you can about how you want the cores to register themselves and that shall be done | 19:29 |
| stekern | blueCmd: it's not much, but it's all I've got: http://git.openrisc.net/cgit.cgi/stefan/linux/commit/?h=smp | 19:39 |
| stekern | to make up for the pie disappointment | 19:39 |
| blueCmd | haha. factories. I'm sorry olofk, but I laugh at code that uses factories in python | 19:40 |
| olofk | blueCmd: What the hell is wrong with my factories? :) | 19:52 |
| olofk | It's one of the very few design patterns that I know of, and I'm damn proud of them! | 19:56 |
| olofk | I even got a few singleton classes :) | 19:56 |
| blueCmd | olofk: because you can just do importlib.import_module(my_nice_string) | 19:56 |
| blueCmd | that's the power of python, and you should use it :) | 19:56 |
| blueCmd | olofk: I'm reworking some things that you might want to pull - I'm going to preview them to you and give you a chance to say yey/nay before I do any huge amout of work with them | 19:57 |
| blueCmd | olofk: if you want to cry a bit, download pep8 and run it on the code ;) | 19:58 |
| stekern | first I crushed olofk's dreams of multiple inheritence and now you take away his factories, take it easy with the poor guy! | 19:59 |
| blueCmd | hah, I don't compromise with code quality :) | 20:03 |
| stekern | to be fair, pep8 complains about silly things in some cases | 20:09 |
| stekern | like the tab here: https://github.com/olofk/fusesoc/blob/master/fusesoc/build/quartus.py#L14 | 20:09 |
| blueCmd | right, it's not perfect - but it's damn better than to not use a linter in a multi-person project | 20:10 |
| stekern | oh, certainly... same goes for checkpatch.pl in the kernel | 20:13 |
| stekern | I wouldn't go as far as calling a coding style checker a 'linter' though ;) | 20:15 |
| blueCmd | hm, no? | 20:16 |
| blueCmd | maybe the one we have at work is a bit more sofisticated, but it's called a linter and does mainly style checking | 20:17 |
| stekern | maybe it's just me that associates the linter word wrongly | 20:18 |
| stekern | I associate it with "static code analyzing to find bugs" | 20:20 |
| blueCmd | olofk: http://aa7f0ededbef1f7b.paste.se/ | 20:21 |
| blueCmd | olofk: then again, if you want to log all functions you can use sys.settrace also | 20:25 |
| blueCmd | or just do 'python -m trace bin/fusesoc' | 20:32 |
| blueCmd | or just do 'python -m trace -t bin/fusesoc' * | 20:33 |
| olofk | blueCmd: I think we should get rid of the function trace stuff. It was done by an old colleague early on. I've been removing bits and pieces of it when I've been updating code | 20:40 |
| blueCmd | Good | 20:42 |
| blueCmd | I'll do a clensing then | 20:43 |
| olofk | But I liked the decorators | 20:43 |
| blueCmd | sure, but if the functionallity isn't needed - let's not add it :) | 20:43 |
| olofk | But maybe we could decorate something else? | 20:43 |
| blueCmd | :D | 20:43 |
| blueCmd | @log | 20:43 |
| blueCmd | stekern | 20:43 |
| blueCmd | look how nice he is now! | 20:43 |
| stekern | who? where? | 20:44 |
| blueCmd | olofk: I only get --help when I run stuff :( | 20:44 |
| blueCmd | stekern: I applied a decorator on you | 20:44 |
| blueCmd | hm | 20:45 |
| stekern | ok, a smile dekorator | 20:45 |
| blueCmd | olofk: false alarm! ;) | 20:45 |
| olofk | blueCmd: I think I was affected by the same bug earlier today. All AttributeErrors are caught in the top-level | 20:47 |
| olofk | I knew it was a bit dirty, but I did it for some reason that I can't remember now | 20:48 |
| blueCmd | olofk: http://d87ad5e75d8f0847.paste.se/ | 20:48 |
| blueCmd | olofk: http://fde99f5601d1bb4e.paste.se/ | 20:49 |
| blueCmd | those are my first two patches I want to merge :) | 20:49 |
| blueCmd | olofk: you have to review faster! it's now 4 commits: https://github.com/bluecmd/fusesoc/commits/master | 21:02 |
| mor1kx | [mor1kx] skristiansson pushed 2 new commits to master: https://github.com/openrisc/mor1kx/compare/e0e2f058e3eb...3dbbd6012024 | 21:03 |
| mor1kx | mor1kx/master bd5d95f Stefan Kristiansson: cfgrs: set Architeture Version Reg to 1.1-rev0 | 21:03 |
| mor1kx | mor1kx/master 3dbbd60 Stefan Kristiansson: cappuccino/fetch: prevent burst signal on regular bus accesses... | 21:03 |
| stekern | I thought for a second that I had found the heisenbug | 21:27 |
| stekern | but it was just one among others... http://git.openrisc.net/cgit.cgi/stefan/linux/commit/?h=smp&id=5c6f2df075b9320628240a8f9f0884a69c7f8eaf | 21:27 |
| olofk | blueCmd: Sorry. Can't merge. I haven't seen your license transfer agreement yet | 21:51 |
| olofk | Ahh.. I see how you did got rid of the factory with importlib | 21:56 |
| olofk | The providerfactory was particularly ugly. I think I did that one first | 21:57 |
| blueCmd | Right | 21:57 |
| blueCmd | I'm doing sections now :) | 21:57 |
| olofk | But I'm not sure why you want to remove the base class? | 21:57 |
| blueCmd | olofk: why do you want it? | 21:57 |
| olofk | Don't you fucking touch my sections submodule :) | 21:57 |
| blueCmd | it's not a submodule anymore ;) | 21:58 |
| olofk | Well, I thought it could do general base classy stuff...like... I don't know | 21:58 |
| olofk | Can't think of anything right now, but I definitely think that the provider classes would want to share some code | 22:01 |
| olofk | Got to sleep now, but I'll probably cherry-pick a few of your patches straight away tomorrow | 22:02 |
| blueCmd | olofk: we can have a talk of why it doesn't matter for python tomorrow - it's a very common mistake to do if one has done a lot of other OOP programing before | 22:03 |
| blueCmd | python is a bit special in that regard | 22:03 |
| blueCmd | olofk: I hope you don't feel stomped upon for me doing this | 22:04 |
| olofk | blueCmd: No worries, I'm eager to learn new stuff. But I might not agree on everything. Convine me tomorrow :) | 22:05 |
| olofk | Convince | 22:05 |
| blueCmd | ofc! | 22:05 |
| olofk | I'm going to make a new project that no one else can commit to, and that will have multiple inheritance and decorators and factories and you can keep your stupid importlib | 22:08 |
| blueCmd | haha | 22:08 |
| blueCmd | olofk: and blackjack and hookers? | 22:09 |
| olofk | :=) | 22:09 |
| blueCmd | olofk: stekern: http://2b22ad86cec9b307.paste.se/ something like that is what I'm thinking | 22:40 |
| blueCmd | I just need to figure out a way of supplying configuration values (which input to use for bootram, what the name of the wb_intercon config file is, and so on) | 22:42 |
| blueCmd | maybe something like: http://0229edd899cce107.paste.se/ | 22:45 |
| blueCmd | https://github.com/bluecmd/fusesoc/commit/0e391de954caefaf68b80046eb5ce30121f57318 | 23:50 |
| blueCmd | RFC | 23:50 |
| blueCmd | good night | 23:50 |
| --- Log closed Tue May 27 00:00:07 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!