| --- Log opened Wed Nov 05 00:00:14 2014 | ||
| poke53282 | stekern: Can you write a non-zero file with the vi of busybox and check the output size of the file? | 02:35 |
|---|---|---|
| poke53282 | please | 02:37 |
| stekern | poke53282: absolutely | 04:07 |
| stekern | ~ # ls -al test | 04:08 |
| stekern | -rw-r--r-- 1 root 0 0 Nov 5 2014 test | 04:08 |
| poke53282 | you might take a look in the musl irc channel | 04:08 |
| poke53282 | I have found an error. | 04:08 |
| poke53282 | in musl | 04:08 |
| stekern | ok, I assume that when you do that it's not 0? | 04:09 |
| poke53282 | Did you write an empty file? | 04:09 |
| poke53282 | It is always zero. And this is the problem. | 04:09 |
| poke53282 | At least for me. | 04:10 |
| stekern | ? | 04:11 |
| stekern | I've just woken up, you have to speak slowly and very clearly ;) | 04:12 |
| poke53282 | open vi, write some text and save the file. And check the size. | 04:12 |
| stekern | yes, that's what I did? | 04:13 |
| poke53282 | and the size turns out to be zero, which is obviously wrong. | 04:13 |
| stekern | is it? | 04:13 |
| poke53282 | This would be a bad text editor otherwise. | 04:14 |
| poke53282 | at least, this is what you posted above. Zero | 04:15 |
| poke53282 | 0 | 04:15 |
| stekern | well, this is what happens when I do the same on my x86_64 ws: | 04:16 |
| stekern | $ ls -al test | 04:16 |
| stekern | -rw-rw-r-- 1 stefan stefan 0 Nov 5 06:15 test | 04:16 |
| poke53282 | ":wq test" in vi? | 04:19 |
| stekern | yes | 04:19 |
| poke53282 | Either you didn't write a text in vi or you must be kidding, or it is indeed too early. | 04:20 |
| stekern | maybe it's my turn to ask 'stupdd' questiions today, why isn't an empty file expected to be 0? | 04:20 |
| poke53282 | !!!non-empty!!! | 04:21 |
| stekern | don't write empty when you mean non-empty then ;) | 04:21 |
| poke53282 | "open vi, *write some text* and save the file. And check the size. " | 04:21 |
| stekern | ok, *now* this conversion begins to be a lot less confusing ;) | 04:23 |
| poke53282 | Good, let's reset. | 04:23 |
| stekern | yes, it's still zero even when there's content in the file | 04:23 |
| poke53282 | *GOOD*, or let's say *BAD* | 04:23 |
| stekern | right | 04:24 |
| poke53282 | musl/arch/or1k/syscall_arch.h | 04:24 |
| poke53282 | #define __SYSCALL_LL_O(x) 0, __SYSCALL_LL_E((x)) | 04:24 |
| poke53282 | the "0, " is wrong here. | 04:24 |
| poke53282 | because our 64 Bit values are not aligned | 04:25 |
| poke53282 | you can test yourself with the code http://pastie.org/9696895 | 04:27 |
| poke53282 | "file.dat" must exist before of course. | 04:27 |
| stekern | right, I see | 04:28 |
| poke53282 | dalias is informed. If you give your Ok, he will patch it. | 04:29 |
| stekern | so, it should be: #define __SYSCALL_LL_O(x) __SYSCALL_LL_E((x)) | 04:33 |
| poke53282 | Yes | 04:34 |
| stekern | yeah, that's an obvious bug (obvious once you get it pointed out for you) | 04:34 |
| poke53282 | It's only obvious if you see, how it is used. | 04:36 |
| dalias | :) | 04:36 |
| stekern | does microblaze align 64-bit types? | 04:37 |
| dalias | yes | 04:37 |
| stekern | since that's where I think I copy-pasted it from | 04:37 |
| stekern | ok, good | 04:37 |
| stekern | dalias: so, could you make the musl source a couple of bytes slimmer for us, or do you want poke53282 (or me) to post a patch for it? | 04:40 |
| dalias | i can do it | 04:42 |
| dalias | i just wanted to know if this fix is correct | 04:42 |
| poke53282 | Ok, thanks | 04:46 |
| olofk | Didn't you just miss a great opportunity to save disk space, if all files can be 0 bytes? | 08:12 |
| olofk | Anyone got a nice DDR2 controller for me? | 10:03 |
| olofk | Looks like there is one in OpenSPARC. Time to check out OpenSPARC then | 11:18 |
| stekern | olofk: doesn't misoc have one? | 11:31 |
| olofk | stekern: Oh, right. I should have checked there first of course | 11:41 |
| olofk | Can only find a DDR controller in verilog, and some target specific other ones written in migen | 11:46 |
| olofk | ysionneau: Do you have any info here? | 11:46 |
| maxpaln | olofk: I have something that is starting to do the right thing now. Although as I have developed it I have realised this will probably be most useful as a 2nd stage debug tool - since the reads/writes are out of sequence it is a bit of a pain to track back through the transactions to find where things went wrong. As such, I expect your original Write-Then-Read test will be the best place to | 13:58 |
| maxpaln | start - then once the controller is doing the right thing, this second test that produces more real world traffic can be applied. | 13:58 |
| maxpaln | I still need to implement the variable wait states but the random read/write transactions of arbitrary type and length appears to be working. | 13:59 |
| ysionneau | 12:31 < stekern> olofk: doesn't misoc have one? < yes | 13:59 |
| ysionneau | LASMIcon is sdram/ddr/ddr2/ddr3 controller | 13:59 |
| ysionneau | and there is a PHY for Spartan6 and kintex7 | 14:00 |
| ysionneau | I'm working on a smaller sdram controller right now | 14:00 |
| ysionneau | it already works for sdram but I have a few stuff to fix for DDR | 14:00 |
| ysionneau | I don't have a lot of knowledge of the features of LASMIcon, but as far as I know it's quite performant | 14:02 |
| ysionneau | better ask sb0 about it | 14:02 |
| ysionneau | olofk: the 3 RAM PHYs : https://github.com/m-labs/misoc/tree/master/misoclib/sdramphy | 14:03 |
| ysionneau | gensdrphy is SDRAM only (no ddr) | 14:03 |
| ysionneau | k7ddrphy is working successfully on KC705 board with DDR3 | 14:04 |
| ysionneau | s6ddrphy for spartan 6 boards with DDR/DDR2 (like M1, Mixxeo) | 14:05 |
| ysionneau | interface between controller and PHY is DFI | 14:05 |
| ysionneau | controller is LASMIcon : https://github.com/m-labs/misoc/tree/master/misoclib/lasmicon | 14:06 |
| ysionneau | if you want specific examples I could point you to it | 14:06 |
| olofk | ysionneau: Ah cool. I didn't know about DFI. I was actually thinking of defining something like that | 14:42 |
| olofk | Which revision are you using? | 14:44 |
| olofk | Jesus christ. There's an insane amount of signals here | 14:49 |
| ysionneau | don't know the exact version though :p | 14:55 |
| ysionneau | but you can have a look at the available signals over there: https://github.com/m-labs/migen/blob/master/migen/bus/dfi.py | 14:56 |
| ysionneau | it's pretty easy to use, I am using it also for my small sdram controller | 14:56 |
| ysionneau | it's basically the physical wires + some others like rddata_en (that you should assert when you issue the READ command), rddata_valid (that is asserted when the PHY has received the data), rddata (contains the data sampled by the PHY) | 14:57 |
| olofk | ysionneau: Ah ok. So you're only using three of the channels? That makes it quite a bit simpler | 14:57 |
| ysionneau | and same kind of stuff for the write | 14:57 |
| ysionneau | I haven't actually read the spec :p | 14:58 |
| ysionneau | I'm just using the dfi implementation in Migen | 14:58 |
| ysionneau | it's quite simple and it works | 14:58 |
| olofk | Also quite similar to the interface I defined for the stuff I've been working on for the last weeks | 14:58 |
| ysionneau | you can also connect a dfi injector that allows you to take over control of the PHY (via dfi) from the software | 14:58 |
| ysionneau | useful for doing the init_sequence from software bitbang | 14:59 |
| ysionneau | instead of wasting fpga space for that | 14:59 |
| ysionneau | you get this for free by using the dfi from migen :) | 14:59 |
| olofk | Aren't there any flow control signals that the phy can use to deny requests? | 14:59 |
| ysionneau | not sure | 15:00 |
| ysionneau | you want to be able to deny ? | 15:00 |
| olofk | I mean that I can't find a way for the phy to indicate that it can't handle any more requests | 15:00 |
| olofk | How will the mc know that? | 15:01 |
| ysionneau | the way it works right now is that the dfi has several "phases" | 15:01 |
| ysionneau | the controler runs on system clock | 15:01 |
| ysionneau | the phy has multiplied clock | 15:01 |
| ysionneau | the controller puts commands in the phases | 15:02 |
| ysionneau | like dfi.phases[rdphase].ras_n.eq(0) etc | 15:02 |
| ysionneau | and the phy presents the data at the right moment | 15:02 |
| ysionneau | on the physical lines | 15:02 |
| ysionneau | so there is no way of "overflowing" the phy | 15:03 |
| ysionneau | basically the phy runs faster than the MC | 15:03 |
| ysionneau | and MC can only put N commands per system clock cycle (N being the number of phases) | 15:04 |
| ysionneau | not sure if I'm clear :p | 15:04 |
| ysionneau | if by flow control you mean taking into account all the tRAS tCAS tRRD etc timing restrictions, this has to go inside the MC state machine | 15:08 |
| maxpaln | well, what do you know? The more stringent wishbone transactor is already paying dividends. Just discovered a bug on back-to-back read bursts!! | 16:36 |
| poke53282 | Firefox compiles and links | 23:03 |
| poke53282 | Only three points prevent me from running it. | 23:03 |
| poke53282 | 1. A limitation of the OpenRISC port in the binutils package (16 Bit R_OR1K_GOT16) | 23:03 |
| poke53282 | 2. xpcom of Firefox (two hundred lines to implement the ABI) | 23:03 |
| poke53282 | 3. To run it, you would have to download approx 50MB of compressed data. (I want Firefox 1.0 back) | 23:03 |
| poke53282 | libxul.so has a size of 100MB. | 23:05 |
| poke53282 | uncompressed | 23:05 |
| dalias | wtf | 23:06 |
| poke53282 | Well, it has a size of 64MB on a x86-64 machine. | 23:08 |
| dalias | not quite that big for me on alpine, but almost | 23:09 |
| dalias | and holy shit, over 300k relocations | 23:09 |
| poke53282 | The binaries here are a little bit larger. But they compress well. | 23:09 |
| poke53282 | Yes, the 16 Bit limitation prevents me from linking correctly. | 23:09 |
| poke53282 | I removed the error message ;) | 23:10 |
| dalias | at least most of them are relative tho | 23:11 |
| poke53282 | Maybe there is a way in Firefox to reduce separate the lib. I think, I have seen something like this. To have the Javascript part separated. | 23:12 |
| dalias | splitting it out is likely to make it load a lot slower | 23:13 |
| dalias | since there will be more symbolic relocations | 23:13 |
| dalias | really binutils just needs to support making arbitrarily many GOTs | 23:13 |
| dalias | i think | 23:13 |
| dalias | that's how ppc and other archs with 16-bit offsets work, i think | 23:14 |
| dalias | really just with or1k had 32-bit immediates like microblaze tho... | 23:14 |
| dalias | it's by far the nicest of the "ugly risc isa" family :) | 23:14 |
| dalias | s/with/wish/ | 23:15 |
| dalias | apologies for my lisp :) | 23:15 |
| poke53282 | Well, we have to live with it. 32-bit immediates would not fit in the 32 Bit instruction size limit. | 23:17 |
| dalias | microblaze also has 32-bit instruction size | 23:17 |
| dalias | they have a really cool system for making it work :) | 23:17 |
| poke53282 | how? | 23:19 |
| dalias | the assembler generates a pair of instructions where the first contains the upper half of the immediate | 23:20 |
| dalias | i don't know exactly how it works with interrupts/faults but it does, and it's transparent as far as i can tell | 23:21 |
| poke53282 | l.movhi r1, 0x1234; l.ori r1,r1,0x5678 | 23:22 |
| poke53282 | This is how you load a 32 Bit value for OpenRISC. Two instructions. | 23:22 |
| poke53282 | --enable-shared-js Create a shared JavaScript library. | 23:25 |
| poke53282 | this I can try | 23:25 |
| poke53282 | The microblaze ABI doesn't look like that different to OpenRISC | 23:30 |
| poke53282 | But honestly, it was never intended by the one who wrote the binutils port to link Firefox 31 with it. who would have known, that there is such a limit. The community for the other CPUs is just larger, that such things get fixed. | 23:37 |
| dalias | yeah but you have to load them into a register in 2 instructions, then have another instruction to use the register | 23:46 |
| dalias | and lots of the advantages of an immediate are thereby lost | 23:46 |
| dalias | and if that exhausts your call-clobbered registers, you need a lot more code to push and pop a stack frame, etc. :( | 23:47 |
| --- Log closed Thu Nov 06 00:00:16 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!