*** tpb has joined #timvideos | 00:00 | |
cr1901_modern | mithro: Bitbang flash write works. Bad news though... I kinda lost the scrollback to screencap tho (code not ready) :( | 00:53 |
---|---|---|
*** arcticShadow has quit IRC | 01:10 | |
*** arcticShadow has joined #timvideos | 01:13 | |
*** arcticShadow has quit IRC | 01:16 | |
*** arcticShadow has joined #timvideos | 01:25 | |
*** arcticShadow has joined #timvideos | 01:27 | |
mithro | cr1901_modern: Great, clean it up and send it upstream? | 01:33 |
cr1901_modern | mithro: Sure. But before I send a pull request, I want to discuss formatting/file changes. Right now, I'm examining some unexpected behavior. >> | 01:57 |
cr1901_modern | (I *strongly* suspect it's due to not clearing the cache properly in the currently loaded firmware, but just in case) | 01:57 |
cr1901_modern | mithro: If you wish to play along, here's a text file showing what I did | 02:03 |
cr1901_modern | Lines 40 and 41 in particular are unexpected, taking the lm32's cache into account | 02:03 |
mithro | You didn't link a text file.... | 02:04 |
cr1901_modern | That would help, wouldn't it: https://gist.github.com/cr1901/4b4e5849ede91fd48d06fbebdfc39e99 | 02:04 |
cr1901_modern | mithro: (Don't mind me, btw. I'm just thinking out loud) | 02:04 |
tpb | Title: spiflash.txt · GitHub (at gist.github.com) | 02:04 |
cr1901_modern | mithro: I was just going to make you guess the gist ID :) | 02:04 |
mithro | cr1901_modern: That also doesn't show me the code for that | 02:05 |
cr1901_modern | mithro: Two seconds please | 02:07 |
cr1901_modern | Gah! firmware/flash.c was deleted in the tip of the tree | 02:08 |
cr1901_modern | mithro: Git woes, I apologize. I am somehow on a commit that no longer exists upstream | 02:16 |
mithro | cr1901_modern: Umm, firmware/flash.c never existed upstream | 02:17 |
cr1901_modern | mithro: I said upstream. I meant mithro/HDMI2USB-litex-firmware* | 02:17 |
mithro | cr1901_modern: Never existed there either... | 02:17 |
cr1901_modern | mithro: The tip of my master points to e656e22ea079d041095b1d44738ae7bf8edb2f50 | 02:18 |
mithro | cr1901_modern: I've never written a firmware/flash.c ... | 02:18 |
cr1901_modern | (what the hell did I do to this poor tree T_T?!) | 02:18 |
cr1901_modern | Okay I found where I am in the commit graph. I managed to accidentally fast-forward to the tip of merge-arty-soc | 02:24 |
mithro | cr1901_modern: arty-soc has a firmware/flash.c? | 02:24 |
cr1901_modern | mithro: Yes | 02:25 |
mithro | Interesting, I didn't notice that | 02:25 |
cr1901_modern | As of this commit: https://github.com/mithro/HDMI2USB-litex-firmware/commit/b70c03bfbb5d7c37a1f5f801f6b40e937798139e | 02:25 |
tpb | Title: execute firmware from sdram, add flash and flash_test · mithro/HDMI2USB-litex-firmware@b70c03b · GitHub (at github.com) | 02:25 |
cr1901_modern | mithro: Should I cherry pick back on master, or is it okay to merge back to master from arty-soc (while acknowledging it was a mistake)? | 02:25 |
mithro | cr1901_modern: I'll merge the arty support in the next couple of days | 02:26 |
cr1901_modern | mithro: So do cherry pick, and you'll handle the merge conflict that *might* occur from "both modified"? | 02:27 |
cr1901_modern | (firmware/flash.c firmware/flash.h will be "both modified" during the merge) | 02:27 |
mithro | cr1901_modern: ? | 02:30 |
cr1901_modern | mithro: Actually, let me just commit, then I'll show you the problem | 02:30 |
cr1901_modern | mithro: Sweet Jesus, finally got it: https://github.com/cr1901/HDMI2USB-litex-firmware | 03:00 |
tpb | Title: GitHub - cr1901/HDMI2USB-litex-firmware: A version of the HDMI2USB firmware based around the misoc+migen tools produced by m-labs. (at github.com) | 03:00 |
cr1901_modern | https://github.com/cr1901/litex | 03:01 |
tpb | Title: GitHub - cr1901/litex: Build your hardware, easily! (at github.com) | 03:01 |
mithro | cr1901_modern: What is line 91 doing? | 03:02 |
cr1901_modern | mithro: Which file | 03:02 |
mithro | https://github.com/cr1901/HDMI2USB-litex-firmware/blob/master/firmware/flash.c#L91 | 03:03 |
tpb | Title: HDMI2USB-litex-firmware/flash.c at master · cr1901/HDMI2USB-litex-firmware · GitHub (at github.com) | 03:03 |
cr1901_modern | mithro: For the sake of testing the flash, I'm resetting the free area back to 0xFF | 03:03 |
mithro | cr1901_modern: So... what is the problem? | 03:06 |
cr1901_modern | mithro: Okay, so the gist I generated with commit 5b167704d55db44dd279ef867543a408454b56e9, before I added the flush cache command. The problem is these two lines: https://gist.github.com/cr1901/4b4e5849ede91fd48d06fbebdfc39e99#file-spiflash-txt-L40-L41 | 03:10 |
tpb | Title: spiflash.txt · GitHub (at gist.github.com) | 03:10 |
cr1901_modern | Before I ran this firmware, I ensured that the SPI flash region to be tested was already zeroed out. This means that a read from that area should return all zeros; it doesn't. | 03:10 |
mithro | cr1901_modern: But of course you need to flush the cache after you modify the spiflash? | 03:10 |
cr1901_modern | mithro: Yes, but at power on for the FPGA the flash region that is tested by bitbang_test is already zeroed out. Thus it won't be in the cache until I run bitbang_test | 03:12 |
cr1901_modern | mithro: I am *fairly* certain flushing the cache solves the problem, I just created this gist as a "starting point" just in case. | 03:12 |
cr1901_modern | Only thing I can think of is that the flash region wasn't fully zeroed out for some reason during the previous test | 03:14 |
mithro | cr1901_modern: I don't know how the dcache actually works - but I wouldn't be surprised if it works on sizes more than individual bytes, so just reading until you get the area is going to cause the cache to contain part of it? | 03:14 |
cr1901_modern | mithro: That's plausible. I'm not going to dwell on it right now. The problem as far as I can tell disappears if I flush the dcache | 03:17 |
cr1901_modern | (which is expected, I just don't want the problem to be something more sinister like "writes aren't honored" :P) | 03:17 |
*** tvCommitBot has joined #timvideos | 03:18 | |
tvCommitBot | [website] mithro pushed 1 new commit to master: https://git.io/vSc43 | 03:18 |
tvCommitBot | website/master 1fdeb48 Tim 'mithro' Ansell: Adding new lines to fix lists. | 03:18 |
*** tvCommitBot has left #timvideos | 03:18 | |
cr1901_modern | mithro: Do you think we should use XMODEM? Not sure if this is a concern for you, but XMODEM in and of itself has no knowledge of file size | 03:30 |
*** rohitksingh_work has joined #timvideos | 03:51 | |
*** arcticShadow has quit IRC | 03:54 | |
*** arcticShadow has joined #timvideos | 04:00 | |
cr1901_modern | mithro: I figured it out. It's not a bug. I didn't take into account that putting in/deleting code will ultimately move the "free area" I used for testing. So when I add new code in, it will push the area I use for testing up to higher addresses that were never touched by the bitbang test | 05:45 |
*** sb0 has quit IRC | 06:02 | |
*** sb0 has joined #timvideos | 06:52 | |
paddatrapper | mithro: GSoC application submitted | 08:59 |
shenki | paddatrapper: what did you submit a propsal on? | 10:28 |
paddatrapper | shenki: USB audio | 10:29 |
paddatrapper | Though not the HDMI capture side | 10:29 |
shenki | ah cool. ive done some work with that before | 10:29 |
shenki | you'r egoing to make it act like a USB sound card? | 10:29 |
*** danielki has joined #timvideos | 10:55 | |
*** sb0 has quit IRC | 11:12 | |
paddatrapper | shenki: yup. Stereo PCM capture | 12:39 |
*** rohitksingh_work has quit IRC | 12:55 | |
*** SamSagaZ has quit IRC | 13:23 | |
*** danielki has quit IRC | 15:52 | |
*** sb0 has joined #timvideos | 15:57 | |
*** danielki has joined #timvideos | 17:20 | |
*** hyadez has quit IRC | 17:45 | |
*** sam_ has quit IRC | 18:09 | |
*** hyadez has joined #timvideos | 18:44 | |
*** Sewar has quit IRC | 19:56 | |
*** userxyz has joined #timvideos | 20:22 | |
*** userxyz has quit IRC | 21:13 | |
*** danielki has quit IRC | 21:15 | |
*** SamSagaZ has joined #timvideos | 21:58 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!