IRC logs for #openrisc Thursday, 2014-07-03

--- Log opened Thu Jul 03 00:00:01 2014
daliasstekern, hey01:56
daliasstekern, ah you left. n/m, catch you later then01:56
stekerndalias: what's up?04:49
daliasoh, just figured i'd check in on musl port04:55
stekernah, it's good you're keeping an eye on me so I don't slack off ;)04:55
stekernI've been busy with other stuff lately, but I'll get around to give it some love soon again04:57
stekernbasically, I'm still missing pieces in src/ldso and src/thread05:01
stekernI'll need to setup a system that actually use that stuff too, so I can test if what I do actually work05:02
stekerniirc, you hinted about some libc testsuite that I could use too05:03
stekernI'll dig the backlogs for it ;)05:03
stekernwb wallento, feeling better?06:48
daliasstekern, test suite is here: nsz.repo.hu/git/?p=libc-test07:59
daliasstekern, ldso should be easy now -- you just have to map the or1k relocations to a generic type of relocation08:00
stekerndalias: yeah, I saw that. I just have to figure out what I need to do in dlsym.s.08:05
stekernand in _dlstart08:11
blueCmdspi expanders - good/bad? I only have 8 GPIO pins and I want to add Ethernet, SDCard and RTC11:54
LoneTechdepends. if you're using it to mux a select line and connect the spi to all of those, it's okay11:57
-!- knz_ is now known as knz11:57
LoneTechbut you certainly won't want to talk through a gpio expander to any of them except possibly the rtc11:57
blueCmdLoneTech: yes, I want a chip that I can tell 'send device X data Y'11:59
LoneTechhttp://electronicdesign.com/displays/serial-control-multiplexer-expands-spi-chip-selects for instance11:59
blueCmdoh right, SPI has slave select - that makes it much simpler12:00
blueCmdI was thinking of I2C12:00
blueCmdbut SPI is what I want12:00
LoneTechjust double check that all devices put MISO (DO for them) in high impedance when not selected12:00
LoneTechor use a mux for that too12:01
LoneTechon i2c everything is slow (probably too slow for pratical use of ethernet or sd card) but chips have addresses12:05
blueCmdI'm thinking that I can have an SPI Mux to control the SS pins and share SCLK/MOSI/MISO and let the mux's SS gate the other SS pins12:07
blueCmdso for ethernet to be activated SS to the Mux needs to be 0, and the mux must be set to output SS 1 for the Ethernet module12:08
blueCmdto change which device is activated I would set SS to the Mux to 1, which would deactivate the bus to every other device, and then write the new value12:08
LoneTechcould be done, assuming you need no data back from the mux. pay attention to the select levels.12:08
LoneTechalso clock polarity; easiest if they all operate in the same spi mode12:09
blueCmdwhy would data back from the mux be a problem?12:09
LoneTechbecause it starts driving immediately as you released select from others. it'd be short, but may involve it fighting with another device12:09
LoneTechhowever, for this use you likely don't need any data back; you just send which bus to use between each select12:10
LoneTechalso don't forget to make the idle state on every select line deselected12:11
LoneTechit's possible a counter or shift register could do better than a mux for the select job12:13
blueCmdI wonder if the linux driver (oc-tiny) can handle muxed GPIOs (or multi-slave buses in general)12:34
blueCmdhttp://comments.gmane.org/gmane.linux.kernel.spi.devel/12868 seems to have implemented what I want, but doesn't seem to be merged12:35
LoneTechthe last one I looked at used linux' gpio layer to handle selects, but that may be simple, not tiny12:36
LoneTechoh, the other way around. the tiny driver uses gpio, which should allow use of extenders12:37
LoneTechyet it was the simple one I patched. oh well, still confused12:39
blueCmdI guess spi-simple is better from a performance POW though12:39
LoneTechperhaps marginally; as I recall it was still 8-bit with no dma, but had a small queue. but that's what I patched; the driver was checking commands sent not results received, and the register interface didn't report command in progress as either12:40
stekernLoneTech: I gave the spi-simple a large overhaul after your patches too12:52
stekernthe 'vanilla' simple core only have slave select via gpio too12:56
stekernthe builtin ss was a orpsocv2 extension12:57
stekerncan't remember if the linux driver have support for that extension neither12:57
blueCmd#define OCSPI_NUM_CHIPSELECTS 813:28
blueCmdI'm trying to figure out if I can have multiple devices on simple-spi13:28
blueCmdI don't see any examples of it, but somethings hint towards it13:28
blueCmdOne comment in a DTS file is '/* Example SD card slot at chipselect 0 */'13:28
stekernyes you can13:29
blueCmdstekern: do you know how that works? like this? http://bc91ceca48efb8fd.paste.se/13:33
stekernI have done it, but can't remembrr from the top of my head, I can check when I get home if you haven't solved it by then13:34
blueCmdcool13:35
blueCmdright, so this patch adds SS to simple_spi on the HDL side: https://github.com/openrisc/orpsoc-cores/blob/master/cores/simple_spi/patches/0005-add-slave-select-logic.patch13:36
blueCmdright, I think I know how it works now, but I still need to figure out the dts syntax13:39
daliasstekern, dlsym.s just needs to pass the return address as an extra argument to __dlsym, so that the latter can support RTLD_NEXT14:14
daliasstekern, _dlstart is a bit more work. for archs where a GOT is required even for accessing local data, you need something like the __reloc_self used on microblaze which gets called early, and it needs to be written so as not to make any function calls or use any global data/consts14:16
daliasstekern, and _dlstart needs to be able to call it without the help of a GOT :)14:17
daliasstekern, otherwise the essential work of _dlstart is simply calling __dynlink with the args and then jumping to the address in the return value14:17
daliasstekern, the intermediate work is skipping all arg slots that were filled with -1's, which is the way __dynlink removes unwanted argv entries when ld-musl.so is invoked as a command to run a program. in that case it has to advance past them and write an updated argc14:19
blueCmdthe size for wb_interconnect - is that byte size of word size?15:19
stekerndalias: ok, thanks for the explanation. I'll take a look at _dlstart in the evening.15:21
stekernblueCmd: byte size15:21
sb0stekern, good job on the mor1kx diet. now it also meets timing at 80MHz on the lx9...16:59
* blueCmd is about to compile his first or1k toolchain for newlib16:59
stekernsb0: ah, good news!17:06
stekernolofk: you will not believe this...17:07
stekernI found another software bug!17:07
stekern...I had forgot to add the l.swa instruction to the code in Linux that checks whether a data pagefault was a write fault..17:08
sb0stekern, do you confirm that irq_setmask(0) with your implementation of that function immediately disables all interrupts?17:10
stekernumm, do you have a link to my implementation of that function? ;)17:11
sb0https://github.com/m-labs/misoc/blob/master/software/include/base/irq.h#L5217:12
stekernyes, except interrupt 0 and 117:13
stekernthey are NMI17:13
sb0aaah17:13
sb0meh17:14
stekernto turn of those you need to unset the IE bit in SR17:14
sb0what's the point of those NMIs?17:14
sb0it sounds like something intel would do17:15
stekernisn't the question - what's the point of NMIs ;)17:15
stekernI don't know, it's in the spec17:16
sb0can't we just get rid of them?17:16
stekernfeel free to post a patch that makes them configurable with a parameter17:16
sb0i'd rather post a patch that removes them completely. is anyone using them for something useful?17:17
stekernhttps://github.com/openrisc/mor1kx/blob/master/rtl/verilog/mor1kx_pic.v#L120 <- that's where they are17:17
stekernI am currently using them for IPI17:17
sb0IPI?17:17
sb0multiprocessor communication?17:18
stekernyes17:18
sb0and it it useful that the software cannot mask them with MR?17:18
sb0*is it17:18
stekernit could/should probably be made to work without using the NMI interrupt for it17:19
sb0yeah17:20
stekernbut why is making it configurable such a big deal?17:20
stekernthat way you for sure doesn't brake it for anyone17:20
sb0#define irq_setmask(x) real_irq_setmask(x | 0x3)17:20
sb0because NMI implemented in this way are a stupid idea, and we need to make that point17:20
stekernwell... why do you *need* to use irq 0&2?17:21
sb0otherwise people will copy that code, and that's how monstrosities like x86 get built after more years and more resources invested into it17:21
stekernerr 0 and 117:21
sb0lm32 has irq's 0 and 1 implemented the proper way (i.e. maskable like the other ones) and I don't want the IRQ map to depend on the processor17:22
stekernfair enough17:23
stekernit's actually not even in the spec, it's just copied from the or12000 behaviour17:25
stekernI'd still make it configurable, to be or1200 compatible, but we can make the non-NMI case the default17:25
stekerns/to be/to be able to be17:26
sb0would it break any code?17:27
stekernhow would I know?17:28
stekernwe're not keeping track of users ;)17:28
blueCmdtoo many to keep track of!17:29
blueCmdor something17:29
stekernit's probably unlikely, but potentially breaking stuff for users is a good way to get rid of them17:29
sb0remove the NMI, see if anyone complains ;)17:30
blueCmdugh, or1k-src - we meet again. newlib being jammed in there17:30
sb0hmm, that still doesn't fix the or1k misoc uart bug ...17:31
sb0well, it does seem to improve things17:34
sb0maybe there's another unrelated bug...17:35
stekerncan I easily build the de0 nano port with or1kx?17:35
stekern+m17:35
stekernif so, I could take a peek17:36
sb0if it's up-to-date, just add "-Ot cpu_type or1k" in the build.py params to switch CPUs17:36
stekernok, I'll give it a go17:37
stekern...right after I built some fences... and took a look at the musl stuff I intended to get to today17:37
sb0actually it seems the uart works fine now. but flterm doesn not for some reason17:38
stekernat least the sockit board is running Linux on a dual core mor1kx fine now17:38
sb0with mmu and all that?17:39
stekernof course17:39
sb0wow, great!17:39
stekernwe don't have a non-mmu Linux port17:40
stekernblueCmd: it just hit me, maybe that sw bug I mentioned is what makes glibc with l.swa/l.lwa crash in or1ksim17:58
blueCmdstekern: oh17:58
stekernhttp://git.openrisc.net/cgit.cgi/stefan/linux/commit/?h=smp17:59
stekernnow I *really* need to build fences, but I'll test that later tonight17:59
blueCmdstekern: configure: WARNING: stdbool.h: present but cannot be compiled18:00
blueCmdhave you seend that before when building gcc w/ newlib?18:00
stekernblueCmd: hmm, not that I can recall19:32
blueCmdmight be a conflict between my two different toolchains19:34
stekernwhat's the other one? the linux toolchain?19:37
stekernand how are you building it?19:37
blueCmdblasting the others didn't work19:39
blueCmdlet me show you19:39
blueCmdhttp://9f8f5a9fac13f12a.paste.se/19:39
blueCmdthat's how19:39
stekernok, that looks right to me19:40
blueCmdno it doesn't19:41
stekernyes, it does, but it doesn't mean it's right ;)19:41
blueCmdhah :P I noticed that it was using the wrong or1k-src19:41
blueCmdso no, it didn't19:42
stekernhow did you expect me to spot that!? =)19:42
blueCmdideally I would like to only use newlib and libgloss from the "real" or1k-src19:42
blueCmdstekern: well, you made me spot it!19:43
blueCmdmy SRCDIR/or1k-src is just binutils from sourceware19:43
blueCmdit doesn't have newlib / libgloss19:43
stekernah, right19:43
stekernwe should split out newlib / libgloss in a seperate repo19:44
stekernbut nothing stops you from building that seperately19:45
stekernor you can just do it 'my ugly way' install binutils from sourceware ontop of an old installation ;)19:46
blueCmdhah19:46
blueCmdhopefully my board diag programs are not going to use a whole lot of TLS relocations ...19:47
stekernspeaking of TLS relocations, how did you test that when you added it to glibc?19:48
blueCmdstekern: the GCC tests19:49
blueCmdalso, glibc uses a shitton of them19:49
blueCmdbut since we're still discovering bugs related to it the testsuits are no doubt lacking :)19:50
stekernI need to write a ethernet adapter to put in between the arm and openrisc processors on the sockit board19:55
blueCmdah, cool stuff19:57
stekernI wonder if I should just 'cross-connect' the MAC in the ARM soc and a MAC in the openrisc soc19:57
blueCmdstekern: oh, did you find that spi dts thing?19:57
blueCmdstekern: yes, that sounds like a good idea to me19:58
stekernor do some fancy high speed interface with special linux drivers19:58
blueCmd"fancy high speed interface" would be some DMA/RDMA thing I guess19:59
stekernoh, sorry. lemme check.19:59
stekernhmm, can't seem to find it, but you just add the slaves under the master node20:05
stekernlike in the example here: http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/spi/spi-bus.txt20:05
blueCmdstekern: cool!20:08
blueCmdseems my newlib gcc works as well20:08
blueCmddouble cool20:08
stekernseems like today is the kind of day when things work20:08
blueCmdyes! :D20:09
stekernnot like the other day, 'let's try if my multicore-soc works on atlys... nope, the atlys board is broken... let's try if I can make a multicore soc work on the sockit... nope it crashes... let's try if quartus 14.0 can build the sockit soc, nope it errors out on clock connections'20:11
stekerntriplecool, that l.swa write check bugfix fixes the bug in debian too20:15
stekern...but it still crashes later on20:16
stekernbut not in the subtle 'just sit and do nothing' kind of way20:16
stekernhttp://pastie.org/935148620:18
stekernmy debug printk in the middle makes it even less subtle, but makes it a bit messy to read the original error message20:19
blueCmdstekern: "the bug in debian"20:22
blueCmdPretty sure we have more than one :P20:22
stekernthe one that prevented it from boot20:22
stekernthe only ones that count, 'if it boots, ship it', you know!20:23
stekern:P20:23
blueCmdhttp://cc70f44b28a27d1d.paste.se/20:26
blueCmdhaha20:26
blueCmdyeah20:26
stekernmehiko!20:27
blueCmdhm. now, how do I find out if I did something wrong? (like an invalid memory access)20:32
blueCmdthat will trigger an exception, but how do I tell newlib that I want to run some nice code for that20:32
stekernblueCmd: https://github.com/openrisc/or1k-src/blob/or1k/newlib/libc/machine/or1k/or1k-support-asm.S#L73120:37
sb0stekern, the other uart bug is due to the fact that, unlike lm32, or1k can't keep up with a continuous stream of received characters when executing-in-place from the serial flash (even with the caches)20:38
stekernsb0: ok, interesting20:38
stekernwhy's that you think?20:39
sb0when executing the same code from sdram it works20:40
stekernI mean, why would or1k be slower than lm32 when executing from the serial flash?20:40
sb0when executing from spi flash, the ISR that puts each character into the software ringbuffer can't run fast enough and some characters are dropped20:41
sb0well, this I don't know20:41
sb0it's just what I observe... compiling with -O3 instead of -Os seems to improve things20:41
stekernI would be happy with wild guesses too ;)20:42
stekernif we assume that lm32 and or1k runs at about equal speed once the data is in cache, it has to be something that differ in the cache refill20:43
stekernmor1kx wishbone interface uses wrapping bursts, could that screw things up?20:45
blueCmdstekern: aha! thanks :)20:45
sb0the spi flash controller doesn't support bursts, and will generate a single ack20:46
sb0hmm isn't the cache smaller?20:46
sb0https://github.com/m-labs/misoc/blob/master/misoclib/mor1kx/__init__.py#L16 vs. https://github.com/m-labs/misoc/blob/master/verilog/lm32/lm32_config.v#L8520:47
stekernI don't know what setup you have in your current setup, but IIRC I set it to be the same as you had in milkymist-ng20:47
stekernwell, I *didn't* know ;)20:48
sb0there are 2**OPTION_ICACHE_SET_WIDTH sets, right?20:48
stekernyes20:48
sb0so it should be the same ...20:49
sb0and the cache size is 2**(OPTION_ICACHE_SET_WIDTH + OPTION_ICACHE_BLOCK_WIDTH) 32-bit words?20:49
sb0everything works fine with -O220:51
stekernno, 2**(OPTION_ICACHE_SET_WIDTH + OPTION_ICACHE_BLOCK_WIDTH) bytes20:51
sb0actually I didn't do extensive testing with lm32. maybe it works with -Os and breaks with the other opt levels :p20:51
sb0ah, yes20:52
stekernbut LM32 is CFG_ICACHE_SETS*CFG_ICACHE_BYTES_PER_LINE20:52
stekernso, it's the same20:52
blueCmd multiple definition of `__getreent'. newlib/libc/reent/getreent.c as well as newlib/libc/machine/or1k/or1k-impure.c gets pulled in. getreent.c contains "/* default reentrant pointer when multithread enabled */" so I suspect multithreading somewhere20:52
stekernblueCmd: yeah, poke wallento20:54
sb0stekern, should I send you my patch to get rid of the NMI (or make them configurable, if you insist), or is it too simple?20:54
stekernsb0: is there any big differences in the binary size?20:55
sb0lm32 breaks at -O2 xD20:56
stekernif you have something ready, sure. I can just add it otherwise.20:56
sb0I have the complete removal of NMIs ready...20:56
stekernand please make it configurable if you do ;)20:57
sb0at -O2: 21320 bytes for LM32 (that breaks), 32104 bytes for or1k (that works)20:58
stekernwonder why the or1k binary is so much larger20:59
sb0at -Os: 18828 bytes for LM32 (that works), 28920 bytes for or1k (that breaks)21:00
stekernabout 8k of the or1k code is silly exception vectors21:01
sb0seems the arch needs some cleanup... NMI, flags, delay slot21:01
stekerndelay slot is optional21:02
stekernand NMI was an or1200 implementation detail21:02
sb0meh, yeah, 8k of exception vectors... what's the idea behind that?21:05
stekernI don't know, that's crazy21:05
stekernyou can skip the reserved once though21:06
sb0...can we get rid of that, too?21:06
sb0:)21:06
stekernand implementation wise, you can get rid of it21:06
stekernwith a bit of address decoding21:06
stekernif you're only interested in running your own baremetal code21:07
sb0we can start by simply removing the "reserved" exception vectors (0xf00 and above) from the crt, no?21:08
stekernyes21:08
sb0I guess nothing uses those vectors21:08
sb0tick timer? meh21:09
sb0timers should be external devices21:09
sb0why not uart and video vsync exceptions, while we're at it...21:10
stekernI agree, but a an on-cpu timer is probably less exotic than an on-cpu uart ;)21:11
ysionneaupoor mor1kx , now that sb0 started to play with it, it's like jack bauer interrogating a known terrorist :p21:12
ysionneauremoving parts until only what he wants comes out21:13
stekernI think so far, he's mostly interrogating the or1k architecture =)21:16
ysionneauthat's for a start :)21:17
ysionneaugn821:43
sb0where is the immediate of the l.sys instruction ending up?21:44
sb0r11?21:46
stekernnowhere21:52
stekernlinux for instance doesn't make use of the immediate21:53
stekernit loads the syscall number in r11 before issuing the l.sys21:54
sb0mh21:55
sb0why is there this immediate, then?21:55
stekernyou can always get it by loading the instruction from mem (which is how I guess they intended it to be used)21:56
stekernI don't see why you would do that though21:58
stekernit's not like the bits could be used for anything else though, so does it matter that you can load an immediate in there?21:59
sb0technically not so much22:00
sb0but it's kinda confusing, especially as the assembler enforces that you specify an immediate22:00
sb0loading the instruction from mem... hmm22:01
stekernagreed, it should just alias l.sys to l.sys 022:01
sb0that sounds slow22:02
sb0the d-cache will miss, and you need more ops22:02
stekernyeah, I didn't say it was a good idea... but it's the only reason I can come up with why they put it there in the first place22:03
sb0gn822:05
stekernnight22:05
mor1kx[mor1kx] skristiansson pushed 1 new commit to master: https://github.com/openrisc/mor1kx/commit/bae88d1bbc3f0dd12aacb9d119902b4a0c5a7e1b22:24
mor1kxmor1kx/master bae88d1 Stefan Kristiansson: pic: make NMIs configurable...22:24
--- Log closed Fri Jul 04 00:00:03 2014

Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!