| --- Log opened Mon Oct 13 00:00:35 2014 | ||
| -!- FreezingAlt is now known as FreezingCold | 03:35 | |
| olofk | stekern: We need the exact same registers for the stream reader, right? | 08:06 |
|---|---|---|
| ysionneau | olofk ah! awesome :) I like those quick hack sessions =) | 08:20 |
| ysionneau | I see the 3 of us made it to $HOME, good | 08:21 |
| olofk | There's no place like ~ | 08:32 |
| olofk | hmm... why does my program counter just stop moving? | 08:41 |
| olofk | There's plenty of instructions to execute | 08:41 |
| wallento | hey guys, I will work on the landing site. jungma (Matthias Jung) provided his help, I contacted him and we will draft something on github | 08:44 |
| wallento | btw: nice you made it home | 08:44 |
| wallento | nobody got lost | 08:44 |
| olofk | wallento: Awesome. Very appreciated | 08:44 |
| olofk | wallento: Well, home is where my FPGA boards are, so I was never really away from home | 08:45 |
| wallento | :) | 08:45 |
| imphil|away | pictures are available at https://www.flickr.com/photos/127858841@N06/sets/72157648274711327/ btw | 08:45 |
| -!- imphil|away is now known as imphil | 08:45 | |
| stekern | olofk: yes, I think so | 08:46 |
| olofk | imphil: Cool. I'll take a look | 08:46 |
| olofk | How do you zoom in? My pointer looks like a magnifying glass, but nothing happens when I click | 08:47 |
| stekern | you've just got a too weak index finger | 08:47 |
| olofk | :) | 08:48 |
| olofk | imphil: Very nice pictures | 08:48 |
| imphil | zooming should work by just clicking on it. | 08:48 |
| stekern | imphil: nice! | 08:48 |
| stekern | imphil: https://www.flickr.com/photos/127858841@N06/15330065647/in/set-72157648274711327 <- my name is Stefan, not Christian though | 08:49 |
| imphil | stekern, oh, very much so | 08:49 |
| imphil | fixed | 08:49 |
| olofk | Probably need to recompile my browser with some extra use flags to make zooming work. | 08:49 |
| stekern | thanks! | 08:50 |
| imphil | stekern, at some point yesterday my brain stopped working at all :) | 08:50 |
| stekern | don't worry, I don't know why, but *a lot* of people seem to mix up my first and last name | 08:51 |
| olofk | stekern: What would be the most common reasons for the mor1kx pc to stop moving? I think it needs to fetch new instructions from RAM, but it doesn't | 08:51 |
| olofk | stekern: Yeah. I never done that before, but this weekend I did it at least one time | 08:51 |
| olofk | That never happens with Wallen Stefantowitz | 08:52 |
| wallento | thats the reason I chose that name, noobs | 08:53 |
| imphil | :) | 08:53 |
| wallento | bugreport: I want to watch the photos in dillo on jor1k but copy and paste does not work and I can't find the slash :( | 08:54 |
| stekern | olofk: is something stalling? | 08:55 |
| olofk | Not sure what's going on yet, but I just saw that I got some x on the padv_* signals in mor1kx_ctrl_cappucino | 08:57 |
| stekern | that's probably the reason then | 08:58 |
| olofk | Finally out of mor1kx_lsu_cappucino now. Backtracing signals isn't always fun | 09:13 |
| olofk | stekern: Ehmm... adder_result in mor1x_execute_alu is never assigned a value | 09:16 |
| wallento | any clue who did this? https://www.dropbox.com/s/fg2kln0mjlfa3e8/1%20%282%29.jpg | 09:17 |
| olofk | stekern: Sorry. False alarm | 09:17 |
| olofk | wallento: Ask juliusb . He paid some guy on fiverr to do it | 09:17 |
| wallento | ah, cool | 09:18 |
| wallento | so we have the rights to use it? jungma will vectorize it, but maybe we also have it | 09:18 |
| olofk | wallento: I think you should check with juliusb what usage rights we have | 09:21 |
| wallento | yeah, I send him a mail | 09:21 |
| wallento | thanks! | 09:21 |
| olofk | stekern: Well, of course it's the usual problem with an uninitialized value in the rf | 09:30 |
| olofk | I thought that newlib cleared r0 properly during startup | 09:44 |
| stekern | it doesn't? | 10:05 |
| olofk | Not yet sure that's the problem. | 10:37 |
| olofk | From my somewhat limited understanding of the issue, it looks like I'm getting an undefined value from RAM when I try to read _board_mem_base | 10:39 |
| olofk | Could it be because that's a weak pointer and therefore not initialized? | 10:40 |
| olofk | ahh... or is that optimized away from the elf, because it's supposed to be 0? | 10:40 |
| olofk | (which would mean that it's undefined in the RAM) | 10:40 |
| olofk | Yeah, I can't find that address in the bin file, so I guess that the elf loader never writes it to the RAM. Sneaky! | 10:42 |
| olofk | Yep. Writing zeros to all addresses in the memory model works too | 10:45 |
| olofk | But what happens on real hw? Could that address contain an old value from the RAM? | 10:45 |
| stekern | mmm | 10:48 |
| wallento | i was always wondering. shouldn't r0 not just be hardwired 0? | 10:48 |
| stekern | if it's not initialized it will contain an old value | 10:48 |
| stekern | but the pointer can be placed in .bss, and then it'd be 0 | 10:49 |
| olofk | wallento: We have had a heated discussion about that, and there was some reason why it couldn't be hardwired | 10:49 |
| olofk | stekern: So, should I solve this with some kind of linker directive? | 10:49 |
| wallento | yeah, I roughly remember, I think its kinda adressing the SRAM or so | 10:49 |
| stekern | mostly hysterical raisins | 10:49 |
| olofk | Yeah, that's about what I remember too. That old sw might depend on r0 not being 0 or something like that | 10:50 |
| stekern | olofk: no idea, why is the weak pointer being read? | 10:50 |
| olofk | stekern: Looks like it's the first few instructions in _start | 10:53 |
| olofk | I'll look it up in newlib | 10:53 |
| wallento | in start? | 10:54 |
| wallento | this is early board init | 10:54 |
| olofk | After that | 10:55 |
| olofk | /* Initialise stack and frame pointer (set to same value) */ | 10:55 |
| olofk | That's when _board_mem_base is used | 10:55 |
| wallento | so do you elf load? | 10:56 |
| olofk | But I heard it's totally ok to let some other program tell you where the stack is :) | 10:56 |
| olofk | wallento: Yeah. I use the elf-loader in FuseSoC to preinitialize an SDRAM with an ELF | 10:56 |
| wallento | and after reset _board_mem_base is not the same value as in first boot? | 10:57 |
| olofk | This is all in simulation | 10:57 |
| wallento | ah, okay | 10:57 |
| olofk | So I can easily confirm that the value is never written | 10:58 |
| olofk | I should try adding -mboard and see if that helps | 10:58 |
| wallento | I think its weak so that you can use a board and overwrite it as user without adding a new board descritpion in newlib | 10:58 |
| olofk | Yes, that's the idea, but it would be nice to have it initialized to a default value if no one redefines it | 10:58 |
| olofk | I thought it defaulted to the or1ksim configuration | 10:59 |
| wallento | it should be zero and not in bss, correct? | 10:59 |
| wallento | yes, thats what GCC does | 10:59 |
| olofk | You shouldn't put anything in the BullShitSection | 10:59 |
| olofk | (I have no idea what bss really is) | 10:59 |
| wallento | its zero after loading, thats the only good thing about it ;) | 11:00 |
| wallento | *after booting | 11:00 |
| olofk | That's better than our r0 at least :) | 11:00 |
| wallento | :-D | 11:00 |
| wallento | btw: may I merge this https://github.com/openrisc/or1k-src/pull/12 | 11:01 |
| stekern | wallento: of course | 11:02 |
| olofk | Ok, so if I understand this correctly, the issue I have is that the elf-loader doesn't write bss | 11:03 |
| stekern | elf-loader shouldn't write elf | 11:04 |
| olofk | s/elf/bss ? | 11:04 |
| stekern | the problem is in the start routing | 11:04 |
| stekern | I remember the issue now, I had a patch for that sometime | 11:04 |
| stekern | s/routing/routine | 11:04 |
| stekern | it's doing stuff in the wrong order | 11:04 |
| stekern | I though I had applied that patch | 11:05 |
| stekern | +t | 11:05 |
| stekern | the problem is that the board vars are read before bss is cleared | 11:06 |
| olofk | ah ok. So it's the software's responsibility to clear bss. | 11:06 |
| stekern | yes | 11:07 |
| stekern | https://github.com/openrisc/or1k-src/blob/or1k/libgloss/or1k/crt0.S#L445 | 11:07 |
| stekern | but board mem base is used already here: https://github.com/openrisc/or1k-src/blob/or1k/libgloss/or1k/crt0.S#L445 | 11:07 |
| stekern | err, https://github.com/openrisc/or1k-src/blob/or1k/libgloss/or1k/crt0.S#L394 | 11:07 |
| stekern | and, haha, yes s/elf/bss up there | 11:08 |
| olofk | Damn NSA sneaking in stuff like that in our code base | 11:08 |
| olofk | Sounds like it's newlib rebuilding time | 11:12 |
| olofk | But I got other problems as well it seems | 11:14 |
| olofk | In the beginning of __impure_init it tries to write to address 0x3FFFDFD8. That's quite a bit outside of my RAM | 11:15 |
| stekern | I can't promise that it was as simple as just moving L394' | 11:20 |
| olofk | stekern: No, I understand that, so I'll just clear the RAM manually for now | 11:24 |
| olofk | But I can't understand what's going on with my new problem. Could it be that the heap or stack is outside of my RAM perhaps? | 11:25 |
| stekern | what is your _board_mem_size | 11:26 |
| olofk | 0x40000000 according to my objdump, which would explain what's going on | 11:26 |
| olofk | Hmm.. that's like 1GB | 11:27 |
| stekern | not only like, it is | 11:28 |
| olofk | Is -mboard=de0_nano a gcc or ld flag? | 11:29 |
| olofk | I tried both now, but it looks like board_mem_size is unchanged | 11:30 |
| olofk | Whoops | 11:35 |
| olofk | It works now | 11:37 |
| olofk | stekern: board_mem_size et. al. were redefined locally (I stole your wb_stremer_test program) | 11:41 |
| stekern | ach so | 11:43 |
| stekern | I thought it was odd that it'd default to 1GB | 11:43 |
| wallento | but _board_* aren't bss, are they? | 11:45 |
| olofk | Now they aren't | 11:46 |
| olofk | Does that depend on whether they are linked in with a libgloss library, or if they are set directly from the main program's code? | 11:47 |
| stekern | wallento: if any of them are set to 0, they end up in .bss | 11:47 |
| wallento | really? because they are weak? | 11:47 |
| stekern | no, because it's zero | 11:47 |
| wallento | but where is this defined | 11:48 |
| stekern | I maybe phrased that unclear, of course only the ones that are set to 0 end up in .bss | 11:48 |
| wallento | the one is data, that has a fixed value | 11:48 |
| ysionneau | olofk: I just noticed there is intercon = wishbone.InterconnectPointToPoint(master, slave) , maybe you want to use that :) | 11:48 |
| wallento | i would expect, that all initialized - independent of value - would be in .data | 11:48 |
| stekern | yes, but that's not what happens | 11:49 |
| wallento | and all undefined are (whyever) initialized to zero as .bss | 11:49 |
| olofk | ysionneau: Yep. I found that one yesterday. Worked fine | 11:49 |
| wallento | mmh, thats awkward | 11:49 |
| ysionneau | ok ^^ | 11:49 |
| ysionneau | olofk: ok now I understand that what you said earlier is exactly that :p | 11:50 |
| ysionneau | sorry! | 11:50 |
| olofk | haha | 11:50 |
| olofk | wallento: But in practice I guess this only matter right now because bss isn't correctly cleared | 11:51 |
| wallento | maybe I am confused, but when I compile _board are always in .text | 11:52 |
| wallento | or1k-elf-objdump -t test.elf | grep _board | 11:52 |
| wallento | 00003314 g .text00000000 _board_init_early | 11:52 |
| wallento | 0000331c w .text00000000 _board_init | 11:52 |
| wallento | 00003308 w .text00000000 _board_exit | 11:52 |
| wallento | 000032fc w .text00000000 _board_uart_base | 11:52 |
| wallento | 00003304 w .text00000000 _board_uart_IRQ | 11:52 |
| wallento | 00003300 w .text00000000 _board_uart_baud | 11:52 |
| wallento | 000032f0 w .text00000000 _board_mem_base | 11:52 |
| wallento | 000032f8 w .text00000000 _board_clk_freq | 11:52 |
| wallento | 000032f4 w .text00000000 _board_mem_size | 11:52 |
| wallento | or1k-elf-objdump -t test.elf | grep _bss | 11:52 |
| wallento | 00005ee0 g .bss00000000 __bss_start | 11:52 |
| wallento | olofk: you are right. if _board_mem_base ends up in bss because it is 0, then you might set it before in _board_init_early | 11:53 |
| davide | hi guys, concenring the OpenRISC conference 2015, if you cannot do at CERN we are available to host it in Zurich | 11:56 |
| wallento | thats great news | 11:57 |
| olofk | davide: Hi. Thanks for the offer. That's really good to know | 11:57 |
| davide | no problem, just let me know when you have some news form Alessandro | 11:59 |
| olofk | Do we really have to save all that crap in our interrupt routine? All those reads and writes to RAM cancels out the benefit of my DMA stuff | 11:59 |
| wallento | we may change it in a way, that it only saves what is needed by assembler | 12:00 |
| wallento | and then the user can define which N first it will use along with the callback he registers | 12:00 |
| olofk | davide: Alessandro contacted me this morning. He thought that they "most likely" could host it, but no promises | 12:00 |
| wallento | but as the callback can be anything.. | 12:01 |
| olofk | I probably need to copy larger chunks if I want it to be more efficient then | 12:02 |
| wallento | yes, or check completion asynchronously, w/o interrupt | 12:03 |
| wallento | e.g. next time you call your dma driver | 12:04 |
| wallento | (without really knowing what you are doing) | 12:04 |
| olofk | Yeah, that could be a good idea | 12:04 |
| olofk | I'm moving data | 12:04 |
| wallento | yes, but why? ;) | 12:04 |
| olofk | And I'm going to have multiple DMA transfers in progress at the same time with limited CPU resources and memory bandwidth | 12:04 |
| stekern | wallento: maybe it depends on the phase of the moon or some other black magic to then ;) | 12:05 |
| olofk | wallento: It's the SDR stuff I'm working on. On the TX side, CPU writes samples to a buffer, which are transmitted with DMA. On the RX side, receiver writes samples to RAM and inform CPU when they are available | 12:06 |
| wallento | okay, if thats the case that the compiler may move 0 ro data to bss (which is odd), we need to set them in _board_init_early | 12:06 |
| wallento | olofk: got it. if you can have them running asynchronously then I would suggest checking completion of all outstanding just the next time you call dma_start() or however it is called | 12:07 |
| wallento | HPC stuff often works like this | 12:07 |
| wallento | I know that MPI implementations do/did it, so that MPI updated the status of asynchronous operations whenever you call MPI_*() or so | 12:07 |
| olofk | wallento: That sounds like a better idea | 12:09 |
| olofk | wallento: Also, I got very interested when I read about something about lossy encoding techniques for limited bandwitdh on one of your slides | 12:10 |
| olofk | Forgot to ask you more about that | 12:10 |
| wallento | oh yeah, if you send me an email what exactly you are interested in, I can provide you more data or conenct you to the guy doing it | 12:11 |
| olofk | Oh and I forgot to ask _franck_ how it's going with the house. Way to many people to talk to in that limited time | 12:11 |
| olofk | wallento: I'll do that if I feel like taking a more serious look at it | 12:11 |
| wallento | so, next ORCONF is one week :) | 12:12 |
| _franck__ | about my house I'm going to be busy for about 1 year I think | 12:12 |
| _franck__ | and I agree, too many people in a short time | 12:12 |
| _franck__ | by the way I left the conference at 12:00 and arrive home at 7pm. That wouldn't have take longer if I had to flight to New-York.... | 12:14 |
| _franck__ | stupid low cost flights :) | 12:14 |
| stekern | there's so much overhead when flying | 12:15 |
| stekern | I was home 23:45 | 12:17 |
| olofk | haha. Yeah. That's quite insane. | 12:18 |
| olofk | Especially for _franck__ since it should just be like on the other side of the mountains | 12:19 |
| _franck__ | I can't wait for the tele-transportation module we'll have in some years ;) | 12:19 |
| olofk | _franck_: Yeah, I've been waiting for that too | 12:20 |
| olofk | larger buffers definitely helped a lot | 12:21 |
| olofk | wallento: Do you think async polls are the way to go for multi-core too? I'm just thinking that it seems like a pretty easy solution to just assign different IRQs to different CPUs | 12:22 |
| olofk | No extra synchronization would be needed AFAICS | 12:23 |
| wallento | if you do it in an atomic way thats a solution in baremetal | 12:23 |
| olofk | wallento: Just in case you happen to know anything about running several OpenRISC cores at the same time :) | 12:23 |
| wallento | actually I did some research about this stuff and came out with a neat idea called HW-OSQM | 12:24 |
| olofk | Sexy abbreviation | 12:24 |
| wallento | where instead of an interrupt or polling to signal the completion of a blocking DMA call from thread by appending them to the ready queue of your OS again | 12:25 |
| wallento | http://dl.acm.org/citation.cfm?id=2450051 | 12:25 |
| wallento | but this never became popular ;) | 12:25 |
| wallento | and it's actually straight forward, you already know everything about it with my description above ;) | 12:26 |
| olofk | So is the idea to have a "message server" that collects all events from the cores, and let sw read from that? | 12:27 |
| wallento | is actually more simple | 12:27 |
| wallento | along with your transaction you store your thread_queue_element* (or however it is called) in the DMA descriptor in your DMA controller | 12:28 |
| olofk | DMA descriptor? | 12:28 |
| wallento | like (src @, dest @, size) | 12:28 |
| stekern | there's only soft descriptors with the wb_streamer | 12:29 |
| olofk | Is it like a tag to identify the current DMA transaction+ | 12:30 |
| olofk | s/+/? | 12:30 |
| wallento | kind of. when your transaction is completed now, the DMA knows how to modify a list | 12:30 |
| wallento | and it just appends your thread element back to the list of runnable threads | 12:30 |
| wallento | and it will be scheduled again | 12:31 |
| wallento | I don't think thats really what you are looking for, but will be an essential part of the OpTiMSoC inter-tile DMA and message passing | 12:31 |
| olofk | Yeah, one of these days I will find time to take a closer look at what you're doing with OpTiMSoC | 12:35 |
| wallento | you should wait a month or so | 12:35 |
| wallento | there are many things coming up with me writing up the thesis | 12:35 |
| wallento | finally packing them properly | 12:36 |
| _franck__ | so, what about the opencores forum/wiki ? Someone want to try to summarize what was said sunday ? | 12:37 |
| wallento | yes, I was planning to write this up | 12:37 |
| olofk | _franck_: Main topics were where to have the conference next year, and discussion if we should set up an foundation for Open Source RTL stuff like OpenRISC | 12:38 |
| _franck__ | ok thanks | 12:38 |
| olofk | We decided to host the conference in your house next year, so make sure it's ready by then | 12:39 |
| _franck__ | and ? should we ? | 12:39 |
| _franck__ | what !! ? | 12:39 |
| _franck__ | :) | 12:39 |
| davide | d | 12:40 |
| olofk | It seemed like most people thought that a foundation is a good idea. We didn't really set any details, but a group of people volunteered to start investigating how to set it up and what the foundation should really do | 12:41 |
| arokux | olofk: hi. I have small question. I'd like to learn about creating some hardware components and go through the whole pipe line. I do not know anything yet. from what I imagine I need to create the component first in verilog (or some other HDL) then I can implement it in FPGA. could you please tell me where I can read more about it? and also maybe you could recommend low cost board with FPGA preferably open and with tools for Linux. Thanks! | 12:50 |
| arokux | maybe some others could give some advice too | 12:53 |
| poke53282 | imphil: Thanks for the pictures | 13:05 |
| imphil | poke53282, you're very welcome! | 13:48 |
| olofk | arokux: For cheap boards I would recommend de0 nano. It is well supported. As for getting a start in doing HDL design, you might want to check out http://chiphack.org | 14:16 |
| olofk | poke53282: Finally looked up the c64 address map and learned how to set Extended color mode :) | 14:19 |
| arokux | olofk: thank you! | 14:25 |
| -!- imphil is now known as imphil|away | 17:04 | |
| poke53282 | olofk: Actually the number is supposed to be 53281 and not 53282. But I guess, I logged in twice and then the chatroom program changed to the second nickname. | 21:07 |
| poke53282 | poke53281,0 was (one of) the first "programs" I ever wrote. | 21:08 |
| poke53282 | and it was so cool. Just by typing this command you could switch the screen color. I was around 8 or so. | 21:09 |
| poke53282 | the next code was then something like | 21:10 |
| poke53282 | 10 poke53281,I | 21:10 |
| poke53282 | 20 I=I+1 | 21:10 |
| poke53282 | 30 goto 10 | 21:10 |
| poke53282 | I didn't understand much. Never saw something like a variable. But it gave nice graphical effects. | 21:11 |
| poke53282 | and accidently my birthday is on 3.2.81 :) | 21:11 |
| --- Log closed Tue Oct 14 00:00:36 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!
