| --- Log opened Tue Sep 09 00:00:44 2014 | ||
| stekern | poke53281: a link you pasted some while ago got me interested in getting 8086tiny running on openrisc | 03:14 |
|---|---|---|
| stekern | ...wow, that codebase must make a record in making assumptions about endianness | 03:15 |
| stekern | I might still go through with "porting" it to big-endian, just because of the challenge ;) | 03:16 |
| poke53281 | I wrote it in the musl chat :) | 03:31 |
| poke53281 | I hope you try the unobfuscated version. | 03:32 |
| poke53281 | dosbox is maybe better. | 03:33 |
| poke53281 | a whole x86 emulator in 4043 bytes. This is still so amazing. It runs DOS, Windows, and some games. | 03:35 |
| poke53281 | I tried to understand the code. Now I understand it, but it's still amazing. | 03:35 |
| poke53281 | Don't be surprised, but I have a Javascript version of 8ß86tiny. | 03:36 |
| poke53281 | This was my way to understand the code. | 03:36 |
| -!- Netsplit *.net <-> *.split quits: mboehnert | 03:38 | |
| -!- Netsplit *.net <-> *.split quits: _franck_, jonmasters, ams, rah, trevorman, knz, FreezingCold, fotis | 03:40 | |
| stekern | poke53281: =) does your version make as much assumptions? | 03:41 |
| -!- Netsplit over, joins: mboehnert | 03:42 | |
| -!- Netsplit over, joins: FreezingCold | 03:43 | |
| poke53281 | Yes, I think so. But I had to get rid of all those defines | 03:44 |
| poke53281 | Javascrpt is little endian | 03:48 |
| stekern | mmm | 03:55 |
| stekern | you got rid of the defines, I add more of them ;) | 03:55 |
| poke53281 | Javascript doesn't have a precompiler. | 03:57 |
| stekern | basically all the *((int16_t *)&some_char_buff) needs to use wrappers that takes care of endianness and alignment | 03:58 |
| stekern | if done right, the wrappers could evaluate to a nop on targets that doesn't need them | 04:02 |
| poke53281 | for my emulator the fastest way was to swap the 32-bit words. But this makes only sense, when all accesses are aligned. | 04:04 |
| poke53281 | the preprocessor is implemented in a very interesting way. | 04:05 |
| poke53281 | This OP is extremely powerful, but also hard to understand. | 04:05 |
| poke53281 | the way, the emulator treats registers and ram in the same way is made by a genius. | 04:06 |
| stekern | but all accesses aren't aligned | 04:12 |
| poke53281 | Yes | 04:13 |
| stekern | https://github.com/adriancable/8086tiny/blob/master/8086tiny.c#L308 | 04:13 |
| stekern | for instance | 04:13 |
| poke53281 | http://simulationcorner.net/8086tiny/8086tiny.html | 04:20 |
| poke53281 | Does not work at the moment. | 04:20 |
| poke53281 | Now I remember. Yes, I change all 16 Bit accesses to return mem[offset] | (mem[offset+1]<<8); | 04:24 |
| stekern | poke53281: since you've dissected the macros, maybe you can help me see what I'm missing here | 05:30 |
| stekern | why aren't these equivalent?: http://pastie.org/9538085 | 05:30 |
| stekern | the place in the original code is here: https://github.com/adriancable/8086tiny/blob/master/8086tiny.c#L131 | 05:30 |
| stekern | ah, the cast to (unsigned short)... maybe... | 05:31 |
| poke53281 | :) The macros are kind of obfuscated. Each tiny little bit is important here. | 05:34 |
| poke53281 | http://pastie.org/9538103 | 05:37 |
| poke53281 | this are the unobfuscated versions | 05:37 |
| stekern | I don't see how the 'obfuscated' version becomes regs16[REG_SP] -= 2 | 05:41 |
| poke53281 | hehe | 05:42 |
| poke53281 | I think the variable is too times subtracted by one | 05:42 |
| poke53281 | at two different positions. Because you use the variable two times | 05:42 |
| poke53281 | "dest" is used two times in the macro | 05:45 |
| poke53281 | http://pastie.org/9538117 | 05:48 |
| stekern | ah, in the R_M_OP macro | 05:48 |
| poke53281 | yes | 05:48 |
| poke53281 | It's crazy efficient written. | 05:48 |
| stekern | crazy, at least ;) | 05:49 |
| poke53281 | These macros can be used for registers as well. | 05:50 |
| poke53281 | but registers are just as fixed memory positions | 05:50 |
| poke53281 | the first 8086 had 29000 transistors. That means, that even the ISA of the x86 must have some inherent logic to build such a complex ISA with 29000 transistors | 05:52 |
| poke53281 | And yes, there is some. | 05:53 |
| poke53281 | Not nice, but at least some logic. | 05:53 |
| stekern | poke53281: this is what I've come up with from your function: http://pastie.org/9538252 | 07:11 |
| stekern | at least it still works on x86_64 | 07:11 |
| stekern | I think it *might* be endian agnostic now | 07:11 |
| stekern | the CAST(unsigned short) might need changing still | 07:12 |
| stekern | the problem is that he makes advantage of how macros work and do things like #define M(x) CAST(unsigned short)x | 07:13 |
| stekern | and then use M like this: M(reg + 1 + 2 + 5) | 07:13 |
| stekern | which then evaluates to: *(unsigned short *)® + 1 + 2 + 5 | 07:15 |
| stekern | i.e. M((reg + 1 + 2 + 5))) would evaluate a completely different result | 07:17 |
| sb0 | is the PreserveAll LLVM calling convention correctly implemented for or1k, and what does it do? | 08:13 |
| sb0 | is there a calling convention with no callee-save registers, that can be used to implement low-overhead collaborative multithreading? | 08:18 |
| sb0 | hmm seems PreserveAll is actually the opposite of what I want | 08:19 |
| -!- rah_ is now known as rah | 09:03 | |
| -!- Netsplit *.net <-> *.split quits: f3ddischson, mboehnert2 | 12:01 | |
| -!- Netsplit over, joins: f3ddischson, mboehnert2 | 12:05 | |
| lauri | Olof is here? | 12:21 |
| ysionneau | he is olofk | 12:21 |
| lauri | Nice job with the presentation @ FPGAworld 2k14 | 12:21 |
| lauri | olofk: The guy with Debian T-shirt here ;) | 12:22 |
| edward__ | hi | 12:57 |
| edward__ | i'm trying to follow this http://opencores.org/or1k/ORCONF2013_Workshop_ORPSoC_On_DE0_Nano | 12:57 |
| edward__ | I can get up to having openocd connect to or1k and I can even load a binary, but nothing else happens | 12:58 |
| stekern | edward__: which binary? (to know what is expected to happen) | 13:01 |
| stekern | if you don't get uart output, try a led-blinker or something | 13:02 |
| edward__ | stekern: yep I tried the led-blinker binary on the page | 13:03 |
| edward__ | stekern: " timerled program, download it here: " | 13:03 |
| stekern | ok, and that doesn't work.. then it's trickier | 13:04 |
| edward__ | I also tried to build a fresh softcore image from https://github.com/openrisc/orpsoc-cores.git without any patches and no such luck | 13:05 |
| stekern | did you try with the pre-built fpga image? | 13:06 |
| edward__ | that was the first thing I tried | 13:06 |
| stekern | ok, "good" | 13:07 |
| edward__ | is that the newest repo? | 13:09 |
| edward__ | i've seen git://openrisc.net/stefan/orpsoc around also | 13:09 |
| stekern | that's old | 13:11 |
| edward__ | yep looks like it ok | 13:12 |
| stekern | you can try this: http://www.elec4fun.fr/downloads/led_blink.elf | 13:12 |
| edward__ | so yea, github.com/openrisc/orpsoc-cores should just work right | 13:12 |
| edward__ | ok 1sec | 13:12 |
| stekern | and load it with this: https://github.com/openrisc/or1k-tcltools | 13:12 |
| edward__ | stekern: ok that seemed to download fine but nothing is happening | 13:16 |
| edward__ | Loading section .text, size 0x0000015c lma 0x00000000 (100%) | 13:17 |
| stekern | hmm, something seems to be terribly wrong | 13:17 |
| edward__ | once I downloaded with that script do I need to do anything else? | 13:17 |
| stekern | no, it should run the binary (which should blink the leds) | 13:18 |
| edward__ | :< | 13:18 |
| edward__ | does quartus II do any sort of board diags? | 13:19 |
| stekern | is this a brand new board? and have you tested other designs on it? | 13:19 |
| edward__ | i've done simple things like a binary counter on it and it works fine | 13:20 |
| stekern | at this point I can't guess anything but that your board would be broken, or it's a new revision that's slightly different (SDRAM timings come to mind) | 13:21 |
| stekern | the prebuilt image has been known to work on several different boards, so it should be "good" | 13:22 |
| stekern | s/boards/de0 nano boards | 13:23 |
| stekern | if you go back to openocd | 13:23 |
| edward__ | yep binary counter still works | 13:24 |
| edward__ | let me just reflash with or1k | 13:24 |
| stekern | load the program and then do: mdw 0x100 | 13:24 |
| edward__ | the led_blink.elf ? | 13:25 |
| stekern | you can go back to the timer program | 13:26 |
| stekern | we just want to load the memory with something known and see if we can read it back with openocd | 13:26 |
| edward__ | > halt; mdw 0x100 | 13:27 |
| edward__ | target state: halted | 13:27 |
| edward__ | 0x00000100: 18000000 | 13:27 |
| stekern | ok, that looks good | 13:28 |
| stekern | you can confirm that it's what is in the program by; or1k-elf-objdump -D program | 13:28 |
| edward__ | hmm yes true but I need to get binutils compiled for this target, also I need to understand the memory map for it | 13:29 |
| stekern | 0x100 is the reset vector | 13:30 |
| edward__ | ah ok | 13:30 |
| stekern | but I can tell you that 18000000 == l.movhi r0,0x0, which is what you'd expect as the first instruction | 13:31 |
| stekern | so that looks good... | 13:31 |
| stekern | what happens if you do: | 13:32 |
| stekern | mwb 0x91000000 0xff | 13:32 |
| stekern | mwb 0x91000001 0xff | 13:32 |
| edward__ | all the leds light up | 13:33 |
| stekern | \o/ ... but :( that the program doesn't seem to run... | 13:33 |
| edward__ | I'm at a loss | 13:39 |
| edward__ | stekern: do those tcl scripts you linked me to put the program in non-volitile storage? | 13:40 |
| stekern | no, it loads it into SDRAM | 13:42 |
| edward__ | takes a really long time to flash the linux image, I presume because its SPI | 13:42 |
| edward__ | oh really!? | 13:42 |
| edward__ | why is it slower than openocd? | 13:43 |
| edward__ | I noticed it invocates quartus_stp | 13:43 |
| stekern | yes, it's not the most efficient way. I just wanted to try that to exclude any problems with openocd | 13:46 |
| edward__ | understood | 13:46 |
| edward__ | stekern: ever seen anyone with this kind of issue before? | 13:58 |
| stekern | not that I can remember | 14:01 |
| edward__ | stekern: so now I am wondering.. what board I should buy.. | 14:06 |
| edward__ | I wish the core was written in VHDL :/ | 14:08 |
| edward__ | stekern: do you happen to have NiosII images about with a working kernel? maybe see if that would work? | 14:14 |
| stekern | edward__: sorry, haven't ever tried NiosII on that board | 14:26 |
| stekern | but, it's weird, so far everything has indicated that it works like it should | 14:28 |
| stekern | except actually running the programs | 14:28 |
| _franck_ | edward__: remove your finger from the reset button ! ;) | 14:30 |
| stekern | heh | 14:30 |
| stekern | well, that you can actually try. load the mem and then press the reset button | 14:30 |
| edward__ | stekern: yep I tried that and even thought of the idea that maybe the button was broken ;) | 14:32 |
| edward__ | what about these dip switches, they are currently all down | 14:33 |
| _franck_ | what if you do mdw 0x100 64 ? To see other memory words (may be only 0x100 is valid) | 14:34 |
| edward__ | https://gist.github.com/anonymous/216d7082fc577ef80729 | 14:37 |
| edward__ | this is with the timerled program | 14:37 |
| _franck_ | looks good | 14:40 |
| stekern | actually, that timerled program doesn't seem to do anything on my board neither now... | 14:40 |
| stekern | bitrot! ;) | 14:40 |
| stekern | ah, now it works, after a 'reset' | 14:41 |
| edward__ | stekern: does timerled give any serial output also? | 14:57 |
| stekern | not sure, I don't think it does | 15:05 |
| edward__ | do you happen to have some simple program around to write some junk to the uart? | 15:06 |
| stekern | http://oompa.chokladfabriken.org/openrisc/hello_world | 15:08 |
| edward__ | great thanks! | 15:09 |
| edward__ | I give up, ram *must* be screwed | 15:22 |
| olofk | lauri: Thanks :) | 15:37 |
| olofk | stekern: You needed something that could push data from wishbone to a fifo interface, right? | 16:14 |
| olofk | Does it matter for your application if the core is a master that can pull data from a memory area by itself? | 16:15 |
| olofk | Because I'm having some new prioritites in the project I'm working on and will implement that now | 16:15 |
| stekern | olofk: hmmm... to be precise, I need something that I can hook up to this: https://github.com/skristiansson/i2s/blob/master/rtl/verilog/i2s_tx.v | 16:29 |
| stekern | so, what you describe sounds like something I can use | 16:30 |
| stekern | basically, I need to read out data on each edge of lrclk | 16:31 |
| olofk | Hmm.. you should be able to use the existing stuff for that I think | 16:41 |
| olofk | The wb_stream_writer that I just renamed to wb_stream_reader | 16:42 |
| olofk | or wait a minute. Whih side is connected to the pins, and which is supposed to connect to the wishbone side? | 16:48 |
| stekern | left_chan/right_chan should be connected to a fifo, and lrclk edges are fifo read enable | 16:50 |
| stekern | but, then there's this too: https://github.com/skristiansson/i2s/blob/master/rtl/verilog/i2s_rx.v | 16:50 |
| stekern | which should be connected to the write-side of a fifo | 16:51 |
| stekern | but I'm mostly interested in the tx initially | 16:51 |
| olofk | Right. That's the part that I haven't implemented yet, but will start with now | 16:53 |
| olofk | So how about this.. config regs for an enable flag, start address, buffer size and an interrupt to tell when all data has been read | 16:59 |
| olofk | Later on we can add configurable burst size and read/write pointer | 17:00 |
| olofk | s | 17:01 |
| poke53281 | stekern: Did you test the code on openrisc | 17:16 |
| stekern | poke53281: it doesn't work yet | 17:16 |
| poke53281 | the cast is important in other parts of the code. Push is relatively harmless | 17:17 |
| stekern | but there's a lot of other places that need fixing as well | 17:17 |
| stekern | yes, I know. I have fixed most of them | 17:17 |
| stekern | but some are hard to fix due to the nature of the macro | 17:18 |
| poke53281 | You, know what I do. In the working version After every instruction I write a into a file a register values. In the other version I load them and compare. | 17:20 |
| stekern | I mean, hard to fix by just exchanging the macro with a wrapper | 17:20 |
| poke53281 | I write the content of the registers (and more) into a file and then compare it with the other version. The file could easily have a size of several GB. | 17:24 |
| poke53281 | Otherwise it is very hard to find the subtle errors. | 17:25 |
| stekern | mmm | 17:26 |
| poke53281 | Here it makes also sense to write op_result, op_src and op_dest in the file | 17:37 |
| poke53281 | stekern: My next project is to make Elite Frontier working on openrisc. One good soul already wrote a Atari-ST assembler converter to C for this game. http://tom.noflag.org.uk/glfrontier.html | 18:08 |
| poke53281 | This was one of my favorite games underDOS | 18:08 |
| poke53281 | At least. Big endian to big endian :) | 18:09 |
| stekern | =) | 18:34 |
| olofk | Yes! Elite II :) | 20:21 |
| olofk | hmm... is wb_ram working at all? Simulations don't look very good | 20:22 |
| olofk | ah.. my bad | 21:28 |
| olofk | stekern: I have implemented the initial part of the stream writer stuff now together with a test bench | 21:48 |
| --- Log closed Wed Sep 10 00:00:45 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!