| --- Log opened Wed Apr 15 00:00:07 2015 | ||
| olofk | stekern: Thanks. Maybe I should have made sure to understand the spec before I started coding, but on the other hand it turned out to be a good learning experience | 05:23 |
|---|---|---|
| olofk | And I would very much like to update some parts of the wishbone spec | 05:24 |
| stekern | reading before starting to code? never heard of that ;) | 05:29 |
| stekern | olofk: since you were so fond of my veroboard pr0n, here's some more: http://1drv.ms/1b1YQ17 | 05:30 |
| stekern | only atari joystick connectors missing | 05:31 |
| stekern | some things works too: http://1drv.ms/1CWCJis | 05:32 |
| stekern | the mor1kx I added to the build is 300 LUTs smaller (2400 vs 2700) than the or1200 that was there | 05:33 |
| stekern | and I have icache enabled on the mor1kx, it's not enabled on the or1200 | 05:34 |
| stekern | still a bunch of stuff that can be disabled in the mor1kx I have there too, like addc and range/overflow | 05:35 |
| stekern | I had some weird problems with the PS/2 connections, one pin on the de0 nano GPIO1 pin header is pulling down the signal for some reason | 05:37 |
| stekern | and I had a similar problem with the audio output, the left channel volume was a lot lower than the right, and when I measured the pins with a scope without the RC filter, the left pin high level was something like < 1V | 05:40 |
| stekern | and exact the same pin settings in quartus | 05:40 |
| stekern | I suspect some PCB problem, but I just moved over to use some other pins instead of the problematic ones | 05:41 |
| stekern | actually, it was the right channel that was lower than the left. Not that it matters ;) | 05:42 |
| olofk | Cool! | 06:27 |
| olofk | stekern: Maybe your nano is tired of you performing experiments on it? :) | 06:31 |
| olofk | stekern: What is the build system like for minimig? I could take a look at FuseSoCify it if you haven't done that yourself | 06:35 |
| stekern | olofk: it's just Makefile based | 06:47 |
| stekern | https://github.com/skristiansson/minimig-de1/blob/master/Makefile | 06:47 |
| wallento | hey guys, please review those for upstream: https://github.com/openrisc/newlib/tree/for-upstream | 06:54 |
| dalias | stekern, no problems with new stuff in musl still? | 06:54 |
| olofk | wallento: I looked at the patches and realized I don't understand enough to review. Sorry | 06:57 |
| stekern | dalias: not that I have noticed, I haven't got around to do any elaborate testing though | 07:02 |
| olofk | Hesham: I haven't looked into HTIF. What is it? | 08:10 |
| olofk | And if you want to have Wishbone over ethernet, there is etherbone. It's included in the Linux kernel | 08:11 |
| Hesham | It's how RISCV SoCs communicate with the host machine | 08:11 |
| Hesham | Host Target Interface.. | 08:11 |
| olofk | hmm... when is that used? | 08:11 |
| Hesham | Every time I think. It's how the Linux port communicate with FPGA now. | 08:12 |
| Hesham | For console output and debugging | 08:12 |
| Hesham | And uploading binaries ... | 08:13 |
| Hesham | I've seen htif_rs232 (used by frontend server) variant but don't know if it has been already used. | 08:14 |
| Hesham | Anyway, I'm going to write a simple serial driver to load some data to RTEMS using USB-UART. If it works I'll move to loading binaries on fusesoc using this driver. | 08:16 |
| olofk | Hesham: Hmm.. so you basically have Host computer <-> Ethernet <-> HTIF <-> Target system? | 08:18 |
| Hesham | olofk: I am not sure, but I think the Ethernet can be any other sort of communication channel like rs232 | 08:19 |
| olofk | Hesham: Yeah. Something to load binaries through UART would be great. I think the zmodem protocol or just passing SREC/Intel Hex files would be the best option | 08:19 |
| olofk | Hesham: It sounds like the Ethernet/UART <-> HTIF conversion might use up a lot of FPGA logic | 08:20 |
| Hesham | Why SREC format? Can't it just be a raw binary? | 08:20 |
| Hesham | If UART <-> HTIF hardware logic is not already there, I may think of implementing it, depending on the amount of effort. | 08:21 |
| olofk | The problems with binaries is that UART controller might interpret some data as control characters | 08:21 |
| olofk | UARTs are messy | 08:22 |
| olofk | But it might work just fine. Maybe this is just problems with legacy systems | 08:22 |
| _franck__ | Hesham: if you parse SREC or Intel Hex you can have offsets for datas embedded in the file | 08:22 |
| Hesham | I think it's the only good option at least on my Atlys board | 08:24 |
| olofk | Hesham: I think it should be pretty easy to do a Hex loader in C. There are probably a few already available | 08:25 |
| Hesham | _franck_ I will give it a look if the driver worked fine with RTEMS. | 08:25 |
| olofk | I started doing mine in asm because I wanted to have it as an initial bootloader to be embedded in a Block RAM. That requires that it's really tiny | 08:25 |
| Hesham | olofk: So you will put the bootloader on the BRAM and make the core jump by default to it? | 08:26 |
| olofk | Hesham: Exactly | 08:28 |
| bandvig | olofk: Does kermit protocol solve problem with UART control characters? I used "Kermit" with u-boot for loading binaries through UART. | 08:28 |
| olofk | kermit and zmodem are similar | 08:28 |
| olofk | According to the zmodem spec it is intended to solve some issues with kermit | 08:28 |
| Hesham | olofk: To make it easy, I'll write both drivers (Host Side + RTEMS/Target side) first, then see the RTEMS driver can be ported to FuseSoC BRAM | 08:29 |
| Hesham | I can't download kermit, the download links are broken | 08:29 |
| olofk | Hesham: Cool. Do you have a feeling for how large it is? Ideally we would like to embed u-boot directly, but that's far too big | 08:29 |
| Hesham | olofk: Not yet, I'll have to get the feeling by doing it today :) | 08:30 |
| olofk | bandvig: And yes. Kermit, xmodem, ymodem and zmodem are all protocols to work around control character problems among other things | 08:30 |
| Hesham | But yes, why can't we use kermit and zmodem? | 08:30 |
| olofk | stekern proposed zmodem. I just figured that my crappy asm skills wouldn't be enough to implement it | 08:31 |
| Hesham | olofk: You mean from OpenRISC side? | 08:33 |
| olofk | Hesham: Yes. Whether we go for zmodem/kermit or a hex loader, someone must implement the loader on the OpenRISC side | 08:33 |
| Hesham | I see. I'll let you know about any good progress I make regarding this bootloader issue. | 08:35 |
| olofk | Hesham: Cool. I'm very interested in this, so let me know how things proceed and what you find out | 08:35 |
| bandvig | Guys, really for me it looks like that you are trynig to implement minimum version of u-boot. Perhaps, it is easier just to reconfigure the u-boot with minimal set of features and fix issues on both sides (host PC / target). Am I wrong? | 08:39 |
| olofk | bandvig: Yes. That would be ideal as we don't really want to maintain any unnecessary code | 08:41 |
| olofk | Problem is that I haven't been able to make u-boot small enough. I can only get it down to ~100kB | 08:42 |
| olofk | We need to make it like at most 32kB. Preferrably something like 4kB | 08:43 |
| olofk | I forgot to mention that u-boot has also recognized this problem and created something called SPL, which is a tiny bootloader intended to load a full u-boot (basically what our SPI bootloader does) | 08:45 |
| olofk | That could be worth investigating | 08:47 |
| bandvig | olofk: investigating what? SPL? If the SPL is small enough and open sourced, perhaps it is a good solution. | 08:49 |
| olofk | Just search for uboot spl | 08:51 |
| bandvig | olofk: Ah, uderstood. | 08:57 |
| wallento | olofk: np | 09:09 |
| wallento | does anybody have a clue where in binutils I can properly set the byte 0x20 (format) in objects created by objcopy? | 09:10 |
| wallento | eh, 0x13 | 09:19 |
| olofk | wallento: Is that the old bug for which you had a small python hack? | 09:36 |
| stekern | wallento: is it this you are speaking about? https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=include/elf/common.h;h=25cfef2d6b1ae8e3f976f1e55576d0fbaff79027;hb=HEAD#l196 | 09:57 |
| olofk | Haha. I was just reading some x86 asm and caught myself looking at the instructions after each jump. Forgot that not all CPUs use branch delay slots :) | 10:52 |
| ysionneau | ahah | 10:53 |
| wallento | olofk: yes, I have a bash hack now also: bash -c "printf '\x5c' | dd conv=notrunc of=$BINARY bs=1 seek=$((0x13)) 2> /dev/null" | 11:04 |
| wallento | stekern: yes, that is what should be there | 11:04 |
| wallento | but it isn't | 11:04 |
| olofk | wallento: You should make a matlab version too, and port it to Ruby on Rails perhaps | 11:04 |
| olofk | Make an Android app to while your at it and launch a cloud service called objcopify | 11:06 |
| olofk | I should probably work more :( | 11:06 |
| stekern | wallento: what do you mean "it's not there"? | 11:18 |
| stekern | it's there in the elf I just built | 11:19 |
| wallento | no, I mean in objcopy | 11:19 |
| wallento | If I generate an object from binary data | 11:19 |
| stekern | ah | 11:19 |
| wallento | then it has no architecture set | 11:20 |
| stekern | ok, but that's a generic objcopy problem then, right? | 11:20 |
| wallento | I dont' know | 11:21 |
| wallento | will check this | 11:21 |
| wallento | ahh, found it | 11:23 |
| wallento | sorry to bother | 11:23 |
| wallento | it is required to set the architecture | 11:24 |
| wallento | even if -O elf32_or1k is used it is required to set -B or1k when using -I binary | 11:24 |
| wallento | which is confusing, but that solved my oldest "bug" | 11:25 |
| ysionneau | the input file had an explicit architecture? | 11:25 |
| wallento | nope, its plain binary | 11:53 |
| wallento | I assumed that the output architecture is set by -O elf32-or1k | 11:53 |
| wallento | and -B is only necessary for other architecture-independent formats | 11:53 |
| ysionneau | ah ok | 12:02 |
| olofk | wallento: Does this mean you will update bugzilla? :) | 12:24 |
| bandvig | olofk: Is it a bug or feature? :) | 12:49 |
| olofk | bandvig: Hard to say. Maybe we need a featurezilla as well :) | 13:18 |
| bandvig | olofk: with comments like "works as designed" :) | 13:41 |
| wallento | ah, this bugzilla-thing | 14:31 |
| wallento | yes | 14:31 |
| wallento | btw. there is one patch in the newlib branch that should solve your uart issues | 14:31 |
| stekern | this is starting to become frustrating, I've searched high and low but can't find how you enable the internal pull-ups on cyclone iv devices with quartus | 16:52 |
| stekern | this claims you *can*, but I can't find anywhere that it would say *how*: https://www.altera.com/en_US/pdfs/literature/hb/cyclone-iv/cyclone4-handbook.pdf | 16:53 |
| olofk | set_instance_assignment -name PASSIVE_RESISTOR "PULL-DOWN" -to | 16:56 |
| olofk | ? | 16:56 |
| olofk | There seems to be a WEAK_PULLUP keyword as well | 16:58 |
| olofk | I recognize the last one | 17:00 |
| olofk | But I'm not sure anymore. Can't find any definitive answers either, and I know too that I have done that | 17:05 |
| stekern | well, that's at least something I can try | 17:21 |
| stekern | "This option is used in functional simulations only." for PASSIVE_RESISTOR | 17:26 |
| stekern | today alteraforum.com doesn't have a broken database like yesterday at least, that's where most of my google efforts yesterday pointed to | 17:28 |
| stekern | set_instance_assignment -name WEAK_PULL_UP_RESISTOR ON -to | 17:37 |
| olofk | stekern: Ah. I saw that one, but thought it was something else | 18:07 |
| olofk | Altera apparently aren't very good at building websites. I have problems connecting to alterawiki all the time | 18:07 |
| olofk | Hmm.. there's no instruction to set a word in memory to a constant value without first putting it in a register | 18:36 |
| olofk | Whose stupid idea was it to write a hex loader in assembler? | 18:40 |
| olofk | And what's going on with FuseSoC...? It doesn't recognize --elf-load for mor1kx-generic | 18:49 |
| olofk | Whoops. There wasn't any dependency on elf-loader | 18:52 |
| stekern | oh lord... I so need this game: http://www.johannesrojola.com/msc/index.html#media | 19:54 |
| olofk | haha | 20:09 |
| olofk | I love the homepage too | 20:10 |
| stekern | it's simply brilliant | 20:10 |
| olofk | Couldn't find any <blink> tags in the source | 20:10 |
| olofk | I wonder what the requirements for the games are. My guess is 486DX2, 16MB RAM, VESA adapter and 16-bit sound card | 20:12 |
| stekern | huh? did you watch the video? | 20:15 |
| olofk | Just meant that the homepage took me back to 1997 | 20:17 |
| olofk | I did look a bit at the video now. Not all 51 minutes though :) | 20:18 |
| stekern | there's a slight offset of the quality of the game graphics and the quality of the web page design ;) | 20:18 |
| --- Log closed Thu Apr 16 00:00:09 2015 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!