| --- Log opened Mon Apr 28 00:00:15 2014 | ||
| --- Day changed Mon Apr 28 2014 | ||
| blueCmd | so. I got my boot rom to work, it loads the u-boot image from flash to RAM and jumps to it. the problem is that there is a hole between the last vector and the code (@0x01fc0000) that objcopy -O binary just skips (and I don't want to store a lot of zeros anyway) | 00:00 |
|---|---|---|
| blueCmd | I'm thinking: 1) move which load address u-boot uses to compensate for that the gap isn't there. ugly. 2) implement some sort of gap-support in the SPI flash->ram code | 00:02 |
| blueCmd | but that's for tomorrow! | 00:02 |
| stekern | blueCmd: ah, right... this should go away: https://github.com/openrisc/orpsoc-cores/blob/master/systems/de0_nano/rtl/verilog/orpsoc_top.v#L591 | 03:31 |
| stekern | since wb_intercon does that by itself | 03:31 |
| stekern | blueCmd: (gap) there shouldn't be any gaps (not that large at least) in the u-boot.bin | 05:26 |
| stekern | u-boot relocates itself to end of ram on boot-up | 05:27 |
| stekern | here, to be more precise: http://git.openrisc.net/cgit.cgi/stefan/u-boot/tree/arch/openrisc/cpu/start.S#n56 | 05:33 |
| olofk_ | blueCmd: I think the reason why you see the big diff when you regenerated wb_intercon is because _franck__ added support for the resize block a while ago. Your previously generated file was probably done before that | 06:17 |
| stekern | it was, the de0_nano port should be patched to use that | 06:18 |
| olofk_ | And wb_intercon_gen should probably be updated to generate correct data widths for the resized components as well :) | 06:19 |
| stekern | yes | 06:20 |
| stekern | it's trivial, we're just lazy ;) | 06:20 |
| stekern | and we want to give blueCmd a chance to get his name in fusesoc as well as in orpsoc-cores *hint* *hint* =) | 06:21 |
| stekern | the atlys issue-report is pretty ironic, the code that fails in newer ISE is from the xilinx whitepaper... | 06:22 |
| olofk_ | So fucking typical | 06:23 |
| olofk_ | They are great at breaking their own stuff | 06:24 |
| stekern | micorsoft really love their 'start-button' (or 'windows' button) | 06:27 |
| stekern | microsoft too | 06:27 |
| stekern | it's completely impossible to use a WP with disfunctional 'hard buttons' | 06:28 |
| stekern | i.e. the back-button and windows button | 06:28 |
| stekern | my phone got a taste of tarmac yesterday and the screen cracked over those button | 06:29 |
| stekern | now I have to power-cycle it to get to the 'home-screen' | 06:29 |
| * stekern is the ontopic master... | 06:30 | |
| stekern | blueCmd: FYI, i tried rebuilding dbus, but it still crashes with an unaligned access in cap_validate_magic | 06:51 |
| olofk_ | stekern: But you can still SSH into your phone, right? | 06:58 |
| olofk_ | Oh... I totally forgot that you don't have a phone with a proper glibc and GNU userland ;) | 06:59 |
| stekern | no, I can only throw it to the ground, that's all it's good for... | 07:02 |
| olofk_ | lol | 07:03 |
| stekern | hmm, I think I've got a got pointer trashing in temacs | 07:28 |
| stekern | pun unintentional | 07:28 |
| stekern | ...nm, I was wrong | 07:31 |
| stekern | instead, the problem is that a call is made to an uninitialized __morecore hook | 07:43 |
| stekern | which is odd, since the emacs code contains this: __ptr_t (*__morecore) PP ((__malloc_ptrdiff_t __size)) = __default_morecore; | 07:57 |
| blueCmd | stekern: right, I rebuilt DBUS a few days ago, so that should be ok | 08:15 |
| blueCmd | but maybe it uses some lib | 08:15 |
| blueCmd | stekern: (uboot) the problem is that the bin-file doesn't contain the gap and the 0x100 code jumps to the specific address 0x01fc0000 (I might have read the code wrong). the data is copied correctly and the cpu gets stuck in 0x700 (invalid instruction), so my thesis seems valid | 08:17 |
| blueCmd | i will look at the code you linked in a bit and compare with what the disass says, need to get my behind to work! | 08:19 |
| stekern | blueCmd: (dbus) yeah, I guess so, will take a closer look later. | 08:45 |
| stekern | (u-boot) but it *shouldn't* contain a gap. | 08:45 |
| stekern | the bin that you load should be: <vectors><text> | 08:45 |
| stekern | then in the reset vector there's code that does: <vectors> gap <text> | 08:46 |
| stekern | all the code in <text> are built to be executed at 0x01fc0000 | 08:47 |
| stekern | but it's not linked in at that address, but right after vectors | 08:47 |
| blueCmd | ah right | 08:51 |
| blueCmd | that makes sense | 08:51 |
| stekern | (because, otherwise you'd have a 32MB .bin) | 08:51 |
| stekern | that's how it initially worked, and that's why I added the relocation code | 08:52 |
| blueCmd | right, good job :) much better, once I can get it to work | 08:53 |
| blueCmd | also, stekern olofk_: sure, please leave the patching of de0 nano to me, I can have it as my pet project | 08:53 |
| stekern | yeah, the illegal insn must come from somewhere else | 08:53 |
| blueCmd | stekern: I'm going to modify the de0 nano project quite heaviliy to add support for my expansion board, would you be sad if I do that? if (stekern.sad) { cp -R de0_nano de0_nano_exp); } | 08:54 |
| stekern | you can of course sanity check it and check that 0x01fc0000 contains the instruction at _start | 08:55 |
| blueCmd | it doesn't | 08:57 |
| stekern | hmm - if (de0_nano_without_exp == BROKEN) stekern.sad = 1; | 08:57 |
| blueCmd | #define BROKEN | 08:57 |
| blueCmd | I mean, what I will do is to potentially remove some controllers that have external pins, move around pins and add new controllers for stuff like network and USB | 08:58 |
| stekern | if you do it so that it's disabled by default, and you turn it on by some config knob, fine | 08:59 |
| stekern | if you can't use the de0_nano without the exp board, not so fine | 08:59 |
| blueCmd | sure, it will be all configruable and agile and .NET and stuff | 08:59 |
| stekern | if you send me an exp board, I'm fine with anything ;) | 08:59 |
| blueCmd | stekern: that's the plan | 09:00 |
| stekern | jk | 09:00 |
| blueCmd | we have one extra board that we plan to fill | 09:00 |
| blueCmd | but I want to make sure it's not all short wires first :P | 09:01 |
| stekern | cool, thanks | 09:01 |
| blueCmd | when I say "we" I mean my super-awesome coworker who reads these IRC logs from time to time | 09:01 |
| stekern | I'll pay for it, of course | 09:01 |
| blueCmd | olofk_: any plan on supporting "configurations" of systems? | 09:01 |
| olofk_ | blueCmd: Yes. A few ideas. Lunch now. Tell you later | 09:02 |
| blueCmd | stekern: oh you will pay alright! *muhahha* | 09:02 |
| stekern | =) | 09:02 |
| blueCmd | olofk_: cool, might be a good idea to get started on that with de0_nano | 09:02 |
| stekern | I bet you'll send me a board and then let me iron out all the bugs for you ;) | 09:02 |
| blueCmd | I'm also thinking of creating a pre-build step or something. There is no reason why we should cary the autogenerated wb_intercon files in the repo | 09:02 |
| blueCmd | we should just generate them on build | 09:03 |
| blueCmd | stekern: <.< | 09:03 |
| blueCmd | I'm so obvious! | 09:03 |
| * stekern nods, configurations and 'generate' support is needed | 09:03 | |
| blueCmd | it will be pretty awesome, because if we add that we can make the bootrom compile the .S file in that step as well | 09:04 |
| blueCmd | spit out an elf for or1ksim, one .lst for inspectin (objdump -d basically) and one .v for the generation | 09:05 |
| blueCmd | inspectin'! hah, awesome typo | 09:05 |
| _franck_web_ | blueCmd: we can already generate wb_intercon files during the build by using some pre_build_script files | 09:09 |
| _franck_web_ | https://github.com/olofk/fusesoc/blob/master/doc/sapi.txt#L58 | 09:10 |
| stekern | yes, but we don't actually do it anywhere, right? | 09:11 |
| _franck_web_ | no we don't but we should | 09:12 |
| _franck_web_ | the problem is to locate the generator (wb_intercon ?). Should we consider it to be in the $PATH | 09:13 |
| _franck_web_ | may be it should be part of the fusesoc installation | 09:14 |
| stekern | we should set some kind of 'envvar' for each core we depend on | 09:15 |
| blueCmd | stekern: do you want barebox? I'm thinking about porting that when I get u-boot running | 09:15 |
| stekern | blueCmd: _franck_web_ has already ported it | 09:15 |
| stekern | it's upstreamed too | 09:15 |
| blueCmd | stekern: ah, hah - nice | 09:15 |
| blueCmd | so why am I using your old PoC? ;) | 09:15 |
| _franck_web_ | :) | 09:16 |
| _franck_web_ | barebox is _the_ bootloader | 09:16 |
| stekern | I don't see the huge added value of barebox tbh... | 09:16 |
| blueCmd | _franck_web_: do you have support for ethoc? | 09:16 |
| _franck_web_ | blueCmd: someone added it, not me | 09:17 |
| blueCmd | cool | 09:17 |
| stekern | I mean, it's of course solid that *we* support it, but in general | 09:17 |
| _franck_web_ | it's using Kconfig so you have this nice make menuconfig and not this crappy config file with all those #defines | 09:18 |
| _franck_web_ | the driver model is like the Linux one | 09:19 |
| stekern | iirc u-boot is moving towards Kconfig too | 09:24 |
| _franck_web_ | that's I read on the mailing list | 09:24 |
| _franck_web_ | *what | 09:24 |
| stekern | but none of those are *huge* added values (IMO) | 09:25 |
| stekern | it's not like it's any hard to port a linux driver to u-boot | 09:26 |
| stekern | I mean, I don't see a reason to switch to barebox if you have a working u-boot on a board | 09:27 |
| stekern | (and the vice-versa) | 09:27 |
| _franck_web_ | no, there is not | 09:27 |
| _franck_web_ | another one: barebox has a good scripting support | 09:28 |
| stekern | is the u-boot scripting support worse? | 09:29 |
| stekern | I haven't really needed to do any scripting | 09:29 |
| stekern | setting up the environment vars has always been enough for my needs | 09:30 |
| _franck_web_ | well, have you seen those 3 lines long command line sometimes ? | 09:33 |
| _franck_web_ | I know it works and it has always been enough for me too | 09:33 |
| stekern | right | 09:36 |
| _franck_web_ | it's easier to read something like this: | 09:36 |
| _franck_web_ | http://git.pengutronix.de/?p=barebox.git;a=blob;f=arch/arm/boards/freescale-mx6-arm2/env/config;h=0ab5bdf0e05b5db38b9e3e321316d68646a236b4;hb=HEAD | 09:36 |
| stekern | http://www.denx.de/wiki/view/DULG/UBootScripts | 09:38 |
| _franck_web_ | you must admit that not straightforward compared to the barebox solution. Plus, barebox has a text editor and you can modify your script directly on your board. | 09:41 |
| _franck_web_ | but I don't try to sell you barebox :) It's free anyway | 09:42 |
| stekern | heh, yeah | 09:42 |
| blueCmd | I'm just one of those "latest version" freaks | 09:45 |
| stekern | how's that related? | 09:45 |
| stekern | afaik, both are actively developed ;) | 09:45 |
| stekern | admittedly, it was a while since I tested if our upstream port is not broken, but I haven't heard any reports lately, so I assume it's not ;) | 09:48 |
| stekern | but, I'm not going to advise you away from barebox. Preferably, use both and test them hard! ;) | 09:55 |
| stekern | besides, barebox has some awesome relocation code as well: http://git.pengutronix.de/?p=barebox.git;a=blob;f=arch/openrisc/cpu/start.S;h=269abc0bffb7cfde1315f6d145d45a2abd80e41b;hb=HEAD#l49 | 09:56 |
| stekern | ;) | 09:56 |
| stekern | translation - if you find some issue with it, the fix should apply to both | 09:57 |
| olofk_ | blueCmd: The grand plan is to let cores register themselves as generators and add some API hooks for that. That way we can keep the FuseSoC code clean. | 09:58 |
| olofk_ | Top-level generation otoh will be a FuseSoC core feature. The idea here is to to that with IP-Xact | 09:58 |
| olofk_ | So every core will have to provide their own IP-XACT description for the interface | 09:59 |
| olofk_ | And things like wb_intercon will generate one on the fly | 09:59 |
| olofk_ | First step is to use another program (like Kactus) to actually connect the cores and generate the top-level RTL | 10:00 |
| olofk_ | configurations will be supported first with a gentoo use-flag-inspired approach | 10:01 |
| olofk_ | That means that you can have conditional dependencies and file inclusions, like depend on ethmac[rgmii], or wb_ram[spartan6] | 10:02 |
| olofk_ | and in your case you could prefix all optional parts with "orpsoc_expandsion_board? (ethmac gpio other_cores)" | 10:05 |
| stekern | olofk_: related question - can you generate .ucf files with the xilinx tcl flow? | 10:06 |
| olofk_ | But another design goal that I have had from the start is that the systems should be lightweight enough so that you can just make a new one instead of putting a lot of conditionals to make it configurable | 10:06 |
| olofk_ | stekern: Hmm... at which stage would you want to do that? | 10:07 |
| stekern | ...or do your ISE backend support several .ucf files to be concatenated? | 10:08 |
| stekern | yes, it does. | 10:08 |
| stekern | because, for the configuration to work, we need to make seperate .ucf files for each "part" | 10:09 |
| stekern | like, a seperate one for ethmac etc | 10:09 |
| stekern | ...and add support for conditionally pull them in | 10:10 |
| stekern | that's what I did with the quartus support in orpsocv2 | 10:10 |
| stekern | but, that hasn't got transferred into fusesoc | 10:11 |
| stekern | for quartus, it's not such a big deal, it'll just slightly complain if it finds some constraints for signals that doesn't exists | 10:12 |
| stekern | ISE isn't as forgiving. | 10:12 |
| olofk_ | Yes, I think concatenation will be easiest for now | 10:12 |
| olofk_ | Might not cover all cases, but we can worry about that later | 10:12 |
| stekern | yup, and that already exists, but the 'conditionally' part is missing | 10:13 |
| olofk_ | And Xilinx is finally leaving their brainded UCF files now with Vivado | 10:13 |
| stekern | but I guess that might be covered in your grand plan | 10:13 |
| olofk_ | It is | 10:13 |
| stekern | ...just making sure | 10:13 |
| olofk_ | Problem is finding time to do it. It will probably take a while to get something working at all | 10:14 |
| olofk_ | Oh well. Parental leave coming up this week :) | 10:14 |
| stekern | right, so we've got two persons working on it then | 10:16 |
| stekern | you and your daughter | 10:16 |
| blueCmd | olofk_: sounds like a cool goal, but also a huge one - what about intermediate goals? | 10:25 |
| blueCmd | like, for now we have top-files, and we have the systems files - surely we can implement the generation part and integrate it with the existing stuff, and implement it in such a way that we can use it both now and later | 10:25 |
| olofk_ | blueCmd: Are you talking specifically about top-level generation now, or about autogenerating stuff in general? | 11:17 |
| blueCmd | olofk_: auto-generating intermediate files such as wb_intercon.v/vh | 11:33 |
| olofk_ | blueCmd: If we can do it with scripts, as _franck_ said, I think that is good enough for now until a proper solution is implemented | 11:38 |
| blueCmd | olofk_: why not implement it proper now? I don't see why this sub-system cannot be implemented now and just be used in the new framework later | 12:15 |
| blueCmd | I'm not a fan of the "waterfall" model where everything needs to be developed at once | 12:15 |
| olofk_ | Sure. We can implement it proper now. I'm just saying that it will probably take some time, so instead of doing some intermediate solution that will be thrown away, we can probably use the script support for now | 12:18 |
| olofk_ | I'm not talking about months here. Just that I don't have much time myself right now | 12:18 |
| blueCmd | I'm saying that I'll implement it | 12:18 |
| blueCmd | and I'd much rather spend time implementing it "for good" than a temporary script-hack that will not be integrated / not work with the final vision of yours | 12:19 |
| stekern | I guess that is "add support for cores to register themselves as generators" | 12:20 |
| stekern | then | 12:20 |
| stekern | that's the small incremental step towards olofk's grand plan IMO | 12:21 |
| olofk_ | Exactly | 12:22 |
| olofk_ | blueCmd: That would be awesome | 12:22 |
| stekern | the API hooks then is just a bikeshedding issue | 12:23 |
| olofk_ | hahaha | 12:23 |
| olofk_ | I was thinking the same thing :) | 12:23 |
| olofk_ | My idea so far is that the core that is a generator (wb_intercon for example) will have a [generator] section that FuseSoC can pick up | 12:24 |
| olofk_ | It should be able to specify which command to run, input files, output files and some parameters | 12:26 |
| olofk_ | And FuseSoC can provide some environment variables to the command that will be executed (like we do for the scripts) | 12:26 |
| olofk_ | The core that will use a generator will also need some tags for that | 12:27 |
| olofk_ | Found an old pastie from October 20 last year when we discussed this the last time http://pastie.org/8416216 | 12:35 |
| olofk_ | This is how I envision the extra sections in the calling core (e.g. de0_nano) | 12:36 |
| olofk_ | Or perhaps [wb_intercon name_of_intercon] if we want to generate several intercons from the same core file | 12:39 |
| stekern | as long as it's indigo | 12:42 |
| stekern | I always wanted an indigo API | 12:42 |
| stekern | bah.. it already exists: http://www.ggasoftware.com/opensource/indigo/api | 12:43 |
| stekern | I guess we'll just have to use that then | 12:44 |
| olofk_ | It's already decided it should be purple. Otherwise it will clash with the Windows CE API hooks | 12:44 |
| LoneTech | I insist it must be octarine | 12:44 |
| olofk_ | The guy in the middle who is trying to teach the old man how to use the tablet looks really frustrated | 12:44 |
| stekern | I think indigo might be compatible with CE: The API allows developers to integrate Indigo into their C/Java/C#/Python projects. | 12:44 |
| stekern | see, C# | 12:44 |
| olofk_ | LoneTech: octarine. I like that :) | 12:45 |
| stekern | yeah, I can make an exception and accept octarine as well | 12:46 |
| olofk_ | stekern: That won't help. FuseSoC will be an activeX extension | 12:46 |
| blueCmd | .386 files | 12:50 |
| blueCmd | autoexec.bat integration | 12:50 |
| blueCmd | HIMEM support | 12:50 |
| blueCmd | olofk_: I'll write a more formal design document and invite people to comment on it | 12:53 |
| olofk_ | blueCmd: Make sure you write it in Microsoft Works so I can read it | 12:54 |
| ysionneau | you forced me to read the whole discussion to understand why you ended up talking about activeX and autoexec.bat :) | 12:55 |
| olofk_ | lol | 12:55 |
| mohessaid | blueCmd: hello | 13:04 |
| mohessaid | are you there | 13:04 |
| LoneTech | odd, things went quiet | 13:13 |
| mohessaid | anyone ever tried to build the openrisc toolchain with glibc and not uclibc or newlib | 13:33 |
| mohessaid | I was trying to follow the steps wrotten by blueCmd but the porcess stacked in glibc | 13:34 |
| olofk_ | mohessaid: I haven't tried glibc unfortunately, but judging from the discussions here lately it should work | 13:46 |
| olofk_ | Can you show us the error message | 13:47 |
| blueCmd | mohessaid: howdy | 13:48 |
| mohessaid | ok | 13:55 |
| mohessaid | ../ports/sysdeps/or1k/nptl/tls.h:47: error: invalid register name for ‘__thread_self’ | 13:57 |
| mohessaid | make[2]: Leaving directory `/home/mohessaid/openrisc/or1k-glibc/csu' | 13:57 |
| mohessaid | make[1]: *** [csu/subdir_lib] Error 2 | 13:57 |
| mohessaid | make[1]: Leaving directory `/home/mohessaid/openrisc/or1k-glibc' | 13:57 |
| mohessaid | make: *** [all] Error 2 | 13:58 |
| mohessaid | this is it | 13:58 |
| mohessaid | the commands used are here: https://github.com/bluecmd/or1k-devel/blob/master/Makefile | 13:59 |
| mohessaid | line 72 | 13:59 |
| blueCmd | mohessaid: which gcc did you use? | 14:01 |
| mohessaid | checking version of gcc... 4.4.7, ok | 14:02 |
| blueCmd | hah, right. no that will not work | 14:05 |
| mohessaid | so, I should use ? | 14:05 |
| blueCmd | pretty sure I told you to use or1k-linux-gnu as compiler | 14:05 |
| mohessaid | ah, but I just build the gcc (stage 1) without headers | 14:05 |
| blueCmd | from where? | 14:06 |
| blueCmd | where did you get the gcc sources? | 14:06 |
| mohessaid | from the ordinary openrisc repository | 14:06 |
| mohessaid | or I should use yours? | 14:07 |
| blueCmd | please provide me a link which one | 14:07 |
| mohessaid | https://github.com/openrisc/or1k-gcc | 14:07 |
| blueCmd | that is a 4.9.0 | 14:08 |
| blueCmd | and the correct one | 14:08 |
| blueCmd | 4.4.7 isn't the correct one, and couldn't be built from that repository you linked above | 14:08 |
| olofk_ | But isn't 4.4.7 the host compiler? | 14:08 |
| olofk_ | Or am I just adding confusion now? :) | 14:09 |
| blueCmd | possibly, but that shouldn't show up in ./configure for glibc if he's cross-compiling | 14:09 |
| mohessaid | 4.4.7 is the build compiler | 14:09 |
| blueCmd | if you do or1k-linux-gnu-gcc -v | 14:09 |
| blueCmd | what does it say? | 14:09 |
| blueCmd | the last line | 14:09 |
| mohessaid | gcc version 4.9.0 20140308 (experimental) (GCC) | 14:10 |
| blueCmd | that's correct. could you give me the full output from configure (and including the full ./configure line) and the make of glibc? | 14:11 |
| mohessaid | ok | 14:11 |
| mohessaid | https://drive.google.com/file/d/0B8oYwofEd1OTMlNNUjZUcmpwME0/edit?usp=sharing | 14:18 |
| mohessaid | https://drive.google.com/file/d/0B8oYwofEd1OTQzdCWjJYOEtRMXM/edit?usp=sharing | 14:18 |
| mohessaid | these are the results from configure then from make | 14:19 |
| blueCmd | mohessaid: I need the ./configure command as well | 14:19 |
| mohessaid | ok | 14:19 |
| blueCmd | checking for gcc... gcc - it seems to be using the wrong gcc | 14:19 |
| mohessaid | yes, I didn't add the directory of or1k-linux-gnu-gcc to the PATH variable | 14:20 |
| mohessaid | this is the ./configure command: | 14:21 |
| mohessaid | ../or1k-glibc/configure --host=or1k-linux-gnu --prefix=/usr --with-headers=/opt/openrisc-devel/or1k-linux-gnu/sys-root/usr/include | 14:21 |
| mohessaid | I started the operation from the begining now, please take a look at this result of configure file from line 9: https://drive.google.com/file/d/0B8oYwofEd1OTTVRMME81ZGtlOEk/edit?usp=sharing | 14:26 |
| jungma | I have a whishbone to TLM2.0 Transactor ready, to use it with a verilated OR ... where should I upload this? | 14:35 |
| mohessaid | blueCmd: before treating glibc I treated these : .binutils-stamp .boot-gcc-stamp .linux-headers-stamp and then glibc | 14:47 |
| mohessaid | and they all works correctly and complete | 14:47 |
| blueCmd | checking for or1k-linux-gnu-gcc... no | 14:57 |
| blueCmd | mohessaid: you have to fix that | 14:57 |
| mohessaid | how, I added or1k-linux-gcc directory to the PATH variable but still the same thing | 14:59 |
| mohessaid | I executed the make and the gcc used in or1k-linux-gnu-gcc but the result of configure is a no for this gcc I think there is a porblem in the configuration script? I will tell you about the result of make when it finish | 15:02 |
| blueCmd | have you looked in config.log / configure to see how it tests it if you're really sure that it's in the path? | 15:03 |
| blueCmd | mohessaid: make is not going to work | 15:03 |
| blueCmd | it's going to compile to your host system, not to or1k | 15:03 |
| blueCmd | so it's a waste of time to even try | 15:03 |
| mohessaid | but it is using the or1k-linux-gnu-gcc now and not the system gcc | 15:04 |
| mohessaid | here is the config.log: https://drive.google.com/file/d/0B8oYwofEd1OTR3NWR0k3VEw3Z2s/edit?usp=sharing | 15:08 |
| blueCmd | mohessaid: sure the last one was the real one then? | 15:09 |
| blueCmd | the last googled document you sent that is | 15:09 |
| mohessaid | yes, of course | 15:09 |
| mohessaid | the configure result or conf.log | 15:10 |
| blueCmd | no, it cant be the same | 15:10 |
| blueCmd | the config.log says: | 15:10 |
| blueCmd | 33 configure:2420: checking for or1k-linux-gnu-gcc | 15:10 |
| blueCmd | 32 configure:2436: found /opt/openrisc-devel/bin/or1k-linux-gnu-gcc | 15:11 |
| blueCmd | 31 configure:2447: result: or1k-linux-gnu-gcc | 15:11 |
| blueCmd | but https://docs.google.com/a/google.com/file/d/0B8oYwofEd1OTTVRMME81ZGtlOEk/edit says 'no' | 15:11 |
| blueCmd | your config.log seems fine however, so whatever /configure run that was associated with should be fine | 15:11 |
| mohessaid | yes the configure results shared are both without the direcotry included in the PATH varibale | 15:12 |
| mohessaid | but the conf.log is the result with PATH variable | 15:12 |
| blueCmd | *sigh* | 15:12 |
| blueCmd | ok | 15:12 |
| blueCmd | so why did you say 'yes, of course'? | 15:12 |
| blueCmd | oh well | 15:13 |
| mohessaid | I asked after the yes whether you want the result or the conf.log :) | 15:13 |
| blueCmd | ah I see | 15:13 |
| blueCmd | stupid interleaved text | 15:14 |
| blueCmd | oh well, hopefully that will work just fine then | 15:14 |
| mohessaid | yep, success, thank you for all | 15:31 |
| mohessaid | blueCmd: thank you so much | 15:32 |
| blueCmd | mohessaid: anytime | 15:52 |
| blueCmd | stekern: so my wannabuild picked up a new source for binutils, and guess what? it built binutils for or1k without any intervention from me! | 19:56 |
| blueCmd | granted, it will contain a bugged TLS (the one I fixed) but yes - it's cool | 19:56 |
| stekern | nice! | 20:01 |
| stekern | this emacs bug isn't as nice, it needs a lot of intervention =( | 20:02 |
| stekern | this should be a minimal test case of the code that fails: http://pastie.org/9120789 | 20:04 |
| stekern | with the only problem that the minimal test case doesn't fail... | 20:05 |
| blueCmd | haha | 20:30 |
| stekern | do you know how the versioning info works? | 20:35 |
| stekern | in temacs, the symbol looks like this: http://pastie.org/9120895 | 20:36 |
| stekern | well, it looks like that in my small testcase too, it was just hidden by the fact that __bss_start overlapped with it | 20:50 |
| stekern | I think I'll sleep on it... | 20:51 |
| blueCmd | stekern: I dont recall how versioning works, sorry | 21:15 |
| blueCmd | I know I read up on it when porting glibc but I forgot | 21:15 |
| blueCmd | stekern: I'm going to push https://github.com/bluecmd/or1k-src/commit/22d737c0aefd21941009d8b280b038f8ed613627 to upstream if it looks alright in your eyes | 22:22 |
| blueCmd | I think it's been used for enough for enough time now to say that it seems to be working and not break more stuff | 22:23 |
| blueCmd | stekern: http://42d7e14523efe2b9.paste.se/ that's what I'm going to push | 22:37 |
| juliusb | wallento: wow, amazing post today | 23:31 |
| juliusb | I really want to try that out :) | 23:31 |
| juliusb | and stekern, top job on the atomic stuff | 23:31 |
| juliusb | seems well thought out | 23:31 |
| juliusb | ... and we're upstream in binutils | 23:34 |
| juliusb | you all deserve a beer | 23:35 |
| juliusb | when's that happening? excuse given to significant others for a catch up and a beer aka ORCONF2014? | 23:36 |
| --- Log closed Tue Apr 29 00:00:06 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!