IRC logs for #openrisc Monday, 2015-01-26

--- 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 registers09:23
_franck_but yes, resolution is just a matter of software configuration09:23
olofk_franck_: Ah cool. Thanks.09:23
_franck_and clock speed09:23
olofkPerfect! So there aren't any `defines I need to setup09:25
_franck_AFAIR: no09:25
olofk_franck_: How do I configure ocfb from Linux?09:34
_franck_you need to hack this:
_franck_I have a patch ready to configure the fb from the device tree:
olofkAnd what will the default values be without that patch?09:37
_franck_640x480 @ 60 Hz, 31.5 kHz hsync09:38
olofkDoes it pick up the clock frequency automatically?09:39
_franck_it doesn't know about clock frequ09:40
_franck_you just tell it09: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 care09:41
olofkHow 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 them09:42
_franck_the driver does not need to knwo at which clock rate pixels are going to be read09:43
olofkTrue, but I need to set my DVI clock to something09:43
_franck_you have to figure out what clock you need to put here09:45
_franck_in vga, you get frame rate and pixels and you compute pixel rate09:45
_franck_stekern: did use DVI on the atlys board I think, you can look at that09:46
olofkI found a comment in the sockit clkgen.v that sets it to 25.2MHz09:46
olofkSeems like atlys sets it to 50MHz. That seems consistent with what I want to do09:47
olofkWill it generate the sync stuff even if I haven't connected the wb interface? So I can see if the monitor detects anything09:51
_franck_No, you have to write things to registers to start the controller09:56
_franck_I didn't that with openocd while I was testing it09:57
olofkThat's a good idea09:57
olofkI love OpenOCD more and more09:57
olofkDo you have any scripts or notes or something I can use to get started?09:58
_franck_yes at home ;) not here10:00
_franck_you just need to follow what's the Linux driver probe does10:06
wallentoanybody also experiencing problems with sourceware?10:14
poke53282blueCmd: Yesterday I tried to fight through your signal changes. It is hard.10:37
poke53282The changes to mmap, tls and atomic kernel calls are more or less clear.10:38
olofkwallento: I can access the web page at least10:40
wallentome too now, but the git is very unstable the last days..10:42
olofkProbably someone sent too many newlib patches and it crashed10:43
stekernolofk: without franks patch, you feed the config via the kernel command line10:51
stekernand the hack I used for atlys to determine the clock freq was based on the V and H params10:52
_franck_stekern: (cmd line) ah you're right, I forgot that10:52
stekernthat whole case ({hlen, vlen}) was (auto)generated from the kernels fbmodes10:54
olofkstekern: I also saw somewhere that you're sniffing the wishbone bus to find out some values for hsync/vsync. Now that's a hack10:55
stekernthat's cleaner than hacking up the vga_lcd core to expose the values at least ;)10:56
olofkBut if I just want a 640x480 @ 60Hz, I would be fine with a ~25MHz clock, right?10:57
olofkHow accurate do I have to be?10:57
stekernit depends on your monitor10:57
olofkTo make it more fun, my FPGA has a 30.72MHz input clock :)10:59
olofkhmm.. how are the values calculate?11:03
wallentostekern: is this musl cross scripts repository the way to build the musl cross-compiler?11:29
olofkwallento: Haven't you looked at the build instructions on the OpenCores wiki?11:29
wallentooh, sorry, for some reason I assumed there is no up-to-date info there ;)11:30
wallentothanks for pointing this out :)11:31
wallentoI will add automated builds for this also11:31
wallentoonce sourceware git is operating again11:31
olofkI spent most of the weekend updating old crap, so now you better start using it!11:31
wallentoyes, sir11:32
poke53282olofk: I looked at the description to the musl toolchain.12:27
poke53282Shoudln't we directly link to musl-cross on stekerns github page?12:28
poke53282Otherwise great work.12:29
poke53282Let's see how far I get with alpine Linux.12:30
stekernno, but you should probably use the one that I pasted12:39
poke53282This branch is 10 commits behind GregorR:master12:46
poke53282And the musl-cross GregorR is newer and contains your patches too.12:47
stekernah, ok12:47
poke53282So I wouldn't take the one from musl-cross12:48
stekernmine is either case behind both of them12:48
olofkYes, gregorR seems to be back and has the latest updates12:56
olofkI 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 updated12:56
poke53282Yes, probably that's easier.12:57
poke53282for us12:57
olofkI guess the cleanest solution would be to let take a parameter to an extra config file with overrides12:57
poke53282Yes, something like "./ or1k"12:59
poke53282and has a table with variables for each architecture.12:59
poke53282olofk: You should also add git to the prerequisites13:01
poke53282I don't think, this is the default.13:02
olofkpoke53282: Good idea13:02
poke53282I guess "wget" is a standard tool in Debian systems and is installed by default.13:04
poke53282I have seen other distributions, in which this isn't installed as default.13:05
olofkYeah, others might use curl for example13:15
poke53282In 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
olofkhaha. I didn't know that13:21
poke53282Ok, that's rare.13:21
olofkI should send a patch to use matlab instead of bc13:22
olofkSo we don't have to install bc13:22
olofkIt's so bloated13:22
poke53282jor1k runs with 50 ticks per second and not with 100 , so that browsers can benefit from longer idle times.13:22
poke53282Therefore I know.13:23
poke53282It is written here. You need gcc, make, binutils, perl, bc13:27
poke53282I 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 prerequisites13:31
olofkI agree13:44
blueCmd_poke53282: atomic kernel calls can be scrapped14: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 branch14:04
poke53282At the moment the questions are more general. Not necessary about your patches.14:13
poke53282I have only a slight idea about, how signals work. Especially the stack handling. And you commented, that some feature is missing.14:14
poke53282The atomic kernel kernel is already separated from the other changes in my repository.14:14
poke53282So, it thought already to scrap it, especially after the implementation of lwa and swa.14:15
poke53282I hoped that an error, which I encountered had to do with your signal handling. But it doesn't look like.14:17
poke53282The cpu sends a EXCP_DPF, which should never in the user mode emulation.14:17
poke53282... never happen ...14:18
poke53282it seems only for segmentation faults14:22
poke53282arghh found it. Busybox bug.16:33
stekernpoke53282: isn't the signaling thing the thing that you found?16:34
stekernor are you speaking about something else?16:34
poke53282yes, but this was in the kernel, not in QEMU16:34
stekernah, you are sepaking about qemu patches, now I'm back in the game16:35
stekernbut either way, let's drop the atomic syscall patches in all instances16:36
poke53282Yes, done16:37
poke53282Project for this week:16:37
poke532821. make sense outof blueCmd's patches16:37
poke532822. finish the rebasing of QEMU16:37
poke532823. fix a few minor problems in the QEMU patches.16:37
poke532824. Try to compile gcc in the qemu user mode emulation.16:38
poke532825. Run the gcc testsuite16:38
stekernsounds like a great plan16:38
poke532826. Try to port alpine linux16:38
poke53282That's it16:39
poke53282I am still stuck with No. 116:39
blueCmd_AFAIK number 5 will not work since QEMU is not threaded16:47
blueCmd_multithreaded software (IIRC) is highly unstable16:47
blueCmd_you might get "good enough" results, but you will have weird failures16:48
poke53282well, I already run the testsuite with qemu-user mode. The result, which I link now and then is based on this.16:50
poke53282What I want to do is, to run it completely in the chroot environment.16:51
poke53282blueCmd: There has been a lot of bugs fixed in QEMU since one year ago.16:51
poke53282Bugs, 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 pthreads17:01
blueCmd_might be enough for GCC, doubtful if it will work for the C++ stuff17:02
poke53282might be17:06
olofkblueCmd_: Not enough for compiling or running c++? Because the gcc code contains c++ nowadays, right?17:57
olofkSo we need to be able to compile c++ if that's the case17:58
poke53282compiling c++ should work18:46
poke53282I have to take a look about threads. This is indeed interesting.18:46
poke53282From the wiki:  QEMU is also able to run multiple threads in user-mode emulation mode18:48
poke53282But it might not be enabled for openrisc.18:48
poke53282make -j xxx wil work anyhow.18:48
blueCmd_poke53282: so, AFAIK it works as long as it's fork/join kind of things19:07
blueCmd_poke53282: QEMU does threading by classic copy-everything IIRC19:08
blueCmd_so you will not be able to do stuff like all the fancy pthreads stuff and share memory between threads19:08
poke53282Hmm, good to know.19:16
olofkWho uses multiple threads anyway? The trend is to have a single extremely big and fast CPU19:30
poke53282The same is true for binary. The trend is going to decimal with the BCD opcodes. Finally a number basis, everyone understands.19:45
poke53282The x86 has already support for it. When does OpenRISC catch up?19:48
stekernI actually had to do software bcd conversion last week20:11
stekernso I vote for l.bcd2bin and l.bin2bcd opcodes20:11
varun_hey is down?20:20
-!- varun_ is now known as Guest6877520:21
Guest68775hey is down?20:21
stekernlooks like it, it worked earlier today though20:24
Guest68775is there any alternate source from where i could download linux for openrisc?20:26
poke53282stekerns and my hard drive I guess.20:38
poke53282Uploading would take probably 3 hours for me.20:39
poke53282Are the official kernel sources not sufficient?20:39
poke53282I mean kernel.org20:40
stekernGuest68775: while is down, I pushed the branch I'm working on here:
--- Log closed Tue Jan 27 00:00:15 2015

Generated by 2.15.2 by Marius Gedminas - find it at!