| GentlemanEnginee | Hello | 04:20 |
|---|---|---|
| glowplug | How's it going? | 04:40 |
| GentlemanEnginee | It fares in a fairly fair fashion. | 04:50 |
| GentlemanEnginee | I just put on the kettle. | 04:50 |
| GentlemanEnginee | I am still investigating the Memory Controller from the Milkymist. | 04:54 |
| GentlemanEnginee | It appears that the DDR initialization is handled by the CPU (or other circuit) seperate from the Memory Controller, which is placed into a pass-through mode to play an initialization sequence. | 04:55 |
| glowplug | Interesting... | 05:10 |
| glowplug | Pass through to hand over control of the controller to the CPU? | 05:10 |
| GentlemanEnginee | For the initialization. | 05:12 |
| GentlemanEnginee | That would require determining the initialization sequence for the DDR chip to be used. | 05:12 |
| GentlemanEnginee | All the more interesting... | 05:12 |
| stekern | yeah, but the init code that the milkymist uses is freely available | 05:43 |
| stekern | https://github.com/milkymist/milkymist/blob/master/software/libhpdmc/libhpdmc.S | 05:47 |
| stekern | I've ported that to openrisc too: http://git.chokladfabriken.org/?p=milkymist-openrisc.git;a=blob;f=software/libhpdmc/libhpdmc.S;h=2f9898541283e00e5d50d5f12851751e816fa735;hb=HEAD | 05:48 |
| GentlemanEnginee | Are you stating that the initialization is done in assembly? | 05:52 |
| GentlemanEnginee | I was looking at porting this to mor1kx. | 05:52 |
| GentlemanEnginee | How generic is this initialization? Would a differing DDR Chip likely require a differing script. | 05:55 |
| stekern | no, I think that is generic | 05:57 |
| stekern | yes, the init is done in assembly. | 05:57 |
| GentlemanEnginee | Intriguing... | 05:58 |
| GentlemanEnginee | I assume one would require loading it during a main init function prior to much else. | 05:59 |
| stekern | yeah, that should run before accessing DDR | 05:59 |
| GentlemanEnginee | Are there any barriers to creating this in Verilog to be synthesized into the CPU/Memory Controller. | 06:00 |
| GentlemanEnginee | *? | 06:04 |
| stekern | no | 06:15 |
| stekern | but you could just put it in an ROM in the soc | 06:15 |
| GentlemanEnginee | I might give that an attempt after. | 06:15 |
| stekern | so, really, no point | 06:15 |
| GentlemanEnginee | How would the ROM be any different? | 06:16 |
| stekern | the code isn't located in the DDR | 06:16 |
| stekern | and on-chip | 06:16 |
| GentlemanEnginee | If it was a cicuit that was run at reset, would that not be preferred? | 06:18 |
| stekern | not necessary | 06:20 |
| stekern | you waste logic on that, vs some blockram | 06:20 |
| stekern | *necessarily | 06:21 |
| GentlemanEnginee | So, you recommend a ROM that is called by the main init routine? | 06:22 |
| stekern | I rececommen that the cpu reset into the ROM | 06:32 |
| stekern | like we already do on many boards | 06:33 |
| stekern | you either need aROM or some other device (i.e. flash) to boot from | 06:34 |
| GentlemanEnginee | Oh I see. The ROM would then be set to call a specific memory location that can be used to call a main function, or OS booting? | 06:41 |
| stekern | exactly | 06:45 |
| GentlemanEnginee | That would work. | 06:45 |
| stekern | it should also serve the purpose of moving useful data into the ddr | 06:46 |
| stekern | from somewhere | 06:46 |
| stekern | on most of the boards there is some sort of spi flash | 06:46 |
| stekern | if you have parallell flash you can execute out of that instead of the rom | 06:47 |
| stekern | quad spi flash could probably be used for that too | 06:48 |
| GentlemanEnginee | I just did not wish to require the user to call an assembly routine in order to use RAM. That was a little frusterating. | 06:50 |
| GentlemanEnginee | *would be | 06:51 |
| stekern | yes, I agree | 06:51 |
| stekern | not that would be an odd requirement, but openrisc sw (e.g.u-boot) assume that the main mem is ready to use | 06:54 |
| GentlemanEnginee | Yes, that was the manner of use I was concerned about. | 06:57 |
| GentlemanEnginee | If you are not using an OS, or something such as FreeRTOS, it is not difficult to have hardware initialization routines. However, even then it is tedious. | 06:58 |
| GentlemanEnginee | Hello mbuf. | 07:02 |
| mbuf | GentlemanEnginee: hi | 07:03 |
| GentlemanEnginee | How fares the battle? | 07:03 |
| mbuf | GentlemanEnginee: which one? | 07:03 |
| GentlemanEnginee | All, none, or a superposition thereof... | 07:03 |
| mbuf | GentlemanEnginee: All fine | 07:04 |
| GentlemanEnginee | What manner of projects are you working on? | 07:04 |
| mbuf | GentlemanEnginee: you are not a bot, are you? | 07:05 |
| GentlemanEnginee | I consider myself to have passed Turing Tests... | 07:07 |
| mbuf | GentlemanEnginee: :) | 07:07 |
| mbuf | GentlemanEnginee: nothing in particular, is there anything in openrisc that I can help with? | 07:08 |
| GentlemanEnginee | I am rather new here, and simply learning some ropes. | 07:08 |
| mbuf | GentlemanEnginee: okay | 07:08 |
| GentlemanEnginee | I am currently looking at porting the Milkymist Memory Controller to mor1kx. | 07:09 |
| mbuf | GentlemanEnginee: do you have a development board to play with? | 07:09 |
| mbuf | GentlemanEnginee: I see | 07:09 |
| GentlemanEnginee | Not yet. | 07:09 |
| GentlemanEnginee | I had one, but lost it back to its original owner. | 07:09 |
| mbuf | GentlemanEnginee: okay | 07:09 |
| GentlemanEnginee | glowplug has his heart set on creating his own development board. | 07:10 |
| GentlemanEnginee | I am considering giving him a hand. | 07:12 |
| GentlemanEnginee | Other than that, I am leaning towards a Spartan 6 development board. | 07:13 |
| mbuf | GentlemanEnginee: okay | 07:17 |
| mbuf | GentlemanEnginee: will catch up with you later | 07:17 |
| GentlemanEnginee | Quite likely... | 07:19 |
| GentlemanEnginee | A good night to all. | 08:18 |
| stekern | man, olofk wasn't joking when he complained about the CDC in ethmac... | 08:57 |
| stekern | just took a peek in eth_wishbone.v | 08:58 |
| stekern | jeremybennett, _franck_: how does gdbs dump command read stuff from memory? byte by byte? | 09:33 |
| jeremybennett | stekern: A good question - let me check | 09:43 |
| stekern | right now I'm doing: set pagination off; set logging on; x/4096 0x96000000 | 09:44 |
| stekern | which works perfect, but I imagine that dump would be faster | 09:45 |
| stekern | maybe it won't be that much faster, now when I start to think about it | 09:46 |
| stekern | most of the time is probably spent reading from the target anyway | 09:46 |
| jeremybennett | Looking at the packets, it uses an "m" packet to read a block of memory. | 09:46 |
| jeremybennett | So however the GDB server chooses to implement the memory packet, that's how it will do it. | 09:46 |
| stekern | and that translates to what in layman terms? ;) | 09:47 |
| stekern | ah, ok | 09:47 |
| jeremybennett | (Tested with GDB 7.5.1 for ARC and gdbserver on ARC linux) | 09:47 |
| stekern | I just get a Cannot access memory at address 0x96000000 | 09:47 |
| jeremybennett | Basically the GDB client asks the target for the block of memory from <start address> to <end address> and the target sends that back. | 09:47 |
| jeremybennett | There's a limit on packet size, so if you ask for a large amount it will use multiple packets. | 09:48 |
| stekern | but I get that on 0x100 too | 09:48 |
| stekern | so maybe we doesn't dupport 'm' packages? | 09:48 |
| jeremybennett | I'm sure you do. If you use "set debug remote 1" it will show you the packets being sent. | 09:49 |
| jeremybennett | Looking at gdbserver it uses ptrace with PTRACE_PEEKTEXT to get the memory values. | 09:49 |
| jeremybennett | (linux_read_memory in linux-low.c) | 09:50 |
| stekern | Cannot access memory at address 0x96000000 | 09:50 |
| stekern | äääh | 09:50 |
| stekern | http://pastie.org/6623512 | 09:51 |
| jeremybennett | A 'm' packet can return an error packet (Enn) if it can't read the memory. | 09:51 |
| stekern | was what I tried to paste | 09:51 |
| jeremybennett | Just looking | 09:51 |
| jeremybennett | That looks correct to me. Why does the GDB server think it can't read 0x100 bytes at 0x100? | 09:52 |
| jeremybennett | What are you using as your GDB server? gdbserver on Linux? OpenOCD's server? | 09:52 |
| jeremybennett | Anyway the problem is in the GDB server, not in the GDB client. | 09:53 |
| stekern | atm, or_debug_proxy | 09:53 |
| stekern | I'll test with openocd | 09:53 |
| stekern | I think I'll stick with the textual 'x' dump anyways, so it's no showstopper for me | 09:55 |
| stekern | ok, it works perfectly in openocd, so no need to investigate that more | 09:57 |
| stekern | thanks for the help jeremybennett | 09:58 |
| jeremybennett | stekern: Glad to help looks like a bug in or_debug_proxy | 10:05 |
| stekern | so, trace dump acquired, next step, turn that into a VCD | 10:11 |
| -!- jeremy_bennett is now known as jeremybennett | 12:54 | |
| stekern | the VCD format is really simple, at least for my needs. | 13:37 |
| stekern | why haven't I done this before? | 13:37 |
| stekern | the answer is probably as simple as, I haven't needed it badly enough | 13:37 |
| stekern | http://oompa.chokladfabriken.org/tmp/mor1kx_on_atlys_dump.png | 13:43 |
| stekern | first test, trig0 = pc_execute, data0 = pc_decode, data1 = ins_decode and data2 = pc_ctrl | 13:43 |
| stekern | I need to make some nice config file which splits the 32-bit values into proper signal names | 13:44 |
| _franck__ | stekern: last time you talked about that I took a look at VCD format and ask myself the same question :) | 14:36 |
| stekern | _franck__: the actual logging to blockram is fairly simple too: http://git.chokladfabriken.org/?p=trace_logger.git;a=blob;f=rtl/verilog/tracer.v;h=5b1d44e60291b25af6e3ab8c184cf46ded474403;hb=386648c07cc78a67d4b0d6f5d1421a7f58392290 | 15:02 |
| stekern | just need to improve it, using signaltap for the last months have shown me how it _should_ work | 15:03 |
| stekern | I need to make a circular buffer so I can get to see the data *before* the trigger | 15:04 |
| stekern | that's usually what's interesting | 15:04 |
| stekern | coupled with gdb's 'x' command and file logging it'll become a pretty "easy to use" setup | 15:06 |
| stekern | less tedious than I had anticipated myself | 15:07 |
| _franck__ | I was about to ask you why you're not using signaltap...but you're working on xilinx now :) | 15:09 |
| stekern | yeah, I've moved over to the atlys board and everything is broken :( | 15:10 |
| stekern | and I feel like a blind person without signaltap, so now I have to build my own =P | 15:11 |
| stekern | if just stuff like: assign debug_signal = my_module.my_other_module.some_signal; | 15:12 |
| _franck__ | I've always wanted to do one :) but here we don't have automatic signal connections and reconfiguration on the display names on the host side | 15:12 |
| stekern | would be synthesizable, everything would just be a dance on roses | 15:12 |
| stekern | that's the most tedious part, reconnecting the debug signals | 15:13 |
| stekern | especially if it's one that's buried deep in some module | 15:14 |
| _franck__ | this is a very anoying thing with those HDL languages | 15:16 |
| _franck__ | you want to add a signal on your top and you're good for 15 minutes :) | 15:16 |
| stekern | I don't understand why the synthesizers doesn't support that, but the simulators does | 15:17 |
| jeremybennett | _franck__: Did you see my GDB post. Are you interested in submitting the or1k port? | 16:58 |
| _franck__ | I saw it. I was thinking it was like GCC: no submission without gurus abrobation | 17:00 |
| _franck__ | I would need to include the tdesc file i the sources (for now, the tdesc file in _only_ get from the remote) | 17:00 |
| jeremybennett | You have to submit and have it reviewed, which takes time. | 17:07 |
| _franck__ | blueCmd: are you still here ? I think you've already did that (plus your work on the linux gdb). Could you share this ? | 17:07 |
| jeremybennett | You also have to have an agreement with the FSF to submit stuff. | 17:07 |
| blueCmd | _franck__: I am! | 17:07 |
| blueCmd | _franck__: I'm busy with my thesis though, so I'm not as active as my super-active february :P | 17:08 |
| _franck__ | jeremybennett: ok so I can't submit, you're the only one able to do that | 17:08 |
| jeremybennett | I have that, so if necessary I can submit on your behalf (you'd have to assign it to me, and then I would assign it) | 17:08 |
| jeremybennett | Yao has said he'll hold off deleting the current stuff if we submit within a 2-3 months. If you have a dissertation to complete that might not be possible | 17:09 |
| blueCmd | there is also the matter of how to seperate the tdesc for baremetal OR and linux OR | 17:09 |
| jeremybennett | So perhaps I should let him delete the current stuff, and then we start with a new submission. | 17:09 |
| jeremybennett | I haven't looked at the latest code. Is the tdesc the XML description? | 17:10 |
| jeremybennett | If so, you are correct to get it from the remote. But you can put it in the gdb/features subdirectory. | 17:11 |
| _franck_ | I've been disconnected | 17:16 |
| -!- Netsplit *.net <-> *.split quits: serp_, Gentlema`, _franck__ | 17:21 | |
| glowplug` | I have apparently joined twice. | 19:07 |
| asm | twice the fun! | 19:14 |
| glowplug` | =) | 19:20 |
| stekern | ring buffer (and thus pre trigger support) implemented: http://git.chokladfabriken.org/?p=trace_logger.git;a=blobdiff;f=rtl/verilog/tracer.v;h=da5f073c18dd4dc2804e2cd3eb4918bf80206d46;hp=e95538fc6ed713874fb125f6fae3c8e5774b3853;hb=694a6af7717f7fde6ec51affd750d027823d47e6;hpb=73753c47b6603411d354dd2709c79402e7a11e53 | 22:28 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!
