| --- Log opened Mon Jan 26 00:00:13 2015 | ||
| olofk | _franck_, stekern: Looking at the vga_lcd core for the first time now. Is screen resolution only determined by vsync/hsync timing? | 09:15 |
|---|---|---|
| _franck_ | olofk: you have xres and yres in OCFB_HTIM and OCFB_VTIM registers | 09:23 |
| _franck_ | but yes, resolution is just a matter of software configuration | 09:23 |
| olofk | _franck_: Ah cool. Thanks. | 09:23 |
| _franck_ | and clock speed | 09:23 |
| _franck_ | https://github.com/fjullien/linux/blob/neek/drivers/video/fbdev/ocfb.c#L126 | 09:24 |
| olofk | Perfect! So there aren't any `defines I need to setup | 09:25 |
| olofk | ? | 09:25 |
| _franck_ | AFAIR: no | 09:25 |
| olofk | _franck_: How do I configure ocfb from Linux? | 09:34 |
| _franck_ | you need to hack this: https://github.com/fjullien/linux/blob/neek/drivers/video/fbdev/ocfb.c#L56 | 09:35 |
| _franck_ | I have a patch ready to configure the fb from the device tree: https://github.com/fjullien/linux/commit/29c60f94327a4a3d73af7e33f92aa3289956669a | 09:36 |
| _franck_ | https://github.com/fjullien/linux/commit/148dcc0c27e968df4f689c4f6887403de75ce211 | 09:36 |
| olofk | cool | 09:36 |
| olofk | And what will the default values be without that patch? | 09:37 |
| _franck_ | 640x480 @ 60 Hz, 31.5 kHz hsync | 09:38 |
| olofk | Does it pick up the clock frequency automatically? | 09:39 |
| _franck_ | it doesn't know about clock frequ | 09:40 |
| _franck_ | you just tell it | 09:40 |
| olofk | how? | 09:40 |
| olofk | (without your device tree patch) | 09:41 |
| _franck_ | I'm not even sur you tell it. For xhat I remember it just don't care | 09:41 |
| olofk | How does that work? | 09:42 |
| _franck_ | well, linux just prepare a frame buffer of x * y pixels and the frame buffer DMA get pixels and prints them | 09:42 |
| _franck_ | the driver does not need to knwo at which clock rate pixels are going to be read | 09:43 |
| olofk | True, but I need to set my DVI clock to something | 09:43 |
| _franck_ | you have to figure out what clock you need to put here | 09:45 |
| _franck_ | in vga, you get frame rate and pixels and you compute pixel rate | 09:45 |
| _franck_ | stekern: did use DVI on the atlys board I think, you can look at that | 09:46 |
| olofk | I found a comment in the sockit clkgen.v that sets it to 25.2MHz | 09:46 |
| olofk | Seems like atlys sets it to 50MHz. That seems consistent with what I want to do | 09:47 |
| olofk | Will it generate the sync stuff even if I haven't connected the wb interface? So I can see if the monitor detects anything | 09:51 |
| _franck_ | No, you have to write things to registers to start the controller | 09:56 |
| _franck_ | I didn't that with openocd while I was testing it | 09:57 |
| _franck_ | s/didn't/did | 09:57 |
| olofk | That's a good idea | 09:57 |
| olofk | I love OpenOCD more and more | 09:57 |
| olofk | Do you have any scripts or notes or something I can use to get started? | 09:58 |
| _franck_ | yes at home ;) not here | 10:00 |
| olofk | ahh | 10:01 |
| _franck_ | you just need to follow what's the Linux driver probe does | 10:06 |
| wallento | anybody also experiencing problems with sourceware? | 10:14 |
| poke53282 | blueCmd: Yesterday I tried to fight through your signal changes. It is hard. | 10:37 |
| poke53282 | The changes to mmap, tls and atomic kernel calls are more or less clear. | 10:38 |
| olofk | wallento: I can access the web page at least | 10:40 |
| wallento | me too now, but the git is very unstable the last days.. | 10:42 |
| olofk | Probably someone sent too many newlib patches and it crashed | 10:43 |
| stekern | olofk: without franks patch, you feed the config via the kernel command line | 10:51 |
| stekern | and the hack I used for atlys to determine the clock freq was based on the V and H params | 10:52 |
| _franck_ | stekern: (cmd line) ah you're right, I forgot that | 10:52 |
| stekern | http://git.openrisc.net/cgit.cgi/stefan/orpsoc/tree/boards/xilinx/atlys/rtl/verilog/dvi_gen/dvi_gen_top.v#n131 | 10:53 |
| stekern | that whole case ({hlen, vlen}) was (auto)generated from the kernels fbmodes | 10:54 |
| olofk | stekern: I also saw somewhere that you're sniffing the wishbone bus to find out some values for hsync/vsync. Now that's a hack | 10:55 |
| stekern | that's cleaner than hacking up the vga_lcd core to expose the values at least ;) | 10:56 |
| olofk | But if I just want a 640x480 @ 60Hz, I would be fine with a ~25MHz clock, right? | 10:57 |
| olofk | How accurate do I have to be? | 10:57 |
| stekern | it depends on your monitor | 10:57 |
| olofk | To make it more fun, my FPGA has a 30.72MHz input clock :) | 10:59 |
| olofk | hmm.. how are the values calculate? | 11:03 |
| wallento | stekern: is this musl cross scripts repository the way to build the musl cross-compiler? | 11:29 |
| olofk | wallento: Haven't you looked at the build instructions on the OpenCores wiki? | 11:29 |
| wallento | oh, sorry, for some reason I assumed there is no up-to-date info there ;) | 11:30 |
| wallento | thanks for pointing this out :) | 11:31 |
| wallento | I will add automated builds for this also | 11:31 |
| wallento | once sourceware git is operating again | 11:31 |
| olofk | I spent most of the weekend updating old crap, so now you better start using it! | 11:31 |
| wallento | yes, sir | 11:32 |
| poke53282 | olofk: I looked at the description to the musl toolchain. | 12:27 |
| poke53282 | Shoudln't we directly link to musl-cross on stekerns github page? | 12:28 |
| poke53282 | Otherwise great work. | 12:29 |
| poke53282 | Let's see how far I get with alpine Linux. | 12:30 |
| stekern | no, but you should probably use the one that I pasted | 12:39 |
| stekern | https://github.com/sabotage-linux/musl-cross | 12:39 |
| poke53282 | This branch is 10 commits behind GregorR:master | 12:46 |
| poke53282 | And the musl-cross GregorR is newer and contains your patches too. | 12:47 |
| stekern | ah, ok | 12:47 |
| poke53282 | So I wouldn't take the one from musl-cross | 12:48 |
| stekern | mine is either case behind both of them | 12:48 |
| olofk | Yes, gregorR seems to be back and has the latest updates | 12:56 |
| olofk | I thought it would be easier to just have the or1k additions as a simple patch rather than cloning the repo and having to keep that updated | 12:56 |
| poke53282 | Ok | 12:57 |
| poke53282 | Yes, probably that's easier. | 12:57 |
| poke53282 | for us | 12:57 |
| olofk | I guess the cleanest solution would be to let build.sh take a parameter to an extra config file with overrides | 12:57 |
| poke53282 | Yes, something like "./build.sh or1k" | 12:59 |
| poke53282 | and config.sh has a table with variables for each architecture. | 12:59 |
| poke53282 | olofk: You should also add git to the prerequisites | 13:01 |
| poke53282 | I don't think, this is the default. | 13:02 |
| olofk | poke53282: Good idea | 13:02 |
| poke53282 | I guess "wget" is a standard tool in Debian systems and is installed by default. | 13:04 |
| poke53282 | I have seen other distributions, in which this isn't installed as default. | 13:05 |
| olofk | Yeah, others might use curl for example | 13:15 |
| poke53282 | Yes | 13:20 |
| poke53282 | In principle I have seen also other prerequisites. For example the linux kernel uses bc to calculated some constants, when you change some internal parameters. Like the number of ticks per second. | 13:21 |
| olofk | haha. I didn't know that | 13:21 |
| poke53282 | Ok, that's rare. | 13:21 |
| olofk | I should send a patch to use matlab instead of bc | 13:22 |
| olofk | So we don't have to install bc | 13:22 |
| olofk | It's so bloated | 13:22 |
| poke53282 | jor1k runs with 50 ticks per second and not with 100 , so that browsers can benefit from longer idle times. | 13:22 |
| poke53282 | :) | 13:23 |
| poke53282 | Therefore I know. | 13:23 |
| poke53282 | a | 13:27 |
| poke53282 | https://www.kernel.org/doc/Documentation/Changes | 13:27 |
| poke53282 | It is written here. You need gcc, make, binutils, perl, bc | 13:27 |
| poke53282 | I just want to say, that the programs, which are installed by default might change over time. So we might want to add wget, bc, and perl to the list of prerequisites | 13:31 |
| olofk | I agree | 13:44 |
| blueCmd_ | poke53282: atomic kernel calls can be scrapped | 14:04 |
| blueCmd_ | poke53282: as for signaling changes, I *think* I know what you're talking about, and if so it's actually a patch from jonas branch | 14:04 |
| poke53282 | At the moment the questions are more general. Not necessary about your patches. | 14:13 |
| poke53282 | I have only a slight idea about, how signals work. Especially the stack handling. And you commented, that some feature is missing. | 14:14 |
| poke53282 | The atomic kernel kernel is already separated from the other changes in my repository. | 14:14 |
| poke53282 | So, it thought already to scrap it, especially after the implementation of lwa and swa. | 14:15 |
| poke53282 | I hoped that an error, which I encountered had to do with your signal handling. But it doesn't look like. | 14:17 |
| poke53282 | The cpu sends a EXCP_DPF, which should never in the user mode emulation. | 14:17 |
| poke53282 | ... never happen ... | 14:18 |
| poke53282 | it seems only for segmentation faults | 14:22 |
| poke53282 | arghh found it. Busybox bug. | 16:33 |
| stekern | poke53282: isn't the signaling thing the thing that you found? | 16:34 |
| stekern | or are you speaking about something else? | 16:34 |
| poke53282 | yes, but this was in the kernel, not in QEMU | 16:34 |
| stekern | ah, you are sepaking about qemu patches, now I'm back in the game | 16:35 |
| stekern | but either way, let's drop the atomic syscall patches in all instances | 16:36 |
| poke53282 | Yes, done | 16:37 |
| poke53282 | Project for this week: | 16:37 |
| poke53282 | 1. make sense outof blueCmd's patches | 16:37 |
| poke53282 | 2. finish the rebasing of QEMU | 16:37 |
| poke53282 | 3. fix a few minor problems in the QEMU patches. | 16:37 |
| poke53282 | 4. Try to compile gcc in the qemu user mode emulation. | 16:38 |
| poke53282 | 5. Run the gcc testsuite | 16:38 |
| stekern | sounds like a great plan | 16:38 |
| poke53282 | 6. Try to port alpine linux | 16:38 |
| poke53282 | That's it | 16:39 |
| poke53282 | I am still stuck with No. 1 | 16:39 |
| blueCmd_ | AFAIK number 5 will not work since QEMU is not threaded | 16:47 |
| blueCmd_ | multithreaded software (IIRC) is highly unstable | 16:47 |
| blueCmd_ | you might get "good enough" results, but you will have weird failures | 16:48 |
| poke53282 | well, I already run the testsuite with qemu-user mode. The result, which I link now and then is based on this. | 16:50 |
| poke53282 | What I want to do is, to run it completely in the chroot environment. | 16:51 |
| poke53282 | blueCmd: There has been a lot of bugs fixed in QEMU since one year ago. | 16:51 |
| poke53282 | Bugs, which were not directly related to Openrisc, but to the general user mode emulation. | 16:52 |
| blueCmd_ | right, but user-mode has never been able to support pthreads | 17:01 |
| blueCmd_ | might be enough for GCC, doubtful if it will work for the C++ stuff | 17:02 |
| poke53282 | might be | 17:06 |
| olofk | blueCmd_: Not enough for compiling or running c++? Because the gcc code contains c++ nowadays, right? | 17:57 |
| olofk | So we need to be able to compile c++ if that's the case | 17:58 |
| poke53282 | compiling c++ should work | 18:46 |
| poke53282 | I have to take a look about threads. This is indeed interesting. | 18:46 |
| poke53282 | From the wiki: QEMU is also able to run multiple threads in user-mode emulation mode | 18:48 |
| poke53282 | But it might not be enabled for openrisc. | 18:48 |
| poke53282 | make -j xxx wil work anyhow. | 18:48 |
| blueCmd_ | poke53282: so, AFAIK it works as long as it's fork/join kind of things | 19:07 |
| blueCmd_ | poke53282: QEMU does threading by classic copy-everything IIRC | 19:08 |
| blueCmd_ | so you will not be able to do stuff like all the fancy pthreads stuff and share memory between threads | 19:08 |
| poke53282 | Hmm, good to know. | 19:16 |
| olofk | Who uses multiple threads anyway? The trend is to have a single extremely big and fast CPU | 19:30 |
| poke53282 | The same is true for binary. The trend is going to decimal with the BCD opcodes. Finally a number basis, everyone understands. | 19:45 |
| poke53282 | The x86 has already support for it. When does OpenRISC catch up? | 19:48 |
| olofk | :) | 20:08 |
| stekern | I actually had to do software bcd conversion last week | 20:11 |
| stekern | so I vote for l.bcd2bin and l.bin2bcd opcodes | 20:11 |
| poke53282 | Agree | 20:15 |
| varun_ | hey is openrisc.net down? | 20:20 |
| -!- varun_ is now known as Guest68775 | 20:21 | |
| Guest68775 | hey is openrisc.net down? | 20:21 |
| stekern | looks like it, it worked earlier today though | 20:24 |
| Guest68775 | is there any alternate source from where i could download linux for openrisc? | 20:26 |
| poke53282 | stekerns and my hard drive I guess. | 20:38 |
| poke53282 | Uploading would take probably 3 hours for me. | 20:39 |
| poke53282 | Are the official kernel sources not sufficient? | 20:39 |
| poke53282 | I mean kernel.org | 20:40 |
| stekern | Guest68775: while openrisc.net is down, I pushed the branch I'm working on here: https://github.com/skristiansson/linux/tree/openrisc | 20:50 |
| --- Log closed Tue Jan 27 00:00:15 2015 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!