| --- Log opened Thu Jul 03 00:00:01 2014 | ||
| dalias | stekern, hey | 01:56 |
|---|---|---|
| dalias | stekern, ah you left. n/m, catch you later then | 01:56 |
| stekern | dalias: what's up? | 04:49 |
| dalias | oh, just figured i'd check in on musl port | 04:55 |
| stekern | ah, it's good you're keeping an eye on me so I don't slack off ;) | 04:55 |
| stekern | I've been busy with other stuff lately, but I'll get around to give it some love soon again | 04:57 |
| stekern | basically, I'm still missing pieces in src/ldso and src/thread | 05:01 |
| stekern | I'll need to setup a system that actually use that stuff too, so I can test if what I do actually work | 05:02 |
| stekern | iirc, you hinted about some libc testsuite that I could use too | 05:03 |
| stekern | I'll dig the backlogs for it ;) | 05:03 |
| stekern | wb wallento, feeling better? | 06:48 |
| dalias | stekern, test suite is here: nsz.repo.hu/git/?p=libc-test | 07:59 |
| dalias | stekern, ldso should be easy now -- you just have to map the or1k relocations to a generic type of relocation | 08:00 |
| stekern | dalias: yeah, I saw that. I just have to figure out what I need to do in dlsym.s. | 08:05 |
| stekern | and in _dlstart | 08:11 |
| blueCmd | spi expanders - good/bad? I only have 8 GPIO pins and I want to add Ethernet, SDCard and RTC | 11:54 |
| LoneTech | depends. if you're using it to mux a select line and connect the spi to all of those, it's okay | 11:57 |
| -!- knz_ is now known as knz | 11:57 | |
| LoneTech | but you certainly won't want to talk through a gpio expander to any of them except possibly the rtc | 11:57 |
| blueCmd | LoneTech: yes, I want a chip that I can tell 'send device X data Y' | 11:59 |
| LoneTech | http://electronicdesign.com/displays/serial-control-multiplexer-expands-spi-chip-selects for instance | 11:59 |
| blueCmd | oh right, SPI has slave select - that makes it much simpler | 12:00 |
| blueCmd | I was thinking of I2C | 12:00 |
| blueCmd | but SPI is what I want | 12:00 |
| LoneTech | just double check that all devices put MISO (DO for them) in high impedance when not selected | 12:00 |
| LoneTech | or use a mux for that too | 12:01 |
| LoneTech | on i2c everything is slow (probably too slow for pratical use of ethernet or sd card) but chips have addresses | 12:05 |
| blueCmd | I'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 pins | 12:07 |
| blueCmd | so 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 module | 12:08 |
| blueCmd | to 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 value | 12:08 |
| LoneTech | could be done, assuming you need no data back from the mux. pay attention to the select levels. | 12:08 |
| LoneTech | also clock polarity; easiest if they all operate in the same spi mode | 12:09 |
| blueCmd | why would data back from the mux be a problem? | 12:09 |
| LoneTech | because it starts driving immediately as you released select from others. it'd be short, but may involve it fighting with another device | 12:09 |
| LoneTech | however, for this use you likely don't need any data back; you just send which bus to use between each select | 12:10 |
| LoneTech | also don't forget to make the idle state on every select line deselected | 12:11 |
| LoneTech | it's possible a counter or shift register could do better than a mux for the select job | 12:13 |
| blueCmd | I wonder if the linux driver (oc-tiny) can handle muxed GPIOs (or multi-slave buses in general) | 12:34 |
| blueCmd | http://comments.gmane.org/gmane.linux.kernel.spi.devel/12868 seems to have implemented what I want, but doesn't seem to be merged | 12:35 |
| LoneTech | the last one I looked at used linux' gpio layer to handle selects, but that may be simple, not tiny | 12:36 |
| LoneTech | oh, the other way around. the tiny driver uses gpio, which should allow use of extenders | 12:37 |
| LoneTech | yet it was the simple one I patched. oh well, still confused | 12:39 |
| blueCmd | I guess spi-simple is better from a performance POW though | 12:39 |
| LoneTech | perhaps 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 either | 12:40 |
| stekern | LoneTech: I gave the spi-simple a large overhaul after your patches too | 12:52 |
| stekern | the 'vanilla' simple core only have slave select via gpio too | 12:56 |
| stekern | the builtin ss was a orpsocv2 extension | 12:57 |
| stekern | can't remember if the linux driver have support for that extension neither | 12:57 |
| blueCmd | #define OCSPI_NUM_CHIPSELECTS 8 | 13:28 |
| blueCmd | I'm trying to figure out if I can have multiple devices on simple-spi | 13:28 |
| blueCmd | I don't see any examples of it, but somethings hint towards it | 13:28 |
| blueCmd | One comment in a DTS file is '/* Example SD card slot at chipselect 0 */' | 13:28 |
| stekern | yes you can | 13:29 |
| blueCmd | stekern: do you know how that works? like this? http://bc91ceca48efb8fd.paste.se/ | 13:33 |
| stekern | I 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 then | 13:34 |
| blueCmd | cool | 13:35 |
| blueCmd | right, 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.patch | 13:36 |
| blueCmd | right, I think I know how it works now, but I still need to figure out the dts syntax | 13:39 |
| dalias | stekern, dlsym.s just needs to pass the return address as an extra argument to __dlsym, so that the latter can support RTLD_NEXT | 14:14 |
| dalias | stekern, _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/consts | 14:16 |
| dalias | stekern, and _dlstart needs to be able to call it without the help of a GOT :) | 14:17 |
| dalias | stekern, otherwise the essential work of _dlstart is simply calling __dynlink with the args and then jumping to the address in the return value | 14:17 |
| dalias | stekern, 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 argc | 14:19 |
| blueCmd | the size for wb_interconnect - is that byte size of word size? | 15:19 |
| stekern | dalias: ok, thanks for the explanation. I'll take a look at _dlstart in the evening. | 15:21 |
| stekern | blueCmd: byte size | 15:21 |
| sb0 | stekern, 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 newlib | 16:59 | |
| stekern | sb0: ah, good news! | 17:06 |
| stekern | olofk: you will not believe this... | 17:07 |
| stekern | I 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 |
| sb0 | stekern, do you confirm that irq_setmask(0) with your implementation of that function immediately disables all interrupts? | 17:10 |
| stekern | umm, do you have a link to my implementation of that function? ;) | 17:11 |
| sb0 | https://github.com/m-labs/misoc/blob/master/software/include/base/irq.h#L52 | 17:12 |
| stekern | yes, except interrupt 0 and 1 | 17:13 |
| stekern | they are NMI | 17:13 |
| sb0 | aaah | 17:13 |
| sb0 | meh | 17:14 |
| stekern | to turn of those you need to unset the IE bit in SR | 17:14 |
| sb0 | what's the point of those NMIs? | 17:14 |
| sb0 | it sounds like something intel would do | 17:15 |
| stekern | isn't the question - what's the point of NMIs ;) | 17:15 |
| stekern | I don't know, it's in the spec | 17:16 |
| sb0 | can't we just get rid of them? | 17:16 |
| stekern | feel free to post a patch that makes them configurable with a parameter | 17:16 |
| sb0 | i'd rather post a patch that removes them completely. is anyone using them for something useful? | 17:17 |
| stekern | https://github.com/openrisc/mor1kx/blob/master/rtl/verilog/mor1kx_pic.v#L120 <- that's where they are | 17:17 |
| stekern | I am currently using them for IPI | 17:17 |
| sb0 | IPI? | 17:17 |
| sb0 | multiprocessor communication? | 17:18 |
| stekern | yes | 17:18 |
| sb0 | and it it useful that the software cannot mask them with MR? | 17:18 |
| sb0 | *is it | 17:18 |
| stekern | it could/should probably be made to work without using the NMI interrupt for it | 17:19 |
| sb0 | yeah | 17:20 |
| stekern | but why is making it configurable such a big deal? | 17:20 |
| stekern | that way you for sure doesn't brake it for anyone | 17:20 |
| sb0 | #define irq_setmask(x) real_irq_setmask(x | 0x3) | 17:20 |
| sb0 | because NMI implemented in this way are a stupid idea, and we need to make that point | 17:20 |
| stekern | well... why do you *need* to use irq 0&2? | 17:21 |
| sb0 | otherwise people will copy that code, and that's how monstrosities like x86 get built after more years and more resources invested into it | 17:21 |
| stekern | err 0 and 1 | 17:21 |
| sb0 | lm32 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 processor | 17:22 |
| stekern | fair enough | 17:23 |
| stekern | it's actually not even in the spec, it's just copied from the or12000 behaviour | 17:25 |
| stekern | I'd still make it configurable, to be or1200 compatible, but we can make the non-NMI case the default | 17:25 |
| stekern | s/to be/to be able to be | 17:26 |
| sb0 | would it break any code? | 17:27 |
| stekern | how would I know? | 17:28 |
| stekern | we're not keeping track of users ;) | 17:28 |
| blueCmd | too many to keep track of! | 17:29 |
| blueCmd | or something | 17:29 |
| stekern | it's probably unlikely, but potentially breaking stuff for users is a good way to get rid of them | 17:29 |
| sb0 | remove the NMI, see if anyone complains ;) | 17:30 |
| blueCmd | ugh, or1k-src - we meet again. newlib being jammed in there | 17:30 |
| sb0 | hmm, that still doesn't fix the or1k misoc uart bug ... | 17:31 |
| sb0 | well, it does seem to improve things | 17:34 |
| sb0 | maybe there's another unrelated bug... | 17:35 |
| stekern | can I easily build the de0 nano port with or1kx? | 17:35 |
| stekern | +m | 17:35 |
| stekern | if so, I could take a peek | 17:36 |
| sb0 | if it's up-to-date, just add "-Ot cpu_type or1k" in the build.py params to switch CPUs | 17:36 |
| stekern | ok, I'll give it a go | 17:37 |
| stekern | ...right after I built some fences... and took a look at the musl stuff I intended to get to today | 17:37 |
| sb0 | actually it seems the uart works fine now. but flterm doesn not for some reason | 17:38 |
| stekern | at least the sockit board is running Linux on a dual core mor1kx fine now | 17:38 |
| sb0 | with mmu and all that? | 17:39 |
| stekern | of course | 17:39 |
| sb0 | wow, great! | 17:39 |
| stekern | we don't have a non-mmu Linux port | 17:40 |
| stekern | blueCmd: it just hit me, maybe that sw bug I mentioned is what makes glibc with l.swa/l.lwa crash in or1ksim | 17:58 |
| blueCmd | stekern: oh | 17:58 |
| stekern | http://git.openrisc.net/cgit.cgi/stefan/linux/commit/?h=smp | 17:59 |
| stekern | now I *really* need to build fences, but I'll test that later tonight | 17:59 |
| blueCmd | stekern: configure: WARNING: stdbool.h: present but cannot be compiled | 18:00 |
| blueCmd | have you seend that before when building gcc w/ newlib? | 18:00 |
| stekern | blueCmd: hmm, not that I can recall | 19:32 |
| blueCmd | might be a conflict between my two different toolchains | 19:34 |
| stekern | what's the other one? the linux toolchain? | 19:37 |
| stekern | and how are you building it? | 19:37 |
| blueCmd | blasting the others didn't work | 19:39 |
| blueCmd | let me show you | 19:39 |
| blueCmd | http://9f8f5a9fac13f12a.paste.se/ | 19:39 |
| blueCmd | that's how | 19:39 |
| stekern | ok, that looks right to me | 19:40 |
| blueCmd | no it doesn't | 19:41 |
| stekern | yes, it does, but it doesn't mean it's right ;) | 19:41 |
| blueCmd | hah :P I noticed that it was using the wrong or1k-src | 19:41 |
| blueCmd | so no, it didn't | 19:42 |
| stekern | how did you expect me to spot that!? =) | 19:42 |
| blueCmd | ideally I would like to only use newlib and libgloss from the "real" or1k-src | 19:42 |
| blueCmd | stekern: well, you made me spot it! | 19:43 |
| blueCmd | my SRCDIR/or1k-src is just binutils from sourceware | 19:43 |
| blueCmd | it doesn't have newlib / libgloss | 19:43 |
| stekern | ah, right | 19:43 |
| stekern | we should split out newlib / libgloss in a seperate repo | 19:44 |
| stekern | but nothing stops you from building that seperately | 19:45 |
| stekern | or you can just do it 'my ugly way' install binutils from sourceware ontop of an old installation ;) | 19:46 |
| blueCmd | hah | 19:46 |
| blueCmd | hopefully my board diag programs are not going to use a whole lot of TLS relocations ... | 19:47 |
| stekern | speaking of TLS relocations, how did you test that when you added it to glibc? | 19:48 |
| blueCmd | stekern: the GCC tests | 19:49 |
| blueCmd | also, glibc uses a shitton of them | 19:49 |
| blueCmd | but since we're still discovering bugs related to it the testsuits are no doubt lacking :) | 19:50 |
| stekern | I need to write a ethernet adapter to put in between the arm and openrisc processors on the sockit board | 19:55 |
| blueCmd | ah, cool stuff | 19:57 |
| stekern | I wonder if I should just 'cross-connect' the MAC in the ARM soc and a MAC in the openrisc soc | 19:57 |
| blueCmd | stekern: oh, did you find that spi dts thing? | 19:57 |
| blueCmd | stekern: yes, that sounds like a good idea to me | 19:58 |
| stekern | or do some fancy high speed interface with special linux drivers | 19:58 |
| blueCmd | "fancy high speed interface" would be some DMA/RDMA thing I guess | 19:59 |
| stekern | oh, sorry. lemme check. | 19:59 |
| stekern | hmm, can't seem to find it, but you just add the slaves under the master node | 20:05 |
| stekern | like in the example here: http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/spi/spi-bus.txt | 20:05 |
| blueCmd | stekern: cool! | 20:08 |
| blueCmd | seems my newlib gcc works as well | 20:08 |
| blueCmd | double cool | 20:08 |
| stekern | seems like today is the kind of day when things work | 20:08 |
| blueCmd | yes! :D | 20:09 |
| stekern | not 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 |
| stekern | triplecool, that l.swa write check bugfix fixes the bug in debian too | 20:15 |
| stekern | ...but it still crashes later on | 20:16 |
| stekern | but not in the subtle 'just sit and do nothing' kind of way | 20:16 |
| stekern | http://pastie.org/9351486 | 20:18 |
| stekern | my debug printk in the middle makes it even less subtle, but makes it a bit messy to read the original error message | 20:19 |
| blueCmd | stekern: "the bug in debian" | 20:22 |
| blueCmd | Pretty sure we have more than one :P | 20:22 |
| stekern | the one that prevented it from boot | 20:22 |
| stekern | the only ones that count, 'if it boots, ship it', you know! | 20:23 |
| stekern | :P | 20:23 |
| blueCmd | http://cc70f44b28a27d1d.paste.se/ | 20:26 |
| blueCmd | haha | 20:26 |
| blueCmd | yeah | 20:26 |
| stekern | mehiko! | 20:27 |
| blueCmd | hm. now, how do I find out if I did something wrong? (like an invalid memory access) | 20:32 |
| blueCmd | that will trigger an exception, but how do I tell newlib that I want to run some nice code for that | 20:32 |
| stekern | blueCmd: https://github.com/openrisc/or1k-src/blob/or1k/newlib/libc/machine/or1k/or1k-support-asm.S#L731 | 20:37 |
| sb0 | stekern, 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 |
| stekern | sb0: ok, interesting | 20:38 |
| stekern | why's that you think? | 20:39 |
| sb0 | when executing the same code from sdram it works | 20:40 |
| stekern | I mean, why would or1k be slower than lm32 when executing from the serial flash? | 20:40 |
| sb0 | when executing from spi flash, the ISR that puts each character into the software ringbuffer can't run fast enough and some characters are dropped | 20:41 |
| sb0 | well, this I don't know | 20:41 |
| sb0 | it's just what I observe... compiling with -O3 instead of -Os seems to improve things | 20:41 |
| stekern | I would be happy with wild guesses too ;) | 20:42 |
| stekern | if 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 refill | 20:43 |
| stekern | mor1kx wishbone interface uses wrapping bursts, could that screw things up? | 20:45 |
| blueCmd | stekern: aha! thanks :) | 20:45 |
| sb0 | the spi flash controller doesn't support bursts, and will generate a single ack | 20:46 |
| sb0 | hmm isn't the cache smaller? | 20:46 |
| sb0 | https://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#L85 | 20:47 |
| stekern | I 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-ng | 20:47 |
| stekern | well, I *didn't* know ;) | 20:48 |
| sb0 | there are 2**OPTION_ICACHE_SET_WIDTH sets, right? | 20:48 |
| stekern | yes | 20:48 |
| sb0 | so it should be the same ... | 20:49 |
| sb0 | and the cache size is 2**(OPTION_ICACHE_SET_WIDTH + OPTION_ICACHE_BLOCK_WIDTH) 32-bit words? | 20:49 |
| sb0 | everything works fine with -O2 | 20:51 |
| stekern | no, 2**(OPTION_ICACHE_SET_WIDTH + OPTION_ICACHE_BLOCK_WIDTH) bytes | 20:51 |
| sb0 | actually I didn't do extensive testing with lm32. maybe it works with -Os and breaks with the other opt levels :p | 20:51 |
| sb0 | ah, yes | 20:52 |
| stekern | but LM32 is CFG_ICACHE_SETS*CFG_ICACHE_BYTES_PER_LINE | 20:52 |
| stekern | so, it's the same | 20: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 somewhere | 20:52 |
| stekern | blueCmd: yeah, poke wallento | 20:54 |
| sb0 | stekern, 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 |
| stekern | sb0: is there any big differences in the binary size? | 20:55 |
| sb0 | lm32 breaks at -O2 xD | 20:56 |
| stekern | if you have something ready, sure. I can just add it otherwise. | 20:56 |
| sb0 | I have the complete removal of NMIs ready... | 20:56 |
| stekern | and please make it configurable if you do ;) | 20:57 |
| sb0 | at -O2: 21320 bytes for LM32 (that breaks), 32104 bytes for or1k (that works) | 20:58 |
| stekern | wonder why the or1k binary is so much larger | 20:59 |
| sb0 | at -Os: 18828 bytes for LM32 (that works), 28920 bytes for or1k (that breaks) | 21:00 |
| stekern | about 8k of the or1k code is silly exception vectors | 21:01 |
| sb0 | seems the arch needs some cleanup... NMI, flags, delay slot | 21:01 |
| stekern | delay slot is optional | 21:02 |
| stekern | and NMI was an or1200 implementation detail | 21:02 |
| sb0 | meh, yeah, 8k of exception vectors... what's the idea behind that? | 21:05 |
| stekern | I don't know, that's crazy | 21:05 |
| stekern | you can skip the reserved once though | 21:06 |
| sb0 | ...can we get rid of that, too? | 21:06 |
| sb0 | :) | 21:06 |
| stekern | and implementation wise, you can get rid of it | 21:06 |
| stekern | with a bit of address decoding | 21:06 |
| stekern | if you're only interested in running your own baremetal code | 21:07 |
| sb0 | we can start by simply removing the "reserved" exception vectors (0xf00 and above) from the crt, no? | 21:08 |
| stekern | yes | 21:08 |
| sb0 | I guess nothing uses those vectors | 21:08 |
| sb0 | tick timer? meh | 21:09 |
| sb0 | timers should be external devices | 21:09 |
| sb0 | why not uart and video vsync exceptions, while we're at it... | 21:10 |
| stekern | I agree, but a an on-cpu timer is probably less exotic than an on-cpu uart ;) | 21:11 |
| ysionneau | poor mor1kx , now that sb0 started to play with it, it's like jack bauer interrogating a known terrorist :p | 21:12 |
| ysionneau | removing parts until only what he wants comes out | 21:13 |
| stekern | I think so far, he's mostly interrogating the or1k architecture =) | 21:16 |
| ysionneau | that's for a start :) | 21:17 |
| ysionneau | gn8 | 21:43 |
| sb0 | where is the immediate of the l.sys instruction ending up? | 21:44 |
| sb0 | r11? | 21:46 |
| stekern | nowhere | 21:52 |
| stekern | linux for instance doesn't make use of the immediate | 21:53 |
| stekern | it loads the syscall number in r11 before issuing the l.sys | 21:54 |
| sb0 | mh | 21:55 |
| sb0 | why is there this immediate, then? | 21:55 |
| stekern | you can always get it by loading the instruction from mem (which is how I guess they intended it to be used) | 21:56 |
| stekern | I don't see why you would do that though | 21:58 |
| stekern | it'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 |
| sb0 | technically not so much | 22:00 |
| sb0 | but it's kinda confusing, especially as the assembler enforces that you specify an immediate | 22:00 |
| sb0 | loading the instruction from mem... hmm | 22:01 |
| stekern | agreed, it should just alias l.sys to l.sys 0 | 22:01 |
| sb0 | that sounds slow | 22:02 |
| sb0 | the d-cache will miss, and you need more ops | 22:02 |
| stekern | yeah, 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 place | 22:03 |
| sb0 | gn8 | 22:05 |
| stekern | night | 22:05 |
| mor1kx | [mor1kx] skristiansson pushed 1 new commit to master: https://github.com/openrisc/mor1kx/commit/bae88d1bbc3f0dd12aacb9d119902b4a0c5a7e1b | 22:24 |
| mor1kx | mor1kx/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!