| --- Log opened Thu Sep 25 00:00:09 2014 | ||
| -!- Netsplit *.net <-> *.split quits: bentley` | 00:52 | |
| olofk | Fuck you Quartus! | 07:44 |
|---|---|---|
| olofk | At least give me a warning when I'm passing a 16-bit value through a 8-bit register, instead of quietly setting the top half to zero | 07:46 |
| -!- ed-jones_ is now known as ed-jones | 09:58 | |
| blueCmd | poke53282: THANKS soo much for doing that, I never was able to get full runs without weird errors | 10:12 |
| blueCmd | poke53282: did you try to use profile-dir=. ? | 10:13 |
| olofk | Took me a while to reverse-engineer this weird format conversion. Apparently I should take three 16-bit words, reverse the order of them, and then treat them like four 12-bit words | 11:08 |
| olofk | stekern, hansfbaier : Are the SPI and I2C masters in the de0 nano port connected to anything on the de0 nano, or just forwarded to the pin headers? | 11:12 |
| olofk | aha... pinmap.tcl had some clues here | 11:12 |
| hansfbaier | olofk: Yes, they are connected to some peripherals | 11:16 |
| hansfbaier | but one of them is forwarded to the port IIRC | 11:16 |
| olofk | hansfbaier: Yes, one I2C and one SPI from what I can see | 11:16 |
| olofk | And I assume that "bottom header" is the shorter one at the short end of the board | 11:17 |
| hansfbaier | Yes, the file should be quite readable | 11:17 |
| hansfbaier | olofk: sorry have to go, got a gig tonight | 11:17 |
| olofk | hansfbaier: Knock 'em dead! | 11:17 |
| hansfbaier | :) | 11:29 |
| stekern | olofk: what are you doing? | 11:45 |
| stekern | btw, I have added a 'tx_cnt' register that can be read at address 4 to my wb_writer | 11:46 |
| olofk | stekern: Working on my OpenRISC-SoC for MyriadRF | 11:48 |
| stekern | to be able to get information about how much has been transmitted | 11:48 |
| olofk | stekern: Cool. Does linux use it, or just for debug purposes? | 11:48 |
| stekern | but, I'd like to get some input before I propose it in the form of a pull request | 11:49 |
| olofk | It should shut down the core when more than 1MB has been transmitted, and there is no valid license. That's my only opinion | 11:49 |
| stekern | now, the buf_size is in bytes, but the tx_cnt is in words | 11:49 |
| stekern | I think those should be of same magnitude | 11:50 |
| olofk | I think we should use bytes | 11:50 |
| stekern | ok, good, one question down ;) | 11:50 |
| olofk | I have a few ideas how to extend the core to handle unaligned accesses in the future | 11:50 |
| olofk | which is useful for ethernet packets or just moving arbitrary memory regions | 11:51 |
| olofk | burst size can still be any unit. That is really only used to control bus utilization | 11:51 |
| stekern | second question, do you want the register to be seperate or should we use write of register 2 as buf_size and read as the current transmitted bytes | 11:53 |
| olofk | Are there any good reasons to reuse the register? Having it separate sounds more straight-forward | 11:54 |
| olofk | Is tx_cnt per transaction, or total? | 11:54 |
| stekern | I have renamed adr and made it visible to _cfg.v | 11:55 |
| olofk | ah ok. Yeah, then it makes a little more sense to reuse reg 2 | 11:55 |
| stekern | but I don't know if there's really much benefit of saving one reg like that | 11:56 |
| olofk | No opinion here really. If you have a feeling for what would be more standard, go with that | 11:56 |
| stekern | reg 2 could just read out the buf_size as written if someone cares to get to know the current setting | 11:56 |
| olofk | True. I think that is better actually, in case someone wants to know what the driver has set it to | 11:57 |
| stekern | let's leave it as a seperate register | 11:57 |
| olofk | Software sometimes does crazy shit to hardware | 11:57 |
| stekern | and to answer the question if it's needed or just for debugging, Linux can make use of it, but it's not mandatory | 11:58 |
| olofk | I need an i2c slave. Any ideas? | 11:58 |
| olofk | I think it's a good addition | 11:59 |
| stekern | but since the logic already is there and it's just a matter of making it visible on the wb bus, I thought I throw that in | 11:59 |
| stekern | it might help me sort out the buffer underrun problems I have with my sound setup too | 11:59 |
| stekern | I think the DMA driver is ok, so it has to be something with how I set up the 'sound card' | 12:00 |
| stekern | alsa is a mess... | 12:00 |
| olofk | Are you using one or several buffers? | 12:00 |
| olofk | Yeah, you should go with pulseaudio instead ;) | 12:00 |
| stekern | the DMA driver setup a set of software descriptors | 12:02 |
| stekern | and then those are used as a ring buffer | 12:02 |
| olofk | good. That's how I assumed it would work | 12:03 |
| stekern | the problem seems to mostly arise when the ring "starts over" | 12:03 |
| olofk | You're using linux, right? | 12:04 |
| olofk | Because windows xp 32 bit is the only supported platform for this hardware | 12:05 |
| stekern | ah... no, I'm currently using windows 7 | 12:05 |
| stekern | there's a 32-bit windows xp machine next to me, will that help? | 12:08 |
| olofk | Anyone about to move to Sweden and is looking for a job? | 15:45 |
| stekern | olofk: what's the offer? ;) | 15:52 |
| olofk | Our company is looking for experienced people in HW/layout/schematics/FPGA | 15:53 |
| poke53282 | blueCmd: You are welcome. I am wondering, why you had problems. I use your binary. | 15:53 |
| poke53282 | I didn't used the profile-dir in the end. This option didn't change anything. | 15:54 |
| poke53282 | but some problems aren't related to gcc. | 15:55 |
| poke53282 | but to QEMU. | 15:55 |
| poke53282 | this C file is a weird one: 20030125-1.c http://pastie.org/9593961 | 15:58 |
| poke53282 | I don't have a clue why it crashes in QEMU. | 15:58 |
| poke53282 | I haven't compiled qemu for a long time. Maybe it's time. | 16:13 |
| poke53282 | to fix a few things. | 16:13 |
| poke53282 | Finally I could also run the testsuite for libffi. | 16:14 |
| stekern | poke53282: iirc, that one failed in my setup too | 16:49 |
| stekern | doesn't it fail when running it in jor1k? | 16:50 |
| poke53282 | no | 16:50 |
| poke53282 | qemu: uncaught target signal 6 (Aborted) - core dumped | 16:50 |
| poke53282 | I can compile qemu, but my distribution got rid of all static libraries :( | 16:51 |
| poke53282 | so I can't compile a static qemu. | 16:51 |
| stekern | hmm, measuring the time it takes for my i2s logic to pull out 8192 bytes of wb_streamer, I get around 11.7 ms | 18:34 |
| stekern | but 8192 bytes should be 1024 samples 8192/(4*2), which should take 21.3333ms @48kHz | 18:35 |
| stekern | right? | 18:35 |
| stekern | some stupid mistake somewhere, for certain... | 18:36 |
| poke53282 | each sample has 32 bit? two channels? | 18:48 |
| poke53282 | 48kHz? | 18:48 |
| stekern | yes | 18:53 |
| stekern | I just measured the period of my lrclk, and that is 48kHz | 18:54 |
| stekern | so the mistake is not there at least | 18:54 |
| stekern | and my logic pulls a sample out of the wb_streamer at each edge of the lrclk | 18:55 |
| stekern | also a sanity check of the kernel time keeping turned out ok | 18:57 |
| stekern | at least the error is a sensible divide by 2 | 18:59 |
| poke53282 | The no of channels are most obvious thing, that could give you a factor of two. | 19:06 |
| stekern | yes | 19:07 |
| stekern | but I get the 8192 from my dma driver | 19:07 |
| stekern | and that's the value I write to the wb_streamer core | 19:07 |
| stekern | so the number of things that can be wrong is quite limited | 19:08 |
| poke53282 | blueCmd: If I compile with my static qemu version the error seems to be gone. I rerun the testsuite now | 19:42 |
| poke53282 | and then I will take a look at your swa and lwa implementation. | 19:43 |
| stekern | doh... of course the time doesn't add up, I have a 1024 word deep FIFO. so when the interrupt comes, I've read out ~1024 words to the i2s interface and ~1024 words are in the FIFO | 21:23 |
| stekern | seems like the underruns are actually real underruns, the sin test use sin() (no precalc) | 21:25 |
| stekern | and the .wav I tested was 44100, and resampling was obviously to heavy. If I convert it to 48000 I can play it | 21:26 |
| stekern | *too | 21:26 |
| stekern | I should add a small config core between that can switch clocks and do some 32->16/32->24 bit conversions so I can support all kinds of formats | 21:28 |
| olofk | Cool | 21:35 |
| poke53282 | stekern: you should trigger the interrupt when the fifo is half empty. | 22:04 |
| stekern | poke53282: why? | 22:08 |
| poke53282 | to refill as long as there is time? Ahh sorry, mixed this up with the pio mode I tried. | 22:09 |
| stekern | when I get the interupt, the fifo is full | 22:10 |
| poke53282 | for DMA this is probably not necessary. | 22:10 |
| stekern | not empty | 22:10 |
| poke53282 | Hmm, in which way this method differ from the Soundblaster standard. This programmed (decades ago) by hand. | 22:10 |
| poke53282 | You a ring buffer and at position 0 and buffersize/2 an interrupt was triggered. | 22:11 |
| poke53282 | You had a ring buffer and at position 0 and buffersize/2 an interrupt was triggered. | 22:11 |
| poke53282 | And the DMA device read periodically this buffer. | 22:11 |
| stekern | yes, that's basically how this works too | 22:12 |
| stekern | but we don't have automatic cyclic reading | 22:13 |
| stekern | and the ring buffer is split up in smaller chunks | 22:13 |
| stekern | so, you get an interrupt at the end of each chunk | 22:14 |
| poke53282 | Ok, that's basically the same. | 22:14 |
| stekern | but, to have time to start of the next chunk, we have a buffer FIFO | 22:15 |
| poke53282 | But the FIFO is an internal part of the DMA device? | 22:17 |
| stekern | yes | 22:17 |
| poke53282 | blueCmd: Sorry, I was wrong. This 20030125-1.c also crashes in jor1k. I compiled it without optimization. | 22:25 |
| poke53282 | But I compile it with, it crashes too. Has nothing to do with qemu. | 22:26 |
| poke53282 | blueCmd: Now I know, why I had never this error in uclibc. They don't test it there: "if { [check_effective_target_uclibc] } { return 1 }" | 23:02 |
| poke53282 | Anyhow, this is a really weird testcase. | 23:09 |
| --- Log closed Fri Sep 26 00:00:10 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!