| --- Log opened Thu Jan 08 00:00:43 2015 | ||
| stekern | juliusb: http://oompa.chokladfabriken.org/openrisc/openrisc.log | 06:14 |
|---|---|---|
| stekern | poke53282: I just meant not needing to bootstrap debian and build the 'glibc.deb' | 06:18 |
| stekern | but from what I understood from your comment, you have scripts to do that? | 06:18 |
| stekern | I'm running the tests in or1ksim | 06:19 |
| olofk | juliusb: I would have assumed that they could migrate these things seamlessly to another machine | 06:54 |
| olofk | Doing a DDR2 phy for Cyclone IV must be the worst decision ever | 07:46 |
| olofk | I'm close to giving up now. stekern, will it work to slap on a wb_avalon_bridge to the altmemphy controller? | 08:27 |
| olofk | Looks like altmemphy doesn't like the pin mapping. That's not good | 09:28 |
| stekern | that's basically what I do on sockit | 09:36 |
| stekern | (to the first question) | 09:36 |
| stekern | with a bit of qsys cruft/magic in between | 09:36 |
| olofk | I tried to add an altmemphy instance, but the fitter complained about pin placements, so I think I'm forced to use my generic hdl solution | 09:39 |
| olofk | (which doesn't work very well) | 09:39 |
| olofk | If 640kB really would have been enough for everyone, I could have done it with Block RAMs | 09:40 |
| poke53282 | stekern, well, I have script to do it in QEMU. The testsuite runs within 1-2 hours. | 09:40 |
| poke53282 | It is part of the toolchain | 09:40 |
| poke53282 | but it is not that easy. You need a static compiled qemu version. | 09:41 |
| olofk | Where is wallento when you need him | 09:43 |
| stekern | poke53282: that's fine, I have a static compiled qemu | 10:09 |
| stekern | my plan is to throw together an expect script that is crosscompiling the tests in qemu, but then transfer the result to or1ksim to run it there | 10:10 |
| juliusb | olofk: yeah, I was supposed to do that but I think it still required a shutdown? | 11:22 |
| --- Log closed Thu Jan 08 11:30:09 2015 | ||
| --- Log opened Thu Jan 08 11:31:15 2015 | ||
| -!- Irssi: #openrisc: Total of 48 nicks [0 ops, 0 halfops, 0 voices, 48 normal] | 11:31 | |
| -!- Irssi: Join to #openrisc was synced in 1 secs | 11:31 | |
| -!- You're now known as Guest57720 | 11:31 | |
| -!- You're now known as juliusb | 11:31 | |
| olofk | _franck__: Can I use upstream OpenOCD 0.8.0 for OpenRISC? | 15:02 |
| olofk | I vaguely remember that there was some stuff needed that was added after the 0.8.0 release | 15:03 |
| _franck__ | olofk: yes you can | 15:14 |
| _franck__ | you _must_ use the upstream OpenOCD | 15:24 |
| stekern | at least once a day | 15:28 |
| maxpaln | olofk: I've discovered a bug in the way I've written insert_wait_states() - I've fixed it, the updated version looks like this http://pastie.org/9820333 | 15:32 |
| maxpaln | are you ok to replace this manually - or do you want me to update the dropbox files? | 15:32 |
| olofk | maxpaln: Updating would be great | 16:42 |
| maxpaln | olofk: https://www.dropbox.com/s/9r27t1f7douqnwg/wb_bfm_latest_08-01-15.rar?dl=0 | 17:08 |
| olofk | maxpaln: Thanks | 17:21 |
| olofk | Are there any magic invocations that can be used to only build gdb (and potential prerequisites) from or1k-src? | 17:22 |
| stekern | olofk: I bet there is, we just need to find them | 17:43 |
| stekern | I want to know the magic if you succeed | 17:43 |
| olofk | I added --enable-option-checking to configure for or1k-src and it turns out that 90% of all the parameters in the build instructions are no-ops | 18:54 |
| olofk | "make all-gdb install-gdb" perhaps? Don't have or1k-src here to check | 19:07 |
| olofk | Do we still have the option to use or1ksim as the gdb simulator? (Not really sure what it means) | 20:28 |
| _franck_ | olofk: yes we have | 20:30 |
| olofk | Is it good for anything? | 20:31 |
| _franck_ | in GDB you have a builtin sim (not sure what it is for, except for testing). We also have a wrapper to use or1ksim as a simulator in GDB | 20:31 |
| olofk | I'm trying to clean up the build instructions a bit, and was wondering if we should mention that there, or if we should move that information to some separate page | 20:36 |
| olofk | But I still don't really understand when we can use it | 20:36 |
| ysangkok | poke53282: how do you generate basefs.xml? the scripts i see are for jor1k-sysroot... | 20:36 |
| _franck_ | olofk: I used it when I ran the GDB testsuite against or1ksim | 20:36 |
| _franck_ | it's not useful for common users | 20:37 |
| olofk | _franck_: Great. I'll make sure that the build instructions recommend users to disable that if they don't know what they are doing | 20:39 |
| olofk | Upstream newlib builds fine if I manuallly add or1k-sprs.h to libgloss/include. Should probably send a patch to add that | 21:03 |
| poke53282 | ysangkok: I did it initially with the same method with a basefs.tar.bz2 file. But then I changed it manually. | 21:41 |
| ysangkok | poke53282: i just inserted a check to warn when the sizes don't fit | 21:42 |
| poke53282 | Ok | 21:42 |
| ysangkok | poke53282: it turned up many problems | 21:42 |
| poke53282 | :) | 21:42 |
| ysangkok | poke53282: do you want me to issue a pull request or should i just tell you the problematic files? | 21:42 |
| poke53282 | shouldn't be, but it is possible with the basefs | 21:43 |
| poke53282 | Just tell me | 21:43 |
| ysangkok | poke53282: /etc/group | 21:43 |
| ysangkok | poke53282: /usr/bin/showmenu | 21:44 |
| poke53282 | Yes, both I changed afterwards :) | 21:44 |
| ysangkok | poke53282: /usr/bin/help | 21:44 |
| poke53282 | In principle I can reduce the basefs by removing most of the symbolic links. busybox can generate them by his own. | 21:45 |
| ysangkok | that would make sense | 21:45 |
| ysangkok | inittab is also off by one byte | 21:46 |
| poke53282 | fixed | 21:52 |
| ysangkok | thank you | 21:55 |
| poke53282 | I thank you | 21:56 |
| ysangkok | poke53282: i was wondering, why is bz2 compression used in the application instead of http layer gzip compression? | 21:56 |
| poke53282 | because it compresses the binaries so much better. I tried also gzip, by I was not satisfied. | 21:57 |
| poke53282 | yes, gzip would be faster, but the loading time would be worse. | 21:58 |
| poke53282 | not even http/2 will solve that problem. | 21:58 |
| ysangkok | decompression would surely be faster, the browser can cache the decompressed gzip replies if it wants. using bz2, this is impossible | 21:58 |
| poke53282 | Yes, the plan was, to put everything in it's own worker thread. And to use .xz or .lzma. | 21:59 |
| poke53282 | The speed is superior to bzip2. | 22:00 |
| poke53282 | But no problem. We can switch from a boolean compression variable to an integer one. c=0: no compression (or gzip) c=1: bzip2 c=2: lzma | 22:01 |
| ysangkok | yes | 22:01 |
| poke53282 | you recognize the decompression time only during the kernel decompression and the collect2 file of gcc. | 22:02 |
| poke53282 | but no compression is already an option. | 22:02 |
| ysangkok | yes i know | 22:02 |
| poke53282 | Keep in mind, not everyone has 50MBit download rate. | 22:02 |
| ysangkok | i recognize that | 22:02 |
| ysangkok | an issue that turned up during the development of the lazy loading, is, that if the file is compressed, the chunking can't be done | 22:03 |
| poke53282 | yes, we discussed this yesterday. | 22:03 |
| ysangkok | ah i forgot... but of course it's not really a serious issue | 22:04 |
| poke53282 | 1. solution: A file cannot be fully randomly loaded. If you want to have the end of the file, you have to download everything. | 22:05 |
| poke53282 | 2. solution. Don't compress. | 22:05 |
| poke53282 | 3. solution: use a pre defined Huffmann compression table for the binaries and for text files. | 22:05 |
| poke53282 | Just to test, I would implement only solution no. 2. | 22:06 |
| ysangkok | yes, i agree | 22:07 |
| ysangkok | but it would be useful with a flag for fs2xml to disable compression | 22:07 |
| poke53282 | Well, that's no problem. | 22:08 |
| poke53282 | Looks like, you start to understand the whole program pretty well. | 22:09 |
| ysangkok | :P only the filesystem layer... i have nowhere near the cpu for example :P | 22:10 |
| poke53282 | fs2xml also creates a json file. Or maybe I haven't committed it yet. | 22:10 |
| ysangkok | it does | 22:11 |
| poke53282 | the cpu is easy after you have read the specification. | 22:11 |
| poke53282 | The safecpu is easy. | 22:11 |
| poke53282 | the fast CPU is optimized and unreadable. | 22:11 |
| ysangkok | the cpu is feature complete, though, no? | 22:12 |
| poke53282 | complete enough I would say. | 22:12 |
| ysangkok | the custom xml parser is a hack, i think json would be nicer. or maybe a real third-party xml parser | 22:12 |
| poke53282 | Yes, therefore I implemented the json output. | 22:12 |
| poke53282 | But I haven't time yet, to use implement a json loader. | 22:13 |
| poke53282 | Yes, the XML loader is a terrible hack. | 22:13 |
| ysangkok | ok good | 22:13 |
| poke53282 | But it works. While I wrote the XML parser, my pulse was very high. I couldn't believe, that I had to implement it myself. | 22:15 |
| poke53282 | you are free to implement the json loader. | 22:15 |
| ysangkok | i'll do it once i get the lazy loading working... :) | 22:16 |
| poke53282 | I thought also to implement a binary format. That takes less bytes to load. | 22:16 |
| poke53282 | more than 50%. | 22:17 |
| ysangkok | i don't think there is much time to save, the metadata is not very big in comparison | 22:17 |
| poke53282 | But I like text files and gzip compresses such files. | 22:17 |
| ysangkok | yes, easy of use is also important | 22:17 |
| poke53282 | Parsing a binary file is always easier than parsing a text file. At least, when you program in C with no libraries and no build-in functions. | 22:18 |
| poke53282 | The only json is easier, because there is a built-in parser, which works even in a worker thread. | 22:19 |
| poke53282 | the onyl reason json is easier is, ...... | 22:20 |
| poke53282 | Also one suggestion. At the moment I use several ids to organize the tree structure. | 22:21 |
| poke53282 | But Javascript allows us to directly work with a tree structure. | 22:21 |
| poke53282 | To get rid of the ids. | 22:21 |
| ysangkok | you mean the inode tree? | 22:23 |
| poke53282 | yes | 22:24 |
| poke53282 | parentid, nextid, and firstid | 22:24 |
| poke53282 | the only thing you need is parentid. | 22:25 |
| poke53282 | nextid and firstid are just there for speed. | 22:25 |
| poke53282 | we can get rid of all ids if we use a similar structure like the json file. | 22:29 |
| poke53282 | hard links are a tiny problem then. | 22:29 |
| poke53282 | but solvable | 22:30 |
| ysangkok | when you say "the only thing you need is parentid" how do you mean this? does 9p only need the parent id? or is it some other interface? who is using firstid now? internal emulator code only? | 22:30 |
| poke53282 | well, to define a tree structure out of objects, an id is sufficient, which defines the parent. The tree can be built with that information. | 22:32 |
| poke53282 | 9p doesn't need the id. It is some internal stuff. | 22:33 |
| poke53282 | not the qid | 22:33 |
| poke53282 | firstid and nextid are used to sweep through the directory listing of one directory. But the parentid already contains this information. | 22:33 |
| poke53282 | Therefore firstid and nextid are only needed for fast file operations. | 22:34 |
| poke53282 | I should make a plot :) | 22:34 |
| ysangkok | i will probably understand once i take a look at the code | 22:36 |
| poke53282 | yes | 22:37 |
| ysangkok | poke53282: which branch is used for development? i see you pushed the DebugMessage/Debug fix to gh-pages, but not to master... i don't understand the strategy in place here | 23:29 |
| --- Log closed Fri Jan 09 00:00:47 2015 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!