#timvideos

John_K: Also mention that you'll lose the UART if you associate w/ libusb

mithro: Not that it's going to matter in a few days :P, but there seems to be a few versions of fxload. Which version are you currently using for mode-switch?

cr1901_modern: the one that gets installed with "apt-get install fxload"

Mithro: any luck?

John_K: sorry, only just starting to take a look now

John_K: Afraid it doesn't quite work...

John_K: investigating now...

Title: Ubuntu Pastebin (at pastebin.ubuntu.com)

Title: Snippet | IRCCloud (at www.irccloud.com)

John_K: It also looks like you only support intelhex file format?

mithro: heading back to Cape Town now. Should be available in 1.5-2 hours

paddatrapper: okay cool

John_K: http://pastebin.ubuntu.com/25405796/

Title: Ubuntu Pastebin (at pastebin.ubuntu.com)

John_K: It looks like there is an issue with parsing the segments?

John_K: I pushed some small fixes into your branch

write on-chip, addr 0x0100 len 128 (0x0080)

rohitksingh1: ping?

John_K: I would also like to move the changes into the hdmi2usb/modeswitch/libusb.py file

rohitksingh1: Do you know anything about https://numato.com/lm4550-ac97-stereo-audio-cod... ?

Title: LM4550 AC'97 Stereo Audio Codec Expansion Module (at numato.com)

Ishan_Bansal: ping?

mithro : pong

Ishan_Bansal: I'm just reviewing paddatrapper's stuff now - I plan to look at your stuff after

Ishan_Bansal: Where are we at with things?

mithro: been a massive accident and traffic is horrendous, so going to be probably another hour

paddatrapper: No worries

mithro : among the pull request we are on RLE-core, you made the comments twice and I have changed the RLE accordingly.

Ishan_Bansal: Okay, I'll take another look at hopefully merge it

Also regarding the final report I also made the changes as per your comments on Google docs.

Ishan_Bansal: Then you have more pull requests to send, right?

mithro : yup.

Ishan_Bansal: Okay cool

Ishan_Bansal: ping?

mithro : pong

Ishan_Bansal: Couple more tips when writing comments

Ishan_Bansal: You should never write something like "Under this module a matrix containing" or "Since the data we get" -- instead say "This module takes a matrix containing 64 blocks of XXXX and verifies the RLECore produces the same output as the reference data"

Ishan_Bansal: If you find yourself writing words like "Under", "Since" and "Get" you are probably going down the right path

s/right/wrong/

Ishan_Bansal: If you find yourself writing words like "Under", "Since" and "Get" you are probably going down the *wrong* path

Ishan_Bansal: As well, you should reply to each of my comments on your code saying if you have fixed the issue

Ishan_Bansal: You have comments on your pull request now too - it's pretty close, mainly just some comment clean up

mithro : Ok, I will fix them.

Ishan_Bansal: Oh, as well - generally I think you'll probably want "then" (--> I went to the shops then went home.) not "than"(--> I'd rather walk than drive there.)

English is kind of stupid though

Mithro: thanks for the fixes, I wasn't quite sure what was being done there

And yes, only intelhex support at the moment - I believe that is what was described in the issue

John_K: libusb.py and lsusb.py are suppose to provide the same API to the rest of the code

Ah

Also my bad, the issue doesn't mention intelhex

As for the Invalid parameter, it seems the request may be too large

John_K: Yeah - it doesn't seem to be parsing the input file correctly

Oh? I'm using the python intelhex module - it seems to do the right thing

fxload reads that segment as only 128 bytes long, but your code thinks its much larger

Hrm, re-reading the pastebibs

Pastebins

John_K -> http://pastebin.ubuntu.com/25405796/

Title: Ubuntu Pastebin (at pastebin.ubuntu.com)

I think that is probably the most informative one

It seems they both do 128 byte transfer just fine

But the fxload code breaks the next fragment up into multiple USB transfers

I hadn't encountered a test file like this so far

Can you pastebin this hex file?

Yeah from inspecting pyusb it looks like the control transfer is failing, strongly suspect due to transfer size

I'm pretty sure it's not the ezusb_write code?

Title: fxload/ezusb.c at master · wkoszek/fxload · GitHub (at github.com)

John_K: I wonder if there is just a bug in the intel hex loading?

John_K: file I'm loading is here -> https://github.com/timvideos/HDMI2USB-mode-swit...

Title: HDMI2USB-mode-switch/ixo-usb-jtag.hex at master · timvideos/HDMI2USB-mode-switch · GitHub (at github.com)

It's entirely possible, checking ezusb.c to see how they handle fragmentation

Thanks for linking that file

John_K: Does look like the error is occuring on the first multi-line segment

John_K: https://github.com/timvideos/HDMI2USB-mode-swit...

Title: HDMI2USB-mode-switch/ixo-usb-jtag.hex at master · timvideos/HDMI2USB-mode-switch · GitHub (at github.com)

Ah I think I see what's happening, the python intelhex module is reconstructing things in memory instead of processing the file line-by-line

Actually

And there happens to be a large contiguous segment once it reconstructs things

I think I ran across this before...

John_K: Take a look at https://github.com/mithro/hexfile ?

Title: GitHub - mithro/hexfile: Python library for parsing Intel Hex files. (at github.com)

I think I just need to break up the segments I get back from the intelhex module if they're too large for a single ctlrl transfer

Sure

This seems like it would have the same issue

John_K: Looks like you might be right -> https://github.com/timvideos/HDMI2USB-litex-fir...

Title: HDMI2USB-litex-firmware/generate_fx2_microboot.py at v0.0.2 · timvideos/HDMI2USB-litex-firmware · GitHub (at github.com)

Title: Document upper limits on control transfers (INVALID_PARAMETER) (re: MAX_CTRL_BUFFER_LENGTH) · Issue #110 · libusb/libusb · GitHub (at GitHub.com)

tl;dr: libusb internals support 4K max control transfer buffer

Patch should be easy

Ishan_Bansal: you seem to have removed my access to put comments on your gsoc file report...

s/file/final/

Mithro: try re-pulling CypressFX

Title: Snippet | IRCCloud (at www.irccloud.com)

Well that's embarrassing, flubbed the commit

Fixed, retry please

It appears to succeed in uploading ixo-USB-JTAG.hex to my test FX2 device

John_K: the device re enumerates as the ixo-usb-jtag device?

It does not appear to, no

mithro : https://docs.google.com/document/d/1hXhApH3lDt4...

Title: GSOC Final Project Report - Google Docs (at docs.google.com)

John_K: It should?

mithro : going to lunch, come within half an hour.

John_K: Doesn't seem to work here either...

Just verifying functionality on windows with fxload.exe now

Ok that works as you described, I'll Debug here and ping you once I have the device reenumerating properly

Likely will happen in about 16 hours, its late here

John_K: No worries

John_K: fxload.exe with --verbose might be useful to figure out what is going on....

So now it seems to work

Oh hah

Fxload.py will work because it reboots the device for you but the API doesn't

mithro: just waiting for travis to build the fixes on that PR

Actually that's a lie, it IS in the API

paddatrapper: You coding in a car, or made it home?

mithro: just got home. I did some work in the car, then my battery died

paddatrapper: Okay cool

paddatrapper: I haven't made much progress on the audio side of things been reviewing code and John_K has been distracting me :-P

mithro: no worries. I see version_data is causing issues with my PR and travis...

mithro: I doubt I'll be able to get the loopback working in time for Tuesday. I'm going to keep working on it, but it feels like it needs a lot more work than there is time before submission

paddatrapper: Okay

paddatrapper: Were are things at the moment?

mithro: master isn't populating FIFO buffer correctly, so it is writing the same 512 bytes all the time. Slave isn't reading them

paddatrapper: Do you want to have a look at it in a little bit?

mithro: sure, though I think we probably want to try get the PR merged first as I'm already dreading the merge conflicts :)

paddatrapper: Sure

mithro: I don't have the git-foo to know what on earth travis is complaining about when it fails to generate the version_data stuff

paddatrapper: Don't worry about it - I'll figure it out

mithro: thanks

paddatrapper: This AC97 codec looks pretty simple - I should have firmware working for it in an hour or two

mithro: awesome

But first I'm going to go find some dinner