| *** tpb has joined #timvideos | 00:00 | |
| *** puck has quit IRC | 00:17 | |
| *** puck has joined #timvideos | 00:21 | |
| *** Thaelim has joined #timvideos | 00:25 | |
| *** Thaelimm has joined #timvideos | 00:34 | |
| *** Thaelim has quit IRC | 00:35 | |
| *** Thaelimm has joined #timvideos | 00:35 | |
| *** futarisIRCcloud has joined #timvideos | 01:04 | |
| *** Thaelimm has quit IRC | 01:34 | |
| CarlFK[m] | vmlinux.o: final close failed: No space left on device | 03:22 |
|---|---|---|
| CarlFK[m] | doh. | 03:22 |
| *** rohitksingh_work has joined #timvideos | 03:52 | |
| *** thaytan has quit IRC | 06:02 | |
| *** thaytan has joined #timvideos | 06:02 | |
| *** ChanServ sets mode: +v thaytan | 06:02 | |
| *** gsmalik has quit IRC | 06:14 | |
| CarlFK[m] | hey look it finished... | 06:21 |
| CarlFK[m] | um.. sudo make install; sudo grub-update? | 06:21 |
| *** futarisIRCcloud has quit IRC | 06:24 | |
| *** aps has joined #timvideos | 07:48 | |
| *** Kripton has quit IRC | 08:14 | |
| *** Kripton has joined #timvideos | 08:22 | |
| *** f15h_ has joined #timvideos | 08:56 | |
| *** fumblehool has joined #timvideos | 08:56 | |
| cr1901_modern | _florent_: Did you see my msgs yesterday? | 09:36 |
| cr1901_modern | _florent_: In any case I think reverse=True for the up/downconverter is going to need to be a configurable parameter for the SD card core. | 09:37 |
| *** f15h_ has quit IRC | 09:37 | |
| cr1901_modern | or changed to reverse=False b/c I can't use reverse=True for my intended application; the BIST should work fine with rev=False | 09:38 |
| *** f15h_ has joined #timvideos | 09:42 | |
| _florent_ | cr1901_modern: Reverse=True or False only has a meaning if you are writing/reading the SDCard with an external reader. We could add a parameter for that yes if needed | 09:48 |
| _florent_ | cr1901_modern: if SDCard is only accessed by the core, there it does not make any difference | 09:49 |
| *** f15h_ has quit IRC | 09:52 | |
| *** f15h_ has joined #timvideos | 09:52 | |
| cr1901_modern | _florent_: I don't understand what you mean by "if SDCard is only accessed by the core, there it does not make any difference" | 09:57 |
| cr1901_modern | _florent_: AFAICT, there's no way to access the SDCard "only by the core". The public interface that the core exposes requires you to go through the up/downconverters. | 09:58 |
| cr1901_modern | >We could add a parameter for that yes if needed | 10:00 |
| cr1901_modern | In any case, I would appreciate that and I'll send it as part of the PR. I'm implementing a wishbone buffer for litesdcard. But reverse=True isn't going to work | 10:00 |
| _florent_ | cr1901_modern: yes then what i'm meaning if your up/downconverters are using the same reverse parameter, you don't really have to know how data are store in the SDCard | 10:00 |
| _florent_ | cr1901_modern: this is only useful if you access the SDCard content by putting it in an external ready | 10:00 |
| _florent_ | reader | 10:00 |
| cr1901_modern | _florent_: Okay, thank you for clarifying. And I agree with that. | 10:01 |
| cr1901_modern | _florent_: If you want to share the SD card between systems however, every system is going to read the SD card contents as how they were stored in RAM. | 10:02 |
| cr1901_modern | reverse=True doesn't work for this, b/c it will store the most significant byte of a 32-bit word first => least significant byte | 10:03 |
| cr1901_modern | The SD spec also says "store least significant byte first, up to most significant byte". For the BIST, this doesn't matter b/c as you said, the BIST doesn't care how the data is stored on the card. | 10:05 |
| cr1901_modern | (And the card itself doesn't care either, for that matter). | 10:05 |
| cr1901_modern | _florent_: For interoperability between two computers however, I think the default parameter for reverse should be changed | 10:06 |
| _florent_ | cr1901_modern: we could change the default yes | 10:08 |
| cr1901_modern | _florent_: Just to make sure. Do you understand why I want to change the default? | 10:09 |
| cr1901_modern | I feel like I might've did a poor job explaining :( | 10:09 |
| *** Kripton has quit IRC | 10:14 | |
| *** futarisIRCcloud has joined #timvideos | 10:16 | |
| *** Kripton has joined #timvideos | 10:22 | |
| _florent_ | cr1901_modern: yes i think i understand, you just want to change the physical order of the bytes in the sdcard. | 10:24 |
| futarisIRCcloud | _florent_: Yep. The endianness should be the same as on other systems. | 10:25 |
| _florent_ | cr1901_modern: i just don't understand why it's causing you issue since in any case you are using the up/down converter | 10:26 |
| *** f15h_ has quit IRC | 10:26 | |
| *** f15h has joined #timvideos | 10:26 | |
| *** f15h has quit IRC | 10:35 | |
| *** f15h has joined #timvideos | 10:36 | |
| cr1901_modern | _florent_: What if I want to read the SD card on other systems | 10:37 |
| cr1901_modern | or write a file to the SD card on another system "A", eject it from system "A", and then bring it over to a design "B" running litesdcard? | 10:37 |
| cr1901_modern | Right now litesdcard reads/writes bytes in a way that _even if_ we "dd" a file from an external system directly onto the SD card (i.e. without a FAT filesystem), litesdcard will read it out incorrectly. | 10:39 |
| cr1901_modern | also if litesdcard writes to a file, and we "dd" the SD card's contents onto another system, each 32-bit word of "dd's output" will be stored in the wrong order | 10:41 |
| *** f15h_ has joined #timvideos | 10:43 | |
| *** f15h has quit IRC | 10:45 | |
| _florent_ | cr1901_modern: i haven't really looked at that. I'm fine if you think we should inverse order, you can fix that and create a pull request. | 11:02 |
| cr1901_modern | _florent_: Ty will do. I will put it as part of my overall PR to add a default interface from reading from a soft-core | 11:04 |
| *** fumblehool has quit IRC | 11:06 | |
| *** rohitksingh_work has quit IRC | 12:34 | |
| *** rohitksingh has joined #timvideos | 13:12 | |
| *** rohitksingh1 has joined #timvideos | 13:47 | |
| *** rohitksingh1 has quit IRC | 14:07 | |
| *** aps has quit IRC | 14:08 | |
| *** gsmalik has joined #timvideos | 14:09 | |
| *** f15h_ has quit IRC | 15:20 | |
| *** rohitksingh has quit IRC | 15:33 | |
| *** rohitksingh has joined #timvideos | 15:34 | |
| *** hyadez has quit IRC | 15:50 | |
| *** rohitksingh has quit IRC | 16:22 | |
| *** rohitksingh has joined #timvideos | 16:26 | |
| *** rohitksingh has quit IRC | 16:40 | |
| *** fumblehool has joined #timvideos | 16:54 | |
| *** hyadez has joined #timvideos | 17:22 | |
| *** rohitksingh has joined #timvideos | 17:37 | |
| *** suhdood has joined #timvideos | 18:14 | |
| *** f15h has joined #timvideos | 18:30 | |
| *** f15h has joined #timvideos | 18:31 | |
| *** samsagaz has quit IRC | 18:40 | |
| *** Kripton has quit IRC | 19:11 | |
| *** Kripton has joined #timvideos | 19:22 | |
| *** fumblehool has quit IRC | 19:23 | |
| *** suhdood_ has joined #timvideos | 19:35 | |
| *** suhdood_ has quit IRC | 19:37 | |
| *** suhdood has quit IRC | 19:38 | |
| *** suhdood has joined #timvideos | 19:42 | |
| *** f15h has quit IRC | 20:02 | |
| *** CarlFK has quit IRC | 20:22 | |
| *** CarlFK has joined #timvideos | 20:31 | |
| *** ChanServ sets mode: +v CarlFK | 20:31 | |
| CarlFK[m] | I am so happy! | 20:42 |
| CarlFK[m] | https://www.pyohio.org/2018/speaker/create/ "E-mail of video reviewer" | 20:42 |
| CarlFK[m] | for tv.us/projects how does this sound: | 21:41 |
| CarlFK[m] | QEMU is a generic and open source machine & userspace emulator and virtualizer. | 21:41 |
| CarlFK[m] | It can be used to emuilate LiteX soft core cpu and thus help with LiteX fpga development. | 21:41 |
| *** suhdood has quit IRC | 21:42 | |
| *** CarlFK has quit IRC | 21:44 | |
| *** CarlFK has joined #timvideos | 21:53 | |
| *** ChanServ sets mode: +v CarlFK | 21:53 | |
| *** rohitksingh has quit IRC | 22:02 | |
| *** suhdood has joined #timvideos | 22:14 | |
| *** suhdood_ has joined #timvideos | 22:51 | |
| *** suhdood has quit IRC | 22:52 | |
| *** suhdood_ has quit IRC | 22:57 | |
| *** CarlFK has quit IRC | 23:16 | |
| mithro | CarlFK[m]: https://github.com/timvideos/getting-started/issues/41 | 23:22 |
| tpb | Title: [LiteX] QEmu simulation of a LiteX generated SoC · Issue #41 · timvideos/getting-started · GitHub (at github.com) | 23:22 |
| CarlFK[m] | mithro (IRC): thanks. ill use that | 23:24 |
| CarlFK[m] | mithro (IRC): qustion about the state of things - page says "Currently to do firmware development you need access to FPGA hardware." | 23:25 |
| CarlFK[m] | isn't qemu working such that you don't need hardware? | 23:25 |
| mithro | CarlFK[m]: Also see the random notes document | 23:25 |
| mithro | https://docs.google.com/document/d/1x3YDNqg1xUiLKl85YVvVBWTwHOq1hSWyyRMO-eKLBeQ/edit# | 23:25 |
| tpb | Title: LiteX QEmu Simulation support Random Notes - Google Docs (at docs.google.com) | 23:25 |
| mithro | CarlFK[m]: Did you see the "Tools for onboarding new contributors!" email I forwarded you? | 23:26 |
| CarlFK[m] | I think so - I skim over most gsoc stuff looking for anything new | 23:27 |
| CarlFK[m] | still not sure if the "Currently ..need access to FPGA hardware." is still accurate | 23:29 |
| mithro | CarlFK[m]: To do firmware development with video it does | 23:29 |
| mithro | But some basic stuff can now be done without FPGA hardware.... | 23:29 |
| mithro | bblr | 23:29 |
| CarlFK[m] | mithro (IRC): wont that always be the case ? | 23:29 |
| mithro | CarlFK[m]: QEMU could emulate the video input/output peripherals (in fact it could even possibly connect them to gstreamer pipes).... | 23:30 |
| CarlFK[m] | jea: NUK!!! | 23:31 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!