IRC logs for #openrisc Wednesday, 2013-08-21

--- Log opened Wed Aug 21 00:00:21 2013
stekern_franck_: the store buffer is placed between the lsu and the memory02:14
stekernit could be placed *before* the cache too I guess, but I have it running in parallell with the cache since we only have write through caches ritght now02:15
stekernthe one I'm designing will be dumb as a stone (at least in it's first incarnation), writes are filled up in it in-order, any incoming load while the buffer is not empty will stall the pipeline02:17
stekerna more advanced store-buffer would keep track of the contents of the store-buffer and would only stall when an load to something currently in the store-buffer occurs02:18
stekernan even more advanced one would read the value out of the store buffer02:19
stekerna really advanced one would re-order the writes and bundle together several smaller than word writes to the same word into one write (imagine for example copying data into to a char* buffer)02:22
stekernso, the benefits of our dumb as a stone store buffer will be quite limited, but it will have one important case where it will help. The typical C function.02:24
stekernbecause there you very often have: a set of stack writes. actual code (which often at least start with a non-load instruction). a set of stack loads02:25
stekernso you get the stack writes filling up the buffer and having the buffer emptying while running your function02:28
stekernone problem I hadn't considered - to get the pc of an dbus error exception, I need to save that in the store buffer as well...03:32
stekerntintenammae: you mean in newlib/libgloss?05:47
tintenammaestekern: yep05:47
tintenammaenot sure it is supposed to work out of the box or not? thanks for replying :)05:48
stekernnot sure neither, I'd assume it doesn't work and check in the source ;)05:52
tintenammaeI should probably build the toolchain then, rather than using the one in that virtualbox image :|05:56
olofktintenammae: stdin/stdout is connected to your UART, right?05:57
tintenammaestdout is... so I assumed stdin would be05:58
olofkYou could try to send something to the UART and read out the UART rx register manually, with a debugger, or a small C program05:59
tintenammaegood point05:59
olofkJust to rule out any hardware problems06:00
tintenammaeI did just notice there were two extra uarts in board.h I don't remember seeing in quartus. Input works in bootloader.06:00
jeremybennetttintenammae: It is possible that just stdout is supported, if the newlib is based on the simulator newlib.06:01
stekernsimulator newlib?06:01
jeremybennettThe minimal newlib was designed for regression testing the tool chain against Or1ksim, and all it provided was support for stdout using l.nop 306:01
jeremybennettstekern: Should have been more precise - the libgloss BSP to support the Or1ksim simulator06:02
jeremybennettThat is the original newlib implementation.06:02
tintenammaeoh right... also some things might have changed since that virualbox image, right?06:02
jeremybennetttintenammae: Certainly - always a good idea to build from source06:03
tintenammaehehe I'm now checking out that or1k-gcc, takes ages06:04
tintenammae450 MB down...06:04
jeremybennettyup - GCC is big06:04
jeremybennettthird biggest program on any Linux system (after the kernel and Mozilla)06:04
stekernjeremybennett: ah, well, he obviously have stdout connected to the uart and not l.nop 306:05
jeremybennettstekern: Yes - of course. But if it started from the old newlib, the syscalls to support stdin may not be there.06:05
jeremybennettSo you'll just have stdout connected to the UART.06:05
jeremybennettJust a hypothesis of course. From memory I was sure we fixed stdin for real HW.06:06
stekernjuliusb probably knows since he was the one seriously poking at libgloss last06:06
stekernjeremybennett: how about Xorg?06:06
stekernactually, google tells me its not that big.. 500KLOC06:08
jeremybennettstekern: Xorg or GCC?06:08
jeremybennettLOC is a black art anyway. I rely on the figures from David Wheeler's sloccount program.06:09
stekerntrue, especially when they are taken from a random google hit ;)06:09
stekernlibreoffice is probably among the top anyway06:10
stekernagain, random google number: 7MLOC06:11
jeremybennettWikipedia has a bit on the subject
tintenammaeanother question - when connecting debug proxy, it tends to steal or mix up the ttyUSBx. does that happen for everyone?06:12
stekernyes, but when you switch over to openocd you get rid of that problem06:13
jeremybennettAlways used to for me. A nicety of the USB interface on Linux. Never really got to the bottom of it.06:13
tintenammaeok, that openocd seems pretty good then06:14
stekernI guess it's probably something the closed source ftd2xx does06:14
stekernopenocd use libftdi06:15
jeremybennettThe FTDI chip needs two channels - one for USB UART, one for USB JTAG.06:15
jeremybennettIt always seems to get muddled about which one is which. A race somewhere in the setup I guess.06:16
tintenammaeI see06:16
stekernyeah, and then the ttyUSBx would be swapped for ttyUSBy06:16
tintenammaeout of interest do most people use linux or not?06:20
tintenammaeas opposed to newlib06:21
jeremybennetttintenammae: As their development machine or on OpenRISC?06:22
olofkNo idea actually. We mostly hear about the linux stuff, but I guess that most commercial applications use it for bare-metal06:22
tintenammaeI see :P06:23
tintenammaeyeah on openrisc06:23
stekernyeah, but I wonder how many of the baremetal actually "use" newlib06:23
olofkstekern: As opposed to using an RTOS?06:24
stekernyeah, that's what I'm getting at06:24
olofkI think most people use Windows CE06:25
stekernI, for some reason, believe you are not serious ;)06:25
jeremybennettThe TechEdSat system used Linux. I would guess the Samsung set top boxes also do. The NXP/Jennic Zigbee is almost certainly bare metal06:26
olofkstekern: Have you figured out what the Allwinner A31 is running?06:27
stekernolofk: yeah, it's baremetal06:29
tintenammae(building gcc now, wondered what the meaning of --enable-sim --disable-or1ksim was?)06:29
stekernbare-bare, not newlib or modified newlib06:30
stekernsince it has that (nice) exception vector workaround06:30
olofktintenammae: Good question. I'm not sure about most of the configure options. Sounds like stuff that could be mentioned on the wiki as soon as someone writes an explanation06:31
stekern--enable-sim enables the cgen simulator, --disable-or1ksim disables or1ksim06:33
stekernbut that's not gcc that you're building, it's or1k-src06:33
olofkIs the cgen simulator any useful? IIRC it required some peripheral emulators to be useful for running the testsuite06:35
tintenammaeI see. So probably should enable-or1ksim, right? (I am thinking of it while gcc is building slowly :P)06:35
stekernolofk: you can use it to run the testsuite against the or1k-elf toolchain06:36
tintenammaewait another question... I remember reading something in the post about porting newlib about it being different for the sim and for hardware? What's up with that?06:37
olofkDoes that mean that we only need or1ksim as a stand-alone simulator now?06:37
olofktintenammae: The board-specific parts (memory map and UART drivers and stuff) are kept in a separate archive. That part is different between the simulator and hw06:38
stekernI think you need it to run the gdb testsuite (_franck_ help me out here) and you of course need it to run the or1k-linux-* toolchain06:39
olofkstekern: "run" the or1k-linux- toolchain? Do you mean build or test here?06:39
stekernbut you can use a stand-alone or1ksim for the or1k-linux-* toolchains06:39
stekernsorry, run the gcc regression test suite against a simulator06:40
stekernyou can run it against real hardware too06:40
olofkah.. ok. That makes sense.06:40
tintenammaeolofk: thanks, but so long as the gcc command has -mboard=ordb2a, am I right in thinking I shouldn't have to worry about that any more?06:40
stekerntheoretically, with native gcc, we should even be able to run the regression suite *on* the hardware06:41
olofkTo sum it up then, should we use --enable-sim --disable-or1ksim for or1k-src then?06:42
stekernI think so yes, I think knowledge about or1ksim all together in or1k-src was brought in by _franck_, so he would be able to run the gdb tests06:43
stekernbasically, if you're not intending to run any regression tests, you could do --disable-sim as well06:44
tintenammaeok then :P06:47
stekernolofk: (DOTT) I feel you...06:53
olofkI love that about gentoo, that you can just do equery uses <package> to get a quick to-the-point explanation of all config options07:02
_franck_--enable-sim makes gdb to include a simulator (target sim), by default, the simulator used is or1ksim07:05
_franck_if you want the cgen sim, use --disable-or1ksim07:05
_franck_and yes, it is only usefull for regression tests07:06
_franck_olofk: in orpsocv3, is it possible to apply some patch to a core only for some choosen system ?07:08
_franck_let's say I need a patch to make the xxx_core to work on the yyy_board07:08
olofk_franck_: No, I've been thinking about adding that feature, but I wanted to wait to see if it is really needed to have board-specific patches07:17
olofkFor example, I know that the current ethmac is a bit problematic as it only supports MII, but I plan to solve that by adding a separe MII<->RMII and MII<->SMII converters07:18
_franck_this board specific patch feature could be a staging area for patch. This could be usefull when you work localy on a new patch on your own board07:27
_franck_of course you can add this new patch in the core directory07:27
stekernI think you can avoid most of board specific patches by having patches that also add a config parameter to apply the functionality the patch offer07:28
olofk_franck_: orpsocv3 supports multiple cores_root directories that you can set in orpsoc.conf (not sure if that works as intended) or by adding one or more --cores_root= arguments on the command line (quite sure that works). The idea is that if you have cores with the same name in several cores directories, the last one takes precedence (quite sure that doesn't work right now)07:32
olofkVery much like gentoo overlays07:32
olofkBut it's really good to know what features people are looking for, so keep the questions coming07:33
_franck_olofk: the cores will be get from github openrisc now ? If we want to add a core we add it there ?07:33
olofkorpsoc supports downloading stuff from github or opencores svn right now, but it will be easy to add more options. You can also use a core directly on your machine07:34
olofkThe [provider] section in the .core file tells orpsoc if it should get the core from opencores/github, or if it's stored in the same directory as the .core file07:36
_franck_I got this part ;) Let me be more clear07:36
_franck_I have a de1.core, with depend = wb_sdram_crtl07:37
_franck_so there will be a wb_sdram_ctrl.core in $install_patch/cores right ?07:37
stekern...which reminds me, I should put that little beast somewhere seperately07:38
stekern_and_ write some proper testbenches for it07:38
tintenammaewhen building or1k-src with --disable-itcl --disable-tk --disable-tcl, when make calls configure again it fails with "could not find private tcl headers". Any easy way round that?07:38
_franck_stekern: true07:38
olofkYes. The collection of cores on openrisc/orpsoc-cores shouldn't have any dependencies on cores in other collections. Hopefully this will work out fine, but only time will tell :)07:39
stekernas it is now, I've only run the orpsoc tests (and a fair amount of "real world use") against it07:39
olofk_franck_: But if you for some reason would like to keep both wb_sdram_ctrl and de1 in a separate collection, that would work too07:40
olofkBut please don't :)07:40
stekernI wonder if I can pull out the git history from orpsocv2 and apply that to a seperate git repository07:40
stekernmaybe my new friend filter-branch knows how to do that07:40
_franck_olofk: I mean do you fetch this openrisc/orpsoc-cores directory from github or it is included in your orpsocv3 base ?07:42
* _franck_ and olofk have hard time to understand each other ;)07:43
stekerntintenammae: that sounds familiar, but I'm not sure how I solved it, perhaps just installed tcl07:44
olofk_franck_: orpsoc-cores is a separate project now. I might add something to orpsoc to automatically download it, but right now it needs to be downloaded as a separate package07:44
_franck_if there is any modification to wb_arbiter.v, should the patch be applied to orpsoccores/cores/wb_arbiter.v07:45
stekerngit submodule?07:45
olofkMan, this will cause some confusion for those who used orpsocv2 where everything but the kitchen sink is included07:45
olofkI might move wb_bfm and wb_intercon to separate projects at some point. The could be useful in other contexts too, but right now it's too much overhead07:47
_franck_this openrisc/orpsoc-cores confused me07:47
olofkAlso, if you want to package jtag_vpi as a separate project, that would be cool. I stored a local copy to avoid pulling in your whole orpsocv2 fork07:47
olofk_franck_: Are you less confused, or should we continue to try and understand each other :)07:48
_franck_let's wait 2 or 3 more questions to come, I'll tell you later about my confusion degree :)07:48
_franck_if I want to add stekern wb_sdram_ctrl.core should I send it to you ?07:49
olofk_franck_: Yes07:50
stekernolofk: what was the motivation behind breaking out the orpsoc-cores? (I'm not saying it's wrong)07:50
_franck_so this openrisc/orpsoc-cores is useless ?07:50
_franck_you sould move orpsocv3 to github so we can send you patch easily07:51
olofkstekern: I think the collection of cores will be updated much more often than orpsoc itself. It will also allow people to use orpsoc for other non-openrisc related things07:51
olofk_franck_: I am planning to do that now when I have a tagged release07:51
_franck_ok great07:52
stekernI see, so orpsoc is actually not an orpsoc anymore but a build system07:52
_franck_for now, I'll put the wb_sdram_ctrl in my system/de1 directory07:52
olofk_franck_: Do that.07:53
stekern_franck_: why does it matter where the git repo is? In regard to easiness of sending patches?07:53
olofk_franck_: We probably want wb_sdram_ctrl in the official orpsoc-cores, so you could also pull the openrisc/orpsoc-cores tree and give me a pull request when you are happy with the .core file07:55
stekernolofk: orpsoc not being orpsoc is fine I suppose, it'll just cause some initial confusion (as you said) for orpsocv2 users07:55
tintenammaestekern: thanks, already had it installed on gentoo but may need another package07:55
_franck_stekern: well it doesn't07:55
olofkstekern: Yes. I'm confident that this will cause a lot of confusion. Hopefully I will have some time to do a few blog posts and write some documentation07:56
olofktintenammae: Which configure options do you use?07:58
tintenammaeolofk ../configure --target=or1k-elf --prefix=whatever --enable-shared --disable-itcl --disable-tk --disable-tcl --disable-winsup --disable-libgui --disable-rda --disable-sid --disable-sim --disable-or1ksim --enable-gdb --with-sysroot --enable-newlib --enable-libgloss08:02
tintenammaeI just installed tcllib and I already had tcl installed on gentoo before this... I think the part that trips it up is "configuring in build-gnulib08:04
olofkOnly thing I can see is that I use --disable-gdb in mine08:05
tintenammaenot sure what is meant by configure --disable-option-checking?08:05
tintenammaebother now another one... gcc -g -O2 -o spu spu.o / gcc error: spu.o no such file or directory08:10
-!- Netsplit *.net <-> *.split quits: blueCmd08:11
-!- Netsplit over, joins: blueCmd08:12
tintenammaeolofk: thanks for your hint about disable-gdb, I think I have toolchain now08:51
tintenammaeolofk: the tcl one appeared fixed by the --disable-gdb and the spu one something to do with build directory08:51
tintenammaeI wondered if anyone experienced hanging in __uart_getc() and why? Busy waiting for uart data ready without using that function works fine. As does reading from Uart fifo without waiting in __uart_getc()11:17
stekernwhat does it do?11:21
stekernI mean code wise11:22
tintenammaethis is for reading input...11:22
tintenammaewhat it does is a do loop until bit 0 of the uart status register is 1, and then return the value in the uart data register11:23
stekernso isn't that the same as your "busy waiting for uart data"?11:24
tintenammaeI thought it was hence why I was asking...11:24
stekernsounds weird, but I don't think I've ever used it11:27
tintenammaeok, I'll look at it a bit more11:28
_franck_olofk: what about an "orpsoc clean my_system" ?12:25
olofk_franck_: I need to handle that better, but in the meantime you can just do rm -rf build or run "orpsoc sim --force" to clean out before running13:09
olofkSame problem with caches. There are no checks to see if they are outdated13:10
olofkWas that what you meant, or did we misunderstand each other again? :)13:11
_franck_c'etait exactement ce que j'avais compris ! :)13:19
_franck_that is perfectly clear13:19
olofkJust curious, how frustrated did you get before you realized that the code wasn't recompiled? :)13:24
_franck_not that much, that's a classic one13:26
olofkI propose that we officially rename the signal name of the date returned from wishbone slaves. It's a fucking pain to avoid name clashes with data going in the other direction14:17
olofkI've been using sdt (Slave data) internally when I needed to distinguish.14:17
_franck_while I was copying your job (in system/generic) I was wondering what sdt stand for14:30
_franck_is that "intgen" usefull in orpsoc ?14:31
olofk_franck_: I think intgen is used for generating interrupts from software. It seems like a good thing to have.14:33
_franck_ok, I'll remove it :)14:34
olofkNot sure if it's used except for in one testcase in orpsocv214:35
stekernolofk: I agree, but I think 'read' and 'write' would be more appropriate14:50
stekern...and I was confused what date you were speaking about first ;)14:51
olofkstekern: How about keeping write as dat and renaming read to rdt? That could also mean return14:51
stekernand I'm getting more and more convinced that the _o and _i notion is not a great idea14:52
olofkI would also like to rename we to wre, as it fucks up my pretty columns all the time :)14:52
stekernat least in the light of interconnect14:53
olofkYes. And interconnects seem to be 90% of what I'm doing in orpsoc14:53
stekernif you have problem keeping track of your in and outputs in the module, then it's probably on the edge of bloated14:55
olofk...said the guy who smacked on a Avalon interface to mor1kx ;)14:56
stekernah, but I can keep track of'em, don't worry14:57
stekernthe nicest solution to that problem would be if we'd have the top level generated with the bus interface the user wants15:04
olofkI agree. I'm currently writing my first orpsoc code generator to help with the interconnects15:06
olofkI try to avoid generated code as much as possible, but it makes sense in some cases15:07
stekernas long as there's no real logic in it I reckon generated code is fine15:12
olofkYeah, I think that's the key. It can get really messy if you try to autogenerate RTL15:13
stekerni.e. code you wouldn't change by hand anyway15:13
stekernlike the mor1kx top module15:13
olofkYes, that would be really nice to have15:14
ysionneaumaybe you could use migen for that?15:46
ysionneauverilog code generated from python description15:46
stekernysionneau: that thought has certainly crossed my mind15:47
ysionneauit has a library for wishbone interconnect15:47
stekernI got most of the mor1kx-dev-env tests running with the store buffer now19:33
stekernfailing are of course the dbus error ones, since I haven't fixed that19:33
stekernbut it seems it has brought out another bug, something in the register file19:34
stekernwhich of course is "nice", then that get bonus fixed19:36
stekernno, scratch that, I thought it was a normal function call that would be writing r9, but it's a tail call so the value of r9 is loaded from the stack and then a normal jump is performed to the function I was looking at19:40
stekernand that load is not right19:40
olofkJust noticed two weird things about DOTT19:53
olofk1. Why doesn't Ted turn red in the future when Bernard paints him to fool IRS19:53
olofk2. IT'S TWENTY YEARS OLD!19:53
olofk_franck_: Thanks20:30
olofkapplied and pushed20:30
olofkysionneau: migen is your baby too, right?20:31
_franck_there is more like this20:31
stekernolofk: 1. I remember always wondering about that too ;)20:33
olofkJust give me a shout if you find anything that should be applied. I haven't touched the generic system for a while. Most of the work has been on or1200-generic20:33
_franck_olofk: are you sure your wb_data_resize works great ?20:33
_franck_assign wbs_adr_o = wbm_adr_i;20:33
olofk_franck_: whoops20:33
ysionneauolofk: not at all, it's lekernel's baby20:34
ysionneau(S├ębastien Bourdeauducq)20:35
olofkAhh.. I see that the generic system uses wb_utils. That should be replaced with stuff from wb_intercon instead20:35
olofkysionneau: Ah ok. Sorry for the mix up20:36
ysionneauno problem20:36
_franck_olofk: wb_utils and wb_intercon files looks similar20:37
olofk_franck_: wb_intercon is based on the stuff in wb_utils, but it has been improved.20:38
_franck_we still have assign wbs_adr_o = wbm_adr_i there. And I don't think this is correct.20:42
_franck_if you do a byte access at address 1 on a 32bits bus, you'll have 0 on the address and sel will be 0010 on the 8bits side of the bridge you'll have address = 120:42
_franck_*(add a "." after 0010)20:43
olofkI see it now20:47
olofkI'll just add a static 32<->8 conversion. I haven't seen any usecases for converting between other widths20:48
_franck_plus in system/generic, there is a byte wide bus but no wb_data_resize core instanciated20:53
olofkI plan to replace the whole interconnect in system/generic with something that looks more like the interconnect in systems/or1200-generic20:55
olofkMy interconnect generator is almost finished now20:56
_franck_ok I'll wait until then20:56
_franck_I'm sorry I have only criticism agains orpsocv3 :|20:58
olofk_franck_: Criticism is probably what I need most right now to get things done :)21:07
_franck_good night21:19
olofkGood night21:19
olofkThere is support for wishbone over USB in the 3.10 kernels. That's cool.21:22
--- Log closed Thu Aug 22 00:00:22 2013

Generated by 2.15.2 by Marius Gedminas - find it at!