IRC logs for #openrisc Monday, 2014-04-28

--- Log opened Mon Apr 28 00:00:15 2014
--- Day changed Mon Apr 28 2014
blueCmdso. 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
blueCmdI'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 code00:02
blueCmdbut that's for tomorrow!00:02
stekernblueCmd: ah, right... this should go away:
stekernsince wb_intercon does that by itself03:31
stekernblueCmd: (gap) there shouldn't be any gaps (not that large at least) in the u-boot.bin05:26
stekernu-boot relocates itself to end of ram on boot-up05:27
stekernhere, to be more precise:
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 that06:17
stekernit was, the de0_nano port should be patched to use that06:18
olofk_And wb_intercon_gen should probably be updated to generate correct data widths for the resized components as well :)06:19
stekernit's trivial, we're just lazy ;)06:20
stekernand we want to give blueCmd a chance to get his name in fusesoc as well as in orpsoc-cores *hint* *hint* =)06:21
stekernthe atlys issue-report is pretty ironic, the code that fails in newer ISE is from the xilinx whitepaper...06:22
olofk_So fucking typical06:23
olofk_They are great at breaking their own stuff06:24
stekernmicorsoft really love their 'start-button' (or 'windows' button)06:27
stekernmicrosoft too06:27
stekernit's completely impossible to use a WP with disfunctional 'hard buttons'06:28
stekerni.e. the back-button and windows button06:28
stekernmy phone got a taste of tarmac yesterday and the screen cracked over those button06:29
stekernnow I have to power-cycle it to get to the 'home-screen'06:29
* stekern is the ontopic master...06:30
stekernblueCmd: FYI, i tried rebuilding dbus, but it still crashes with an unaligned access in cap_validate_magic06: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
stekernno, I can only throw it to the ground, that's all it's good for...07:02
stekernhmm, I think I've got a got pointer trashing in temacs07:28
stekernpun unintentional07:28
stekern...nm, I was wrong07:31
stekerninstead, the problem is that a call is made to an uninitialized __morecore hook07:43
stekernwhich is odd, since the emacs code contains this: __ptr_t (*__morecore) PP ((__malloc_ptrdiff_t __size)) = __default_morecore;07:57
blueCmdstekern: right, I rebuilt DBUS a few days ago, so that should be ok08:15
blueCmdbut maybe it uses some lib08:15
blueCmdstekern: (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 valid08:17
blueCmdi 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
stekernblueCmd: (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
stekernthe bin that you load should be: <vectors><text>08:45
stekernthen in the reset vector there's code that does: <vectors> gap <text>08:46
stekernall the code in <text> are built to be executed at 0x01fc000008:47
stekernbut it's not linked in at that address, but right after vectors08:47
blueCmdah right08:51
blueCmdthat makes sense08:51
stekern(because, otherwise you'd have a 32MB .bin)08:51
stekernthat's how it initially worked, and that's why I added the relocation code08:52
blueCmdright, good job :) much better, once I can get it to work08:53
blueCmdalso, stekern olofk_: sure, please leave the patching of de0 nano to me, I can have it as my pet project08:53
stekernyeah, the illegal insn must come from somewhere else08:53
blueCmdstekern: 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
stekernyou can of course sanity check it and check that 0x01fc0000 contains the instruction at _start08:55
blueCmdit doesn't08:57
stekernhmm - if (de0_nano_without_exp == BROKEN) stekern.sad = 1;08:57
blueCmd#define BROKEN08:57
blueCmdI 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 USB08:58
stekernif you do it so that it's disabled by default, and you turn it on by some config knob, fine08:59
stekernif you can't use the de0_nano without the exp board, not so fine08:59
blueCmdsure, it will be all configruable and agile and .NET and stuff08:59
stekernif you send me an exp board, I'm fine with anything ;)08:59
blueCmdstekern: that's the plan09:00
blueCmdwe have one extra board that we plan to fill09:00
blueCmdbut I want to make sure it's not all short wires first :P09:01
stekerncool, thanks09:01
blueCmdwhen I say "we" I mean my super-awesome coworker who reads these IRC logs from time to time09:01
stekernI'll pay for it, of course09:01
blueCmdolofk_: any plan on supporting "configurations" of systems?09:01
olofk_blueCmd: Yes. A few ideas. Lunch now. Tell you later09:02
blueCmdstekern: oh you will pay alright! *muhahha*09:02
blueCmdolofk_: cool, might be a good idea to get started on that with de0_nano09:02
stekernI bet you'll send me a board and then let me iron out all the bugs for you ;)09:02
blueCmdI'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 repo09:02
blueCmdwe should just generate them on build09:03
blueCmdstekern: <.<09:03
blueCmdI'm so obvious!09:03
* stekern nods, configurations and 'generate' support is needed09:03
blueCmdit will be pretty awesome, because if we add that we can make the bootrom compile the .S file in that step as well09:04
blueCmdspit out an elf for or1ksim, one .lst for inspectin (objdump -d basically) and one .v for the generation09:05
blueCmdinspectin'! hah, awesome typo09:05
_franck_web_blueCmd: we can already generate wb_intercon files during the build by using some pre_build_script files09:09
stekernyes, but we don't actually do it anywhere, right?09:11
_franck_web_no we don't but we should09:12
_franck_web_the problem is to locate the generator (wb_intercon ?). Should we consider it to be in the $PATH09:13
_franck_web_may be it should be part of the fusesoc installation09:14
stekernwe should set some kind of 'envvar' for each core we depend on09:15
blueCmdstekern: do you want barebox? I'm thinking about porting that when I get u-boot running09:15
stekernblueCmd: _franck_web_ has already ported it09:15
stekernit's upstreamed too09:15
blueCmdstekern: ah, hah - nice09:15
blueCmdso why am I using your old PoC? ;)09:15
_franck_web_barebox is _the_ bootloader09:16
stekernI 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 me09:17
stekernI mean, it's of course solid that *we* support it, but in general09:17
_franck_web_it's using Kconfig so you have this nice make menuconfig and not this crappy config file with all those #defines09:18
_franck_web_the driver model is like the Linux one09:19
stekerniirc u-boot is moving towards Kconfig too09:24
_franck_web_that's I read on the mailing list09:24
stekernbut none of those are *huge* added values (IMO)09:25
stekernit's not like it's any hard to port a linux driver to u-boot09:26
stekernI mean, I don't see a reason to switch to barebox if you have a working u-boot on a board09:27
stekern(and the vice-versa)09:27
_franck_web_no, there is not09:27
_franck_web_another one: barebox has a good scripting support09:28
stekernis the u-boot scripting support worse?09:29
stekernI haven't really needed to do any scripting09:29
stekernsetting up the environment vars has always been enough for my needs09: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 too09:33
_franck_web_it's easier to read something like this:09:36
_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 anyway09:42
stekernheh, yeah09:42
blueCmdI'm just one of those "latest version" freaks09:45
stekernhow's that related?09:45
stekernafaik, both are actively developed ;)09:45
stekernadmittedly, 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
stekernbut, I'm not going to advise you away from barebox. Preferably, use both and test them hard! ;)09:55
stekernbesides, barebox has some awesome relocation code as well:;a=blob;f=arch/openrisc/cpu/start.S;h=269abc0bffb7cfde1315f6d145d45a2abd80e41b;hb=HEAD#l4909:56
stekerntranslation - if you find some issue with it, the fix should apply to both09: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-Xact09:58
olofk_So every core will have to provide their own IP-XACT description for the interface09:59
olofk_And things like wb_intercon will generate one on the fly09:59
olofk_First step is to use another program (like Kactus) to actually connect the cores and generate the top-level RTL10:00
olofk_configurations will be supported first with a gentoo use-flag-inspired approach10: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
stekernolofk_: 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 configurable10: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
stekernyes, it does.10:08
stekernbecause, for the configuration to work, we need to make seperate .ucf files for each "part"10:09
stekernlike, a seperate one for ethmac etc10:09
stekern...and add support for conditionally pull them in10:10
stekernthat's what I did with the quartus support in orpsocv210:10
stekernbut, that hasn't got transferred into fusesoc10:11
stekernfor quartus, it's not such a big deal, it'll just slightly complain if it finds some constraints for signals that doesn't exists10:12
stekernISE isn't as forgiving.10:12
olofk_Yes, I think concatenation will be easiest for now10:12
olofk_Might not cover all cases, but we can worry about that later10:12
stekernyup, and that already exists, but the 'conditionally' part is missing10:13
olofk_And Xilinx is finally leaving their brainded UCF files now with Vivado10:13
stekernbut I guess that might be covered in your grand plan10:13
olofk_It is10:13
stekern...just making sure10:13
olofk_Problem is finding time to do it. It will probably take a while to get something working at all10:14
olofk_Oh well. Parental leave coming up this week :)10:14
stekernright, so we've got two persons working on it then10:16
stekernyou and your daughter10:16
blueCmdolofk_: sounds like a cool goal, but also a huge one - what about intermediate goals?10:25
blueCmdlike, 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 later10:25
olofk_blueCmd: Are you talking specifically about top-level generation now, or about autogenerating stuff in general?11:17
blueCmdolofk_: auto-generating intermediate files such as wb_intercon.v/vh11: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 implemented11:38
blueCmdolofk_: 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 later12:15
blueCmdI'm not a fan of the "waterfall" model where everything needs to be developed at once12: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 now12:18
olofk_I'm not talking about months here. Just that I don't have much time myself right now12:18
blueCmdI'm saying that I'll implement it12:18
blueCmdand 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 yours12:19
stekernI guess that is "add support for cores to register themselves as generators"12:20
stekernthat's the small incremental step towards olofk's grand plan IMO12:21
olofk_blueCmd: That would be awesome12:22
stekernthe API hooks then is just a bikeshedding issue12: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 up12:24
olofk_It should be able to specify which command to run, input files, output files and some parameters12: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 that12:27
olofk_Found an old pastie from October 20 last year when we discussed this the last time
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 file12:39
stekernas long as it's indigo12:42
stekernI always wanted an indigo API12:42
stekernbah.. it already exists:
stekernI guess we'll just have to use that then12:44
olofk_It's already decided it should be purple. Otherwise it will clash with the Windows CE API hooks12:44
LoneTechI insist it must be octarine12:44
olofk_The guy in the middle who is trying to teach the old man how to use the tablet looks really frustrated12:44
stekernI think indigo might be compatible with CE: The API allows developers to integrate Indigo into their C/Java/C#/Python projects.12:44
stekernsee, C#12:44
olofk_LoneTech: octarine. I like that :)12:45
stekernyeah, I can make an exception and accept octarine as well12:46
olofk_stekern: That won't help. FuseSoC will be an activeX extension12:46
blueCmd.386 files12:50
blueCmdautoexec.bat integration12:50
blueCmdHIMEM support12:50
blueCmdolofk_: I'll write a more formal design document and invite people to comment on it12:53
olofk_blueCmd: Make sure you write it in Microsoft Works so I can read it12:54
ysionneauyou forced me to read the whole discussion to understand why you ended up talking about activeX and autoexec.bat :)12:55
mohessaidblueCmd: hello13:04
mohessaidare you there13:04
LoneTechodd, things went quiet13:13
mohessaidanyone ever tried to build the openrisc toolchain with glibc and not uclibc or newlib13:33
mohessaidI was trying to follow the steps wrotten by blueCmd but the porcess stacked in glibc13:34
olofk_mohessaid: I haven't tried glibc unfortunately, but judging from the discussions here lately it should work13:46
olofk_Can you show us the error message13:47
blueCmdmohessaid: howdy13:48
mohessaid../ports/sysdeps/or1k/nptl/tls.h:47: error: invalid register name for ‘__thread_self’13:57
mohessaidmake[2]: Leaving directory `/home/mohessaid/openrisc/or1k-glibc/csu'13:57
mohessaidmake[1]: *** [csu/subdir_lib] Error 213:57
mohessaidmake[1]: Leaving directory `/home/mohessaid/openrisc/or1k-glibc'13:57
mohessaidmake: *** [all] Error 213:58
mohessaidthis is it13:58
mohessaidthe commands used are here:
mohessaidline 7213:59
blueCmdmohessaid: which gcc did you use?14:01
mohessaidchecking version of gcc... 4.4.7, ok14:02
blueCmdhah, right. no that will not work14:05
mohessaidso, I should use ?14:05
blueCmdpretty sure I told you to use or1k-linux-gnu as compiler14:05
mohessaidah, but I just build the gcc (stage 1) without headers14:05
blueCmdfrom where?14:06
blueCmdwhere did you get the gcc sources?14:06
mohessaidfrom the ordinary openrisc repository14:06
mohessaidor I should use yours?14:07
blueCmdplease provide me a link which one14:07
blueCmdthat is a 4.9.014:08
blueCmdand the correct one14:08
blueCmd4.4.7 isn't the correct one, and couldn't be built from that repository you linked above14:08
olofk_But isn't 4.4.7 the host compiler?14:08
olofk_Or am I just adding confusion now? :)14:09
blueCmdpossibly, but that shouldn't show up in ./configure for glibc if he's cross-compiling14:09
mohessaid4.4.7 is the build compiler14:09
blueCmdif you do or1k-linux-gnu-gcc -v14:09
blueCmdwhat does it say?14:09
blueCmdthe last line14:09
mohessaidgcc version 4.9.0 20140308 (experimental) (GCC)14:10
blueCmdthat's correct. could you give me the full output from configure (and including the full ./configure line) and the make of glibc?14:11
mohessaidthese are the results from configure then from make14:19
blueCmdmohessaid: I need the ./configure command as well14:19
blueCmdchecking for gcc... gcc - it seems to be using the wrong gcc14:19
mohessaidyes, I didn't add the directory of or1k-linux-gnu-gcc to the PATH variable14:20
mohessaidthis 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/include14:21
mohessaidI started the operation from the begining now, please take a look at this result of configure file from line 9:
jungmaI have a whishbone to TLM2.0 Transactor ready, to use it with a verilated OR ...  where should I upload this?14:35
mohessaidblueCmd: before treating glibc I treated these : .binutils-stamp  .boot-gcc-stamp  .linux-headers-stamp and then glibc14:47
mohessaidand they all works correctly and complete14:47
blueCmdchecking for or1k-linux-gnu-gcc... no14:57
blueCmdmohessaid: you have to fix that14:57
mohessaidhow, I added or1k-linux-gcc directory to the PATH variable but still the same thing14:59
mohessaidI 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 finish15:02
blueCmdhave 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
blueCmdmohessaid: make is not going to work15:03
blueCmdit's going to compile to your host system, not to or1k15:03
blueCmdso it's a waste of time to even try15:03
mohessaidbut it is using the or1k-linux-gnu-gcc now and not the system gcc15:04
mohessaidhere is the config.log:
blueCmdmohessaid: sure the last one was the real one then?15:09
blueCmdthe last googled document you sent that is15:09
mohessaidyes, of course15:09
mohessaidthe configure result or conf.log15:10
blueCmdno, it cant be the same15:10
blueCmdthe config.log says:15:10
blueCmd 33 configure:2420: checking for or1k-linux-gnu-gcc15:10
blueCmd 32 configure:2436: found /opt/openrisc-devel/bin/or1k-linux-gnu-gcc15:11
blueCmd 31 configure:2447: result: or1k-linux-gnu-gcc15:11
blueCmdbut says 'no'15:11
blueCmdyour config.log seems fine however, so whatever /configure run that was associated with should be fine15:11
mohessaidyes the configure results shared are both without the direcotry included in the PATH varibale15:12
mohessaidbut the conf.log is the result with PATH variable15:12
blueCmdso why did you say 'yes, of course'?15:12
blueCmdoh well15:13
mohessaidI asked after the yes whether you want the result or the conf.log :)15:13
blueCmdah I see15:13
blueCmdstupid interleaved text15:14
blueCmdoh well, hopefully that will work just fine then15:14
mohessaidyep, success, thank you for all15:31
mohessaidblueCmd: thank you so much15:32
blueCmdmohessaid: anytime15:52
blueCmdstekern: 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
blueCmdgranted, it will contain a bugged TLS (the one I fixed) but yes - it's cool19:56
stekernthis emacs bug isn't as nice, it needs a lot of intervention =(20:02
stekernthis should be a minimal test case of the code that fails:
stekernwith the only problem that the minimal test case doesn't fail...20:05
stekerndo you know how the versioning info works?20:35
stekernin temacs, the symbol looks like this:
stekernwell, it looks like that in my small testcase too, it was just hidden by the fact that __bss_start overlapped with it20:50
stekernI think I'll sleep on it...20:51
blueCmdstekern: I dont recall how versioning works, sorry21:15
blueCmdI know I read up on it when porting glibc but I forgot21:15
blueCmdstekern: I'm going to push to upstream if it looks alright in your eyes22:22
blueCmdI think it's been used for enough for enough time now to say that it seems to be working and not break more stuff22:23
blueCmdstekern: that's what I'm going to push22:37
juliusbwallento: wow, amazing post today23:31
juliusbI really want to try that out :)23:31
juliusband stekern, top job on the atomic stuff23:31
juliusbseems well thought out23:31
juliusb... and we're upstream in binutils23:34
juliusbyou all deserve a beer23:35
juliusbwhen'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 2.15.2 by Marius Gedminas - find it at!