| *** tpb has joined #timvideos | 00:00 | |
| mithro | I'm alive! (kinda) | 02:41 |
|---|---|---|
| mithro | tumbleweed: I'll be around for the next 8-10 hours I think | 02:41 |
| *** panther has joined #timvideos | 02:47 | |
| xfxf | mithro: so MCEC are being a bit painful (pycon au venue), they're insisting that we shouldn't use HDMI2USB as a passthrough device and they'll supply a scan converter that will give us a HDMI out feed | 03:12 |
| xfxf | the only way they're willing to proceed is if i basically make them entirely non-responsible for no problems, which is rubbish | 03:13 |
| xfxf | just checking with you, you absolutely want them as passthrough devices, yes? | 03:13 |
| mithro | xfxf: yes | 03:13 |
| xfxf | are you going to be around to help if we have issues? | 03:13 |
| mithro | xfxf: We will provide them with a 720p HDMI feed | 03:13 |
| xfxf | because what they're saying is making me a bit nervous | 03:13 |
| xfxf | yes, i've been through this 5 times | 03:13 |
| xfxf | they're only willing to proceed if they're taking zero responsibility for issues | 03:14 |
| xfxf | i've told them i'm happy if that's limited to just the HDMI, but ugh | 03:14 |
| xfxf | tis fine, i'll keep pushing | 03:14 |
| xfxf | i already tested the box on their systems, worked perfectly | 03:14 |
| xfxf | i have a EDID dump if you want it | 03:15 |
| mithro | xfxf: Why do they even know about the HDMI2USB stuff? You should tell them they are getting the HDMI feed which is their responsibility to get onto the projection screens? | 03:15 |
| xfxf | because we don't get access to the rooms until 5am in the morning, so i have to be explicit about how i need things laid out | 03:15 |
| xfxf | we get access to 1x of the rooms 1 day before though for testing | 03:16 |
| mithro | xfxf: you have a HDMI feed from the podium right? | 03:16 |
| xfxf | yes | 03:16 |
| mithro | xfxf: so? | 03:16 |
| xfxf | i'm not sure you're understanding the implication they're giving | 03:16 |
| xfxf | but it's fine, i'll just push back | 03:16 |
| xfxf | i'm just not going to be able to solve issues with the devices on my own, so wanted to check you'll be around | 03:17 |
| xfxf | i'm fine taking responsibility as long as i know we can solve the problems | 03:17 |
| xfxf | i'm trying to avoid an issue where they completely stop responding to actual AV issues unrelated to the HDMI2USB because 'we are not responsible anymore' | 03:17 |
| mithro | xfxf: How are they suggesting otherwise? | 03:18 |
| xfxf | they want to use their own scan converter / splitter system which will give us a feed up the back | 03:18 |
| xfxf | to be clear, i don't actually want to do that at all | 03:19 |
| xfxf | but i keep telling them no, they keep pushing it | 03:19 |
| xfxf | we're up to conversation 5 or 6 now | 03:19 |
| mithro | xfxf: Why would they think we want a feed up the back? | 03:19 |
| xfxf | probably because they're used to how most people do this | 03:19 |
| mithro | xfxf: well, I'll leave it in your hands | 03:23 |
| xfxf | you haven't answered the question i was asking :) will you be around to help specifically with HDMI2USB issues? | 03:23 |
| mithro | xfxf: but it basically sounds like you've given them to much knowledge under the expectation that it would be helpful and it's backfired | 03:23 |
| mithro | xfxf: yes | 03:23 |
| xfxf | great | 03:23 |
| mithro | xfxf: but I don't think you should be counting on that | 03:24 |
| xfxf | okay, so that makes me nervous | 03:24 |
| xfxf | we know from LCA the devices aren't at a "just works" state yet | 03:24 |
| xfxf | it's at a "mostly works with caveats" state | 03:24 |
| xfxf | and it isn't a case of too much information. given our limited access, i booked a time with them to go in specifically to test the devices outputted through their systems OK. i think not doing that would have been bad. | 03:26 |
| xfxf | re issues, if they're things we can resolve through a power cycle, i'm not phased - i'm just recalling situations where the devices completely stopped working and we had to swap them with different ones, some laptops causing them to hang, etc | 03:27 |
| xfxf | i can setup a HDMI2USB in the corner of an organisers room and have people come and test their device, but we need to have a way to action fixes if we discover issues, or that testing is for moot | 03:27 |
| mithro | xfxf: If this was a piece of proprietary hardware what would you be doing? | 03:28 |
| xfxf | the proprietary hardware i have (blackmagic devices) don't have these issues | 03:29 |
| mithro | xfxf: What issues? | 03:29 |
| xfxf | i'm using HDMI2USB because i believe in its cause, and want to support open hardware + you - not because they're the solution that has the highest compatibility | 03:30 |
| xfxf | above | 03:30 |
| xfxf | the things we hit @ LCA | 03:30 |
| xfxf | which i believe are totally resolvable | 03:31 |
| xfxf | i just don't solve them myself :) | 03:31 |
| xfxf | er, d/don't/can't/ | 03:31 |
| xfxf | again, things that require a power cycle - not phased | 03:31 |
| xfxf | it was more issues where we had opsis's stop working entirely or had people's laptop cause them to lock up | 03:31 |
| xfxf | i have no idea if that'll be any better now with newer firmware? | 03:31 |
| xfxf | the stop working thing seems like hardware to me - like i've got two opsis's here which just don't work properly, systems never see them on the USB bus properly | 03:32 |
| xfxf | but they show a test pattern | 03:33 |
| xfxf | but without USB can't actually poke at it to test anything else | 03:33 |
| mithro | xfxf: I'd like you to come up with a plan which has action items you would like seen done | 03:33 |
| xfxf | it's difficult for me to give you a concrete action plan when i'm not in a position to test this with hundreds of laptops over the next few weeks | 03:34 |
| xfxf | my empirical evidence is identical to yours | 03:35 |
| xfxf | i'm not sure i can provide much more than that | 03:35 |
| mithro | xfxf: At the moment you are saying "I have worries that things won't work, please tell me that they will" | 03:37 |
| xfxf | no, it's just more that i'd like to ensure we have a plan so when we hit issues, we're able to resolve them, or have a viable workaround | 03:38 |
| xfxf | i realise you can't magically fix largely unknown things | 03:38 |
| mithro | xfxf: Write down a list of issues you think we might hit, I'll then see if there are things that I think are missing or not concerns and we can come up with plans on how to resolve / work around them | 03:41 |
| xfxf | okay, will do | 03:43 |
| mithro | xfxf: You can also write down a list of things you want to do before PyCon AU and I'll tell you if we can do them | 03:46 |
| *** panther is now known as sab_123 | 04:14 | |
| *** sb0 has quit IRC | 05:43 | |
| cr1901_modern | mithro: ping when you get the chance | 05:44 |
| mithro | cr1901_modern: If you are around in an hour or two, probably can chat then | 05:46 |
| mithro | cr1901_modern: I saw you said something about the HDMI frequency counter stuff | 05:46 |
| cr1901_modern | mithro: Yes, among other things | 05:47 |
| cr1901_modern | minispartan6 can be properly detected by my NVIDIA graphics card, but the driver doesn't like it/keeps resetting | 05:47 |
| mithro | cr1901_modern: Last you mentioned that you couldn't get a clock from the computer on the HDMI input? | 05:47 |
| cr1901_modern | mithro: I was able to get a clock input when I removed "just the EDID" and clocking modules and uncommented the HDMI input. But there is no way the frequencies I'm reading are in proper range (2-3MHz) | 05:48 |
| cr1901_modern | I'm measuring the pixel_clock*1 | 05:49 |
| mithro | cr1901_modern: What is pixel clock for 640x480? | 05:49 |
| mithro | http://tinyvga.com/vga-timing | 05:49 |
| tpb | Title: VGA Signal Timing (at tinyvga.com) | 05:49 |
| cr1901_modern | Ideally? Or what I'm measuring? | 05:49 |
| mithro | Looks like roughly 30MHz | 05:49 |
| cr1901_modern | It's 25.125Mhz | 05:49 |
| mithro | cr1901_modern: yeah - you should be getting the pixel clock | 05:49 |
| cr1901_modern | 25.175*... I was close :P | 05:50 |
| cr1901_modern | My current theory (will test later today) is that the laptop *is* in fact sending 2-3MHz b/c the display adapter driver keeps malfunctioning | 05:51 |
| mithro | cr1901_modern: There isn't much debugging you can do regarding the EDID problem on Windows | 05:51 |
| mithro | cr1901_modern: Attach litescope or something similar to the I2C lines and see what is going on | 05:51 |
| mithro | cr1901_modern: If you where on Linux you'll probably find it thinks there are lots of hotplug events going on, or it is reading a corrupt EDID or something.... | 05:52 |
| cr1901_modern | mithro: I'll see what I can do re: Linux. Unfortunately, the HDMI output is tied to the NVIDIA card | 05:53 |
| cr1901_modern | (I would NOT be using NVIDIA if external monitors we physically connected to the card) | 05:54 |
| mithro | cr1901_modern: https://github.com/timvideos/HDMI2USB/wiki/EDID-Related-Code | 05:54 |
| tpb | Title: EDID Related Code · timvideos/HDMI2USB Wiki · GitHub (at github.com) | 05:54 |
| cr1901_modern | mithro: So, what I'm seeing, sans the "I'm on Windows" bug, is expected in a sense :P? | 05:56 |
| cr1901_modern | (what I'm seeing == "the display driver doesn't like the new dev board") | 05:56 |
| mithro | cr1901_modern: No, I thought we had fixed all the EDID issues - but we have experienced similar style problems before | 05:56 |
| mithro | cr1901_modern: Make sure you have the EDID lines around the right way too, mixing up the clock+data often gives weird results :P | 05:57 |
| mithro | cr1901_modern: There are probably tools on Windows for reading the EDID from the monitor that you could test too | 05:57 |
| mithro | cr1901_modern: btw you do need to populate the EDID memory with valid data | 05:58 |
| cr1901_modern | mithro: There are, unfortunately, they go through the registry. There are no provisions to read from the monitor directly from user code | 05:58 |
| mithro | https://github.com/timvideos/HDMI2USB-misoc-firmware/blob/master/firmware/lm32/edid.c | 05:59 |
| tpb | Title: HDMI2USB-misoc-firmware/edid.c at master · timvideos/HDMI2USB-misoc-firmware · GitHub (at github.com) | 05:59 |
| mithro | Might take a look at this too | 05:59 |
| mithro | https://github.com/timvideos/HDMI2USB-misoc-firmware/blob/b1a554cc76a5da36c7182e9aad15b9c7e8b282a9/targets/atlys_edid_debug.py | 05:59 |
| tpb | Title: HDMI2USB-misoc-firmware/atlys_edid_debug.py at b1a554cc76a5da36c7182e9aad15b9c7e8b282a9 · timvideos/HDMI2USB-misoc-firmware · GitHub (at github.com) | 05:59 |
| cr1901_modern | mithro: The EDID is most likely valid. I am able to get the board to show up as a third monitor, called "HDMI2USB", with 800x600 resolution | 05:59 |
| mithro | # This SoC was used to debug EDID transactions between video sources and the board. | 05:59 |
| mithro | cr1901_modern: It would be good if we got callbacks / notification about EDID state changes | 06:00 |
| cr1901_modern | After a while, I can get the board to "behave" for short periods, where I have literally three monitors :P. But the input frequency is wrong. | 06:00 |
| cr1901_modern | But it's NOT zero, which is something :P. | 06:00 |
| mithro | https://github.com/timvideos/HDMI2USB-misoc-firmware/issues/39 | 06:00 |
| tpb | Title: Generate a message on the UART when EDID state changes · Issue #39 · timvideos/HDMI2USB-misoc-firmware · GitHub (at github.com) | 06:00 |
| cr1901_modern | mithro: Hardly all hope is lost. :D | 06:01 |
| cr1901_modern | mithro: "It would be good if we got callbacks / notification about EDID state changes" <--- I can do that | 06:01 |
| cr1901_modern | What I could also do is try one of hamsterwork's demos and see what happenbs | 06:02 |
| cr1901_modern | mithro: Additionally, when I build the "full HMDI input", not the abbreviated version with just the EDID, the CPU will crash occassionally. And ONCE I got a memory check failure when rebooting the board | 06:03 |
| mithro | cr1901_modern: There could be a couple of causes of that | 06:04 |
| mithro | cr1901_modern: _florent_ was saying that you can't execute from memory while also DMAing to/from it | 06:04 |
| mithro | cr1901_modern: but because the minispartan6 doesn't have enough block ram, we need to do that | 06:05 |
| mithro | cr1901_modern: so that might be the problem.... | 06:05 |
| mithro | cr1901_modern: _florent_ has just finished doing a rebase of our stuff onto litex which is based off the latest misoc/migen | 06:06 |
| mithro | cr1901_modern: and using litedram instead - which should fix that problem | 06:06 |
| cr1901_modern | mithro: I thought block RAM was used for cache? So there's pretty much a guarantee you'll be grabbing code from DRAM, even during DMA? | 06:07 |
| mithro | cr1901_modern: unknown | 06:07 |
| cr1901_modern | I'll talk to _florent_ about this when he's around. I'm a little bit confused about the memory hierarchy. | 06:07 |
| mithro | cr1901_modern: I'm pretty sure there is block ram uses for cache | 06:08 |
| cr1901_modern | Just makes sense :P | 06:08 |
| mithro | but I also seem to remeber seeing a "l2_cache=False" or something similar along those lines | 06:08 |
| cr1901_modern | mithro: As I understand it, MiSoC has provisions for onboard ROM, onboard RAM, and offboard RAM. The onboard RAM is separate from the cache, which is provided by the CPU source files. However, I don't know any designs which use both the onboard and offboard RAM simultaneously | 06:10 |
| cr1901_modern | mithro: Want some good news now :P? | 06:11 |
| mithro | cr1901_modern: sure? | 06:14 |
| cr1901_modern | mithro: Once these bugs are fixed, I believe I figured out a way to make input and output work simultaneously on minispartan6 | 06:14 |
| mithro | cr1901_modern: great! | 06:15 |
| mithro | cr1901_modern: I had some ideas on how to do that, but hadn't actually gotten around to trying anything | 06:16 |
| cr1901_modern | mithro: I believe we can replace the PLL used to generate the system frequency with two DCMs; one DCM synthesizes 5x's frequency, the other takes in the 5x's frequency and will shift it by 270 degrees. And DCMs have provisions to sync the outputs of two of them to each other | 06:16 |
| cr1901_modern | well 5/2* | 06:16 |
| mithro | cr1901_modern: hrm? | 06:18 |
| cr1901_modern | mithro: Do you know what a DCM is? | 06:18 |
| mithro | cr1901_modern: yes | 06:19 |
| cr1901_modern | Ahhh, so what are your concerns then :)? | 06:19 |
| mithro | cr1901_modern: oh, you are talking about generating the RAM/system clock using the DCM | 06:19 |
| cr1901_modern | Yes We most certainly need a PLL for the input b/c the input *will* deviate from ideal. Not sure about the output, but ain't broke don't fix | 06:20 |
| mithro | We have 2 PLLs | 06:20 |
| mithro | 1 for the input, 1 for the system? | 06:20 |
| cr1901_modern | No, there's a PLL for the output as well | 06:21 |
| mithro | I don't think we actually need a PLL for the output side of things, but might be wrong... | 06:21 |
| cr1901_modern | Why do we need a PLL for the system? Or are you just describing the current setup? | 06:21 |
| mithro | cr1901_modern: generate a stable clock from the oscillator? | 06:22 |
| mithro | cr1901_modern: I'm no expert on clocking :P | 06:22 |
| cr1901_modern | A DCM can generate a stable clock. It just can't phase lock its output to an unknown input | 06:23 |
| mithro | cr1901_modern: The PLL might be needed on the output to make the SERDES work within the jitter requirements or to allow the ability to program the output frequency? | 06:24 |
| cr1901_modern | mithro: Not sure about the second point (a PLL will lose lock if input is not close to ideal output, and idk how to change that set point), but the first point makes sense. | 06:26 |
| cr1901_modern | I remember you saying that there's benefits to having more than 2 PLLs, but I can't remember if you said that in the context of "minispartan is scarce on resources", or "some gateware beyond the base HDMI2USB" requires it. | 06:26 |
| cr1901_modern | or maybe both :P | 06:26 |
| mithro | cr1901_modern: well, you need a PLL per input | 06:26 |
| mithro | cr1901_modern: if we can make the system work without using an PLLs allowing 4 inputs, that would be awesome | 06:26 |
| mithro | cr1901_modern: we may been a PLL for stable clocking stuff on the DDR.... | 06:27 |
| mithro | cr1901_modern: basically, PLLs are really limited on the Spartan 6 series :( | 06:27 |
| cr1901_modern | mithro: I don't THINK no PLLs are possible. The input will require it b/c the PLL will need to deal with deviations from ideal input, and a DCM is not capable of doing this. | 06:28 |
| mithro | cr1901_modern: one of the biggest limiting factors in our designs | 06:28 |
| cr1901_modern | I am not prepared to write an All-Digital PLL either :( | 06:28 |
| cr1901_modern | (Which, isn't going to work anyway now that I think about it, thanks to the multiplier) | 06:28 |
| mithro | cr1901_modern: We set PLL stuff here -> https://github.com/timvideos/HDMI2USB-misoc-firmware/blob/master/firmware/lm32/pll.c | 06:29 |
| tpb | Title: HDMI2USB-misoc-firmware/pll.c at master · timvideos/HDMI2USB-misoc-firmware · GitHub (at github.com) | 06:29 |
| cr1901_modern | In any case, I think we should leave the output PLL alone for now, assume inputs require PLLs, and convert the PLL that's used to drive the system clock into two DCMs. | 06:29 |
| cr1901_modern | That's my recommendation anyway ;D | 06:30 |
| mithro | cr1901_modern: I'm happy with anything which makes it work :) | 06:30 |
| cr1901_modern | I'll make a separate branch for replacing the DCM in my own personal source tree. I'm not comfortable making any more changes than I have to while minispartan is crashing and my graphics driver hates the HDMI2USB :P | 06:32 |
| cr1901_modern | So... that's the current status of things. Sorry it's been slow going. | 06:32 |
| mithro | cr1901_modern: have you tried removing the output and just keeping the input? | 06:32 |
| cr1901_modern | mithro: Yes, currently I have to thanks to the aforementioned PLL woes | 06:33 |
| mithro | cr1901_modern: It seems like working with that should be good enough for now? | 06:33 |
| mithro | cr1901_modern: and focus on getting the HDMI input working? | 06:33 |
| cr1901_modern | mithro: Oh wait, are you talking about the "full blown hdmi_in" module, or just the bare minimum EDID module? | 06:33 |
| mithro | cr1901_modern: Yeah, I was meaning a full blow hdmi_in module | 06:35 |
| cr1901_modern | I recall you saying "just instantiate an EDID module" and call it a day. Unfortunately, Xilinx will bitch if I don't include the clocking module and the datacapture modules as well. The clocking module requires a PLL. So it probably doesn't make sense to "just" do EDID. | 06:35 |
| mithro | cr1901_modern: That was another potential idea | 06:35 |
| mithro | cr1901_modern: hopefully _florent_ will be around later so we can chat about the rebased stuff - it sounds like that might help solve some of the weirdness you are getting.... | 06:36 |
| cr1901_modern | mithro: That's fine, I have the output disabled for now. But just remember that RIGHT now, input/output simultaneously do not work on minispartan | 06:36 |
| mithro | be back in 30 minutes - going to get some food | 06:37 |
| cr1901_modern | and input doesn't work either for that matter :) | 06:37 |
| cr1901_modern | alright sounds good. I'll be around | 06:37 |
| mithro | sab_123: I believe I have replied to everything outstanding | 07:55 |
| *** sab_123 has quit IRC | 07:57 | |
| *** sab_123 has joined #timvideos | 07:57 | |
| sab_123 | mithro, okay | 08:18 |
| tumbleweed | mithro: I'm out sick, but maybe someone else can do some remote debugging with you | 08:34 |
| mithro | tumbleweed: ahh, that sucks | 08:35 |
| *** Bertl_zZ is now known as Bertl | 08:35 | |
| mithro | tumbleweed: What version of the firmware were you flashing? | 08:35 |
| mithro | tumbleweed: It sounds like the EEPROM might be corrupted... | 08:35 |
| tumbleweed | mithro: c4646dd6ad5ac3be4edb05f08d5f72aa2fcba8d5 (something I had tagged as known-good) | 08:36 |
| tumbleweed | (that's a prebuilt commit) | 08:36 |
| mithro | I had planned to work on the FX2 EEPROM stuff today, but it doesn't seem likely that I'll get to it | 08:37 |
| mithro | tumbleweed: do you know if anyone has attempted to look at packaging modeswitch at all? | 08:37 |
| tumbleweed | nope | 08:38 |
| mithro | cr1901_modern: was there anything more you wanted to discuss? | 09:22 |
| *** ssk1328 has joined #timvideos | 09:59 | |
| ssk1328 | mithro: Ping! | 10:01 |
| mithro | ssk1328: pong! I'm alive barely | 10:08 |
| ssk1328 | mithro: I actually don't have question as such to ask right now. But I had pushed in a lot of repositories last week, which are yet to be reviewed. | 10:10 |
| mithro | ssk1328: okay | 10:10 |
| ssk1328 | mithro: ALso we missed our weekly meeting this week | 10:10 |
| mithro | ssk1328: can you send me an email with what you want me to look at / review and I'll try and get to it tomorrow | 10:11 |
| ssk1328 | Ok | 10:11 |
| cr1901_modern | mithro: At the moment, no. After fixing the input woes and trying to put sysclk generation onto a DCM, I'll get started with data islands if you wish. | 10:22 |
| cr1901_modern | mithro: When input woes are fixed, I have questions about ci.c. Unfortunately, I don't remember what they were right now XD. So I'll get back to you on that. | 10:24 |
| mithro | cr1901_modern: okay | 10:24 |
| cr1901_modern | (It was related to the defines used to activate certain status messages and debugging info, and me having trouble getting some of them- outputs in particular- to work) | 10:25 |
| cr1901_modern | mithro: Actually one last quick q... | 10:27 |
| cr1901_modern | Should I be worried that status returns a memory bandwidth of about 16-32Mb/sec | 10:27 |
| cr1901_modern | ? That sounds kinda low... | 10:28 |
| mithro | cr1901_modern: Is the output enabled? | 10:28 |
| cr1901_modern | No | 10:28 |
| mithro | cr1901_modern: Then the memory bandwidth will be ~0 | 10:28 |
| cr1901_modern | ddr: read: 24Mbps write: 0Mbps all: 24Mbps | 10:28 |
| cr1901_modern | I assume that means MegaBITS per second? | 10:28 |
| mithro | cr1901_modern: I think the fact it isn't zero is because you are executing the stuff from ddr ram? | 10:29 |
| mithro | cr1901_modern: This would be a _florent_ question I think.... | 10:29 |
| cr1901_modern | Alright, will ask him when he's around. Certainly possible that I'm just not actually exhausting bandwidth. I've discussed all I've needed to for now :). | 10:31 |
| *** _florent_ has joined #timvideos | 10:41 | |
| *** Niharika has joined #timvideos | 10:41 | |
| mithro | Please of the devil ;) (_florent_) | 10:42 |
| cr1901_modern | Hey _florent_, are you there? | 10:51 |
| cr1901_modern | Your presence is requested | 10:51 |
| *** Bertl is now known as Bertl_oO | 11:06 | |
| *** sab_123 has quit IRC | 11:08 | |
| *** sab_123 has joined #timvideos | 11:09 | |
| ssk1328 | mithro: Is there a way to bypass 30mins of make gateware, to test small changes in gateware code | 12:06 |
| ssk1328 | mithro: I need this specifically for testing float16 arithmetic with lm32 | 12:07 |
| *** rohitksingh has joined #timvideos | 12:10 | |
| mithro | ssk1328: use the video mixer target rather than the hdmi2usb target | 12:38 |
| mithro | ssk1328: that will cut it down to a lot smaller | 12:38 |
| mithro | ssk1328: actually, use the base target | 12:38 |
| mithro | ssk1328: that should get it down to about 5-10 minutes | 12:40 |
| shenki | mithro: hello | 12:53 |
| shenki | i was setting up the hdmi2usb environment on my new laptop | 12:53 |
| shenki | and we don't handle secure boot very well | 12:54 |
| mithro | shenki: hrm? | 12:54 |
| shenki | dkms tries to install the vizzini module, fails due to module signing, and then the tty goes all screwy | 12:54 |
| mithro | _florent_: https://gist.github.com/mithro/604da515edc1061a77a8ee6c1fe729e6 | 12:54 |
| tpb | Title: Script to get all the enjoy-digital repos and set up a conda environment for using them in · GitHub (at gist.github.com) | 12:54 |
| mithro | shenki: well, if you got that uart change upstream, we could ditch that :P | 12:55 |
| shenki | i tried to work out how to discover secure boot mode, but the tool to read efi variables it isn't installed by default | 12:55 |
| shenki | yeah, i knew you would say that | 12:55 |
| shenki | i thought the same thing :D | 12:55 |
| mithro | shenki: :-P | 12:55 |
| mithro | shenki: You mean disable secure boot mode? | 12:55 |
| shenki | no | 12:55 |
| shenki | dkms offers that as an option when installing | 12:55 |
| shenki | i didn't want to do that | 12:56 |
| shenki | i was thinking we could detect secure boot and skip the kernel module install step | 12:56 |
| mithro | shenki: well, its required for the Atlys at the moment | 12:56 |
| shenki | yeah | 12:56 |
| mithro | shenki: so skipping it just gives you a non-working system | 12:56 |
| shenki | i can't do atlys dev on this machine | 12:56 |
| shenki | but i have plenty of other boards | 12:57 |
| mithro | shenki: you could make it so if the BOARD= isn't set to the Atlys, then it skips installing the vizzini module or something? | 12:57 |
| shenki | ok, i'll do that | 12:57 |
| mithro | shenki: I was working on updating the docs for setup at https://github.com/mithro/HDMI2USB-misoc-firmware/tree/docs-scripts-update | 12:58 |
| tpb | Title: GitHub - mithro/HDMI2USB-misoc-firmware at docs-scripts-update (at github.com) | 12:58 |
| mithro | shenki: https://github.com/mithro/HDMI2USB-misoc-firmware/tree/docs-scripts-update/scripts | 12:58 |
| tpb | Title: HDMI2USB-misoc-firmware/scripts at docs-scripts-update · mithro/HDMI2USB-misoc-firmware · GitHub (at github.com) | 12:58 |
| mithro | shenki: there are also much better udev rules and improved modeswitch tool at https://github.com/mithro/HDMI2USB-mode-switch | 12:59 |
| tpb | Title: GitHub - mithro/HDMI2USB-mode-switch: Tool for switching boards supported by HDMI2USB firmware between multiple different modes (programming, webcam, etc). (at github.com) | 12:59 |
| mithro | shenki: I'd like to update HDMI2USB-misoc-firmware makefile to use the modeswitch tool | 12:59 |
| shenki | cool | 13:00 |
| mithro | shenki: so you can just type "make load" after doing a "make load-fx2" and it'll push it back into the jtag mode | 13:00 |
| mithro | but again, not enough time | 13:00 |
| *** rohitksingh has quit IRC | 13:00 | |
| shenki | :) | 13:06 |
| shenki | yep | 13:06 |
| mithro | shenki: _florent_ has almost finished the rebase work which hopefully solves a bunch of issues on the miniSpartan | 13:07 |
| mithro | shenki: cr1901_modern has also been playing with the miniSpartan6+ | 13:07 |
| shenki | good to hear | 13:08 |
| shenki | i want to write a spi-romulator in migen on the ms6 | 13:09 |
| shenki | so i can do boot testing of ARM systems | 13:09 |
| mithro | shenki: What is a spi-romulator, you mean something which pretends to be a SPI flash? | 13:09 |
| shenki | without risk of bricking | 13:09 |
| shenki | yeah | 13:09 |
| shenki | i got the term from someone else: https://github.com/bunnie/novena-spi-romulator | 13:10 |
| tpb | Title: GitHub - bunnie/novena-spi-romulator: SPI romulator (at github.com) | 13:10 |
| mithro | shenki: I believe the coreboot guys have already created something like this? | 13:10 |
| shenki | using migen? | 13:10 |
| mithro | No | 13:10 |
| shenki | anyway, even if they have | 13:10 |
| shenki | the purpose is to write migen | 13:10 |
| mithro | shenki: I'm all for you writing more migen :) | 13:11 |
| shenki | yeah | 13:11 |
| mithro | shenki: I'd love for you to get back to the Linux porting stuff sometime too | 13:12 |
| shenki | yeah | 13:12 |
| shenki | i think i want to get the uart driver done first | 13:12 |
| shenki | then linux porting | 13:12 |
| shenki | do we need uboot? | 13:13 |
| shenki | i dont think we do. but ive been doing a bunch of uboot hacking recently | 13:13 |
| mithro | shenki: we need uboot if it means you can hack on it at work ;) | 13:13 |
| mithro | shenki: It has always been unclear to me what uboot provides :P | 13:14 |
| shenki | heh | 13:14 |
| shenki | in our case, nothing | 13:15 |
| mithro | shenki: Do they have a "fileformat" for doing things like storing stuff in SPI flash or something? | 13:15 |
| shenki | no | 13:15 |
| shenki | we're currently going through that now :) | 13:16 |
| shenki | i think we will use FIT images | 13:16 |
| mithro | FIT images? | 13:16 |
| mithro | shenki: https://github.com/timvideos/HDMI2USB-misoc-firmware/issues/253 :P | 13:16 |
| tpb | Title: SPI flash should have proper file system or something similar · Issue #253 · timvideos/HDMI2USB-misoc-firmware · GitHub (at github.com) | 13:16 |
| shenki | U-Boot's primary image format is FIT (Flat Image Tree), a very flexible, structured container format which supports multiple kernel images, device trees, ram disks, etc | 13:17 |
| shenki | (i dont really know myself - i will learn this week) | 13:17 |
| mithro | shenki: I believe when _florent_ finishes the rebase we should be able to have Ethernet enabled all the time - which means things like tftp booting new lm32 firmware | 13:18 |
| shenki | uboot could/would replace the "BIOS" that the project currently uses | 13:18 |
| shenki | simple menu system, chainloading from flash/serial/net, simple tests | 13:18 |
| shenki | the upside is we don't have to maintain code | 13:19 |
| shenki | downside is more complexity than the current code | 13:19 |
| mithro | shenki: when looking into FIT, for our use case we need the image to start with an arbitrary binary blob | 13:20 |
| shenki | you mean the start of flash? | 13:20 |
| mithro | shenki: yeah | 13:20 |
| shenki | ok. what is that blob? | 13:20 |
| mithro | the FPGA gateware | 13:21 |
| shenki | ok. and that needs to be at the start of flash? or just a fixed/known location? | 13:21 |
| mithro | shenki: has to be at position zero | 13:21 |
| shenki | ok | 13:21 |
| mithro | shenki: ideally we should be using MultiBoot in the future -> http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/pim_p_creating_prom_file_spi_multiboot.htm | 13:22 |
| mithro | shenki: which is basically where the first (minimal) gateware verifies the proper gateware and then gets the FPGA to load that instead | 13:23 |
| shenki | ah yep. that sounds good | 13:23 |
| mithro | shenki: so you keep around a failsafe gateware which you boot too if the normal gateware is borked | 13:24 |
| shenki | yep | 13:24 |
| shenki | "golden image" | 13:24 |
| shenki | kinda, not really i guess | 13:24 |
| mithro | It's more useful for us if we want to have multi gateware which setup things differently | 13:25 |
| mithro | Well, I'm going to walk home, then eat some dinner | 13:33 |
| *** sb0 has joined #timvideos | 13:37 | |
| *** sab_123 has quit IRC | 15:38 | |
| *** ssk1328 has quit IRC | 17:34 | |
| *** Bertl_oO is now known as Bertl_zZ | 23:19 | |
| *** nueces has joined #timvideos | 23:50 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!